Playing ULAW sample correctly?

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]

[e-mail] 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+

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]

[e-mail] 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+

Please write audio tests (was: Playing ULAW sample correctly?)

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.

Please write audio tests (was: Playing ULAW sample correctly?)

[Damjan Jovanovic]

On Tue, Nov 3, 2009 at 3:33 PM,   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;
> - generate a PCM sine wave tone (like winmm/tests/wave.c);
> - convert it to µ-law via the ACM functions;
> - play it via winmm if wine_interactive is set (like in wave.c)
> - 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?
> - 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

Please write audio tests (was: Playing ULAW sample correctly?)

[David Laight]

On Tue, Nov 03, 2009 at 07:48:29PM +0200, Damjan Jovanovic wrote:
> On Tue, Nov 3, 2009 at 3:33 PM,   wrote:
> > Wine would benefit from a test in msacm32/tests/ sketched as follows:
> > 0. choose some base frequency like 11025Hz;
> > - generate a PCM sine wave tone (like winmm/tests/wave.c);
> > - convert it to ?-law via the ACM functions;
> > - play it via winmm if wine_interactive is set (like in wave.c)
> > - 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

Please write audio tests (was: Playing ULAW sample correctly?)

[Nicklas Börjesson]

> 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