Playing ULAW sample correctly?

[Joerg-Cyril.Hoehle]

Hi,

Using the MCI, I've successfully played an ADPCM sample from Wikipedia, except
at the very end of IMA ADPCM play:
fixme:wavemap:wodWrite Not all src buffer has been written, expect bogus sound
After play status length increased from 13813 to 13826! How comes?

However, playing an ULAW sample, the same message occurs constantly (apparently
once for each wavehdr played) and the sound is awfully chopped. The error could
be anywhere (MCI, WAVE_MAPPER, gsm711 ACM, waveaudio ...).

Are there audio tests in Wine beside winmm/wave.c?
How is ulaw / how are the msacm/gsm711/gsm722/gsm602 tested?

Does anybody know whether ULAW works in Wine? (Any app that uses it outside of MCI?)

Thanks,
 Jörg Höhle

[Eric Pouech-5]

Joerg-Cyril.Hoehle@... a écrit :

> Hi,
>
> Using the MCI, I've successfully played an ADPCM sample from Wikipedia, except
> at the very end of IMA ADPCM play:
> fixme:wavemap:wodWrite Not all src buffer has been written, expect bogus sound
> After play status length increased from 13813 to 13826! How comes?
>
> However, playing an ULAW sample, the same message occurs constantly (apparently
> once for each wavehdr played) and the sound is awfully chopped. The error could
> be anywhere (MCI, WAVE_MAPPER, gsm711 ACM, waveaudio ...).
>
> Are there audio tests in Wine beside winmm/wave.c?
> How is ulaw / how are the msacm/gsm711/gsm722/gsm602 tested?
>
> Does anybody know whether ULAW works in Wine? (Any app that uses it outside of MCI?)
>
> Thanks,
>  Jörg Höhle
>  

IIRC, I never tested µ-law wave file, so it may well be that the ACM
converter is broken
A+

--
Eric Pouech
"The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

[Joerg-Cyril.Hoehle]

Hi,

>IIRC, I never tested µ-law wave file, so it may well be that the ACM
>converter is broken

What is the policy for including sample multimedia files in Wine?
E.g., I remember tests being skipped because msrle.avi is not present:
http://www.winehq.org/pipermail/wine-devel/2008-October/070112.html

It is not acceptable that µ-law code bit-rots because of lack of continuous
testing (assuming it worked the day it was checked in).

Regards,
 Jörg höhle

[Eric Pouech-5]

Joerg-Cyril.Hoehle@... a écrit :

> Hi,
>
>  
>> IIRC, I never tested µ-law wave file, so it may well be that the ACM
>> converter is broken
>>    
>
> What is the policy for including sample multimedia files in Wine?
> E.g., I remember tests being skipped because msrle.avi is not present:
> http://www.winehq.org/pipermail/wine-devel/2008-October/070112.html
>
> It is not acceptable that µ-law code bit-rots because of lack of continuous
> testing (assuming it worked the day it was checked in).
>
> Regards,
>  Jörg höhle
>
>
>  

actually, you can add a (small) wave file in the test program (and
create on the fly the needed file)
we already test some .exe this way in winetest

A+

--
Eric Pouech
"The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

[Joerg-Cyril.Hoehle]

Hi,

Eric Pouech wrote:
>> It is not acceptable that µ-law code bit-rots because of
>lack of continuous
>> testing (assuming it worked the day it was checked in).

>actually, you can add a (small) wave file in the test program (and
>create on the fly the needed file)
>we already test some .exe this way in winetest
One could do without real .wav files:

Wine would benefit from a test in msacm32/tests/ sketched as follows:
0. choose some base frequency like 11025Hz;
1. generate a PCM sine wave tone (like winmm/tests/wave.c);
2. convert it to µ-law via the ACM functions;
3. play it via winmm if wine_interactive is set (like in wave.c)
4. convert it back and apply some delta function to tell if it's
   close enough to the original sine,
   i.e. mechanically verify that the round-trip worked.
5. repeat 2-4 for
 - ADPCM
 - IMAADPCM
 - GSM6.10 (is available)
 - ....
 - actually, better enumerate all ACM converters and call them in turn
   rather than hard-code a fixed set of them.

I'll not write that, as the MCI will probably keep me busy until the end of the year.

Any volunteer who wants to provide this?

Regards,
        Jörg Höhle.

[Damjan Jovanovic-2]

On Tue, Nov 3, 2009 at 3:33 PM,  <Joerg-Cyril.Hoehle@...> wrote:

> Hi,
>
> Eric Pouech wrote:
>>> It is not acceptable that µ-law code bit-rots because of
>>lack of continuous
>>> testing (assuming it worked the day it was checked in).
>
>>actually, you can add a (small) wave file in the test program (and
>>create on the fly the needed file)
>>we already test some .exe this way in winetest
> One could do without real .wav files:
>
> Wine would benefit from a test in msacm32/tests/ sketched as follows:
> 0. choose some base frequency like 11025Hz;
> 1. generate a PCM sine wave tone (like winmm/tests/wave.c);
> 2. convert it to µ-law via the ACM functions;
> 3. play it via winmm if wine_interactive is set (like in wave.c)
> 4. convert it back and apply some delta function to tell if it's
>   close enough to the original sine,
>   i.e. mechanically verify that the round-trip worked.

You'd need to verify the energy in the discrete Fourier transform of
the signal at the frequency you're testing for, is say 90% of the
total signal energy.

wave.c however does this instead:

    if (winetest_interactive && (device != WAVE_MAPPER))
    {
        trace("Playing a 5 seconds reference tone.\n");
        trace("All subsequent tones should be identical to this one.\n");
        trace("Listen for stutter, changes in pitch, volume, etc.\n");

...which is a human verification not an automated one...

And recording from the microphone while playing seems like bad news,
surrounding noise levels are unpredictable, hardware might not be
present, etc.

Any other idea how to play and record without using the microphone?
Maybe we should test against the implementation in a tool like sox
instead?

> 5. repeat 2-4 for
>  - ADPCM
>  - IMAADPCM
>  - GSM6.10 (is available)
>  - ....
>  - actually, better enumerate all ACM converters and call them in turn
>   rather than hard-code a fixed set of them.
>
> I'll not write that, as the MCI will probably keep me busy until the end of the year.
>
> Any volunteer who wants to provide this?

> Regards,
>        Jörg Höhle.
>
>
>

Damjan Jovanovic

[David Laight]

On Tue, Nov 03, 2009 at 07:48:29PM +0200, Damjan Jovanovic wrote:

> On Tue, Nov 3, 2009 at 3:33 PM,  <Joerg-Cyril.Hoehle@...> wrote:
> >
> > Wine would benefit from a test in msacm32/tests/ sketched as follows:
> > 0. choose some base frequency like 11025Hz;
> > 1. generate a PCM sine wave tone (like winmm/tests/wave.c);
> > 2. convert it to ?-law via the ACM functions;
> > 3. play it via winmm if wine_interactive is set (like in wave.c)
> > 4. convert it back and apply some delta function to tell if it's
> > ? close enough to the original sine,
> > ? i.e. mechanically verify that the round-trip worked.
>
> You'd need to verify the energy in the discrete Fourier transform of
> the signal at the frequency you're testing for, is say 90% of the
> total signal energy.

Or use a goertzel detector for the transmitted tone(s).
It is also quite simple to generate sine waves without any trig.

        David

--
David Laight: david@...

[Nicklas Börjesson-2]

>Or use a goertzel detector for the transmitted tone(s).
>It is also quite simple to generate sine waves without any trig.

Just another, less advanced, idea,

Even easier would making a really slow square wave(~0.5 Hz) that follows a simple pattern, like 80, 80, 80, -80, -80, -80, 80, 80, 80...for 5 seconds.
Then one would easily be able to find the signal in the data without any advanced tricks.
Just (signal<0) or not for a specified period would suffice as detection.
Maybe stutter and sound quality would not be tested, however it would be a simple first step.

BTW, wouldn't stutter affect a straight line as much as it would a sound wave?
If you know that the wave isn't a wave but is supposed to follow a straight line, wouldn't then all deviations be stutter?
The soundsystem doesn't treat a stream of similar bytes any different from a sine wave, does it?

Of course, this will obviously not work through a microphone, but I can't see how that loop would be relevant to test. Being hardware and all.

//Nicklas

[Joerg-Cyril.Hoehle]

Hi,

>1. generate a PCM sine wave tone (like winmm/tests/wave.c);
Actually any repetitive signal may not be good enough for general purpose,
sine or square.  Perhaps add some change in volume?

For instance, there currently is a bug somewhere that causes Wine to
repeat the first second of an intro animation's sound (bug #18182, comment #3)
instead of continuing.  This would probably not be detected.

Also, the µ-law speech sample I fed to the MCI produces
stuttering.  Perhaps that would not be heard with a sine wave,
if the periods match.

Still it's better to have a test than currently no test at all!

>It is also quite simple to generate sine waves without any trig.
Code for sine is already in winmm/tests/wave.c  No need to reinvent.

Regards,
        Jörg Höhle

[Gert van den Berg-4]

On Wed, Nov 4, 2009 at 12:48,  <Joerg-Cyril.Hoehle@...> wrote:

> Hi,
>
>>1. generate a PCM sine wave tone (like winmm/tests/wave.c);
> Actually any repetitive signal may not be good enough for general purpose,
> sine or square.  Perhaps add some change in volume?
>
> For instance, there currently is a bug somewhere that causes Wine to
> repeat the first second of an intro animation's sound (bug #18182, comment #3)
> instead of continuing.  This would probably not be detected.
>
> Also, the µ-law speech sample I fed to the MCI produces
> stuttering.  Perhaps that would not be heard with a sine wave,
> if the periods match.
>

A chirp (frequency sweep) might help for most of these issues?
(Another sound with volume sweeps might be needed for other issues?)

Chirps are quite easy to generate. (I'm not familiar with Wine's code
yet though...)

http://en.wikipedia.org/wiki/Chirp

Gert