November 2009 - Wine-Devel - list.winehq.org

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

by 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

Nov. 3, 2009

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

by 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(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

Nov. 3, 2009

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

by Damjan Jovanovic

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

Nov. 3, 2009

windows chromium testsuite valgrind warnings

by Dan Kegel

For what it's worth, here are the valgrind warnings from a run of my current subset of the chromium test suite under valgrind+wine: http://kegel.com/wine/chromium/valgrind-logs/errors.html Mostly they're leaks. That's good news. For the few nonleak warnings, I already filed http://bugs.winehq.org/show_bug.cgi?id=20567 for the des one in http://kegel.com/wine/chromium/valgrind-logs/base_unittests/RSAPrivateKeyUn… http://kegel.com/wine/chromium/valgrind-logs/base_unittests/SignatureCreato… and http://kegel.com/wine/chromium/valgrind-logs/base_unittests/SignatureVerifi… and http://bugs.winehq.org/show_bug.cgi?id=20553 for the first one in http://kegel.com/wine/chromium/valgrind-logs/unit_tests/TableViewTest.log and am puzzling over the crash later in TableViewTest (though maybe once I clear up the first error, the crash will go away). The leaks aren't quite as important. I filed a few so far: http://bugs.winehq.org/show_bug.cgi?id=20544 shell32 imagelist memory leak on unload? http://bugs.winehq.org/show_bug.cgi?id=20545 memory leak in MMDRV_Init on exit? http://bugs.winehq.org/show_bug.cgi?id=20548 Memory leak in pending overlapped I/O? http://bugs.winehq.org/show_bug.cgi?id=20551 user32 clipboard memory leaks http://bugs.winehq.org/show_bug.cgi?id=20552 Memory leak in alloc_thread_tls? and http://bugs.winehq.org/show_bug.cgi?id=20549 secur32 memory leak on exit? which is already closed (it's an upstream issue and/or notabug). Of those, I'm only worried about 20548 and 20551. - Dan

Nov. 3, 2009

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

by Joerg-Cyril.Hoehle＠t-systems.com

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.

Nov. 3, 2009

Re: [PATCH 0/3] Handling DOS drives in mountmgr (try 2)

by Charles Davis

Charles Davis wrote: > Alexandre Julliard wrote: >> Charles Davis <cdavis(a)mymail.mines.edu> writes: >> >>> I thought I fixed all the issues. What's wrong with my patches now? >> Many things, it's a lot more complicated than that. For instance you >> can't just kill the fstab support, this needs to be preserved somehow, >> probably on the mountmgr side. Also you can't have a single file >> descriptor per device, you need one for each open. >> > OK, I can do that. > > I've decided to do the open in mountmgr, so I can have it handle changes > to the fstab while it's running. So, I'm working on implementing > IRP_MJ_CREATE support (which is the standard way for drivers to handle > open requests). I've attached a first stab at that. Can you take a look? > I'm pretty sure there's something I'm missing. > > BTW, I'm on #winehackers as I write this (my nick is cdavis5x). > > Chip > > Please disregard both my emails. (The second one was because my email client complained that it failed to send the email.) That patch I sent is riddled with problems. (I should know better by now, but apparently, I don't. Once again, I jumped the gun, so to speak.) I'll have a better version ready by tomorrow.

Nov. 3, 2009

Re: mshtml/tests: Fix events test when pointer is on a corner.

by Nicolas Le Cam

2009/10/30 Jacek Caban <jacek(a)codeweavers.com>: > Hi Nicolas, > > Nicolas Le Cam wrote: >> >> Hi Jacek, >> >> Thanks for feedback. >> It should handle pointer in every corners IMHO, the left corner can >> cause failures in winetest. >> >> I'll try to find a better solution. Do you have any hints ? >> > > The test in line 472 is invalid. It looks like all we can do is check if > get_x returned something. I'd suggest to set l to 0xdeadbeef before get_x > call and test that the value has changed (ok(x != 0xdeadbeef, ...)). That's > all we can do. The same applies to get_client[XY] and get_offset[XY] tests. > > > Thanks,git br > Jacek > > Hi Jacek, I did what you've suggested (patch's attached for reference) but I don't think it's the right solution. Test passes on Wine and Windows with such a patch, but we're now ignoring the fact that values are completely different on Wine (only -1 and 0) and Windows (cursor's position relative to something). I'm trying to find a way to compare values against results from GetCursorPos and friends. What do you think about that, could that be a solution ? Thanks, Nicolas Le Cam

Nov. 2, 2009

Re: eventlog tests and writing/clearing the logs

by Paul Vriens

On 11/02/2009 05:51 PM, mellery wrote: > Hi, > > Will this involve implementing advapi:RegisterTraceGuidsW, and can I > help at all? > > Thanks, > Mike Event tracing is totally different from event logging. Be my guest to pick that up ;) Maybe it's a good idea to split the advapi32/eventlog.c into eventlog.c and eventtrace.c once the tracing is fleshed out a bit more. Particularly if we move most of functionality to services.exe (as on Windows). -- Cheers, Paul.

Nov. 2, 2009

Re: eventlog tests and writing/clearing the logs

by Paul Vriens

On 11/02/2009 05:39 PM, Nikolay Sivov wrote: > On Mon, Nov 2, 2009 at 7:35 PM, Paul Vriens<paul.vriens.wine(a)gmail.com> wrote: >> >> Any thoughts on this? Correct approach? >> > > Do you plan to implement a real logging or what all of this is for? If you mean, get functional event logging into Wine, the answer is yes. -- Cheers, Paul.

Nov. 2, 2009

Re: gdi32: add testcases for copying an EMF from a NULL bitmap

by Austin English

On Mon, Nov 2, 2009 at 10:09 AM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: > On Mon, Nov 2, 2009 at 8:27 AM, Austin English <austinenglish(a)gmail.com> wrote: >> Testcase for bug 4553 > > Are you sure? I don't see any related patches here. > >> >> -- >> -Austin >> > > Why there's no wine failure in this test? Apparently part of the problem has already been fixed, as the testcase passes but the program still crashes. I sent the testcase by itself to prevent it from regressing. Actually, there was a typo in the original e-mail, it's bug 4543, see http://bugs.winehq.org/show_bug.cgi?id=4543#c17. -- -Austin

Nov. 2, 2009