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
Joerg-Cyril.Hoehle(a)t-systems.com 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)
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
Joerg-Cyril.Hoehle(a)t-systems.com 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)
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.
On Tue, Nov 3, 2009 at 3:33 PM, <Joerg-Cyril.Hoehle(a)t-systems.com> 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
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(a)t-systems.com> 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(a)l8s.co.uk
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
participants (5)
-
Damjan Jovanovic -
David Laight -
Eric Pouech -
Joerg-Cyril.Hoehle＠t-systems.com -
Nicklas Börjesson