On Jul 23, 2004, Francois Gouget wrote:
The patch removes the primary buffer's 'volpan' variable and instead uses waveOutGetVolume() on dsound->hwo to get the current volume.
This seems to be failing for me here on three different machines during the primary part of test_secondary() in dsound/tests/ds3d.c.
You can see evidence of this in valgrind logs, e.g. http://kegel.com/wine/valgrind/logs-2007-12-06/vg-dsound_ds3d.txt or http://kegel.com/wine/valgrind/logs-2008-06-16/vg-dsound_ds3d.txt you can see valgrind getting annoyed that waveOutGetVolume didn't actually retrieve anything: Conditional jump or move depends on uninitialised value(s) at DSOUND_AmpFactorToVolPan (mixer.c:66) by PrimaryBufferImpl_GetVolume (primary.c:646) by test_secondary (ds3d.c:864) by dsenum_callback (ds3d.c:1303) by DirectSoundEnumerateA (dsound_main.c:315) by ds3d_tests (ds3d.c:1324) by func_ds3d (ds3d.c:1344) by run_test (test.h:449) by main (test.h:498) Uninitialised value was created by a stack allocation at PrimaryBufferImpl_GetVolume (primary.c:627)
The test nevertheless happens to succeed on some machines, but not others. One machine it fails on (even without valgrind) says ds3d.c:896: Test failed: The primary pan changed from 673 to 656 because, I think, it's calculating the pan based on random values on the stack.
A +dsound,+alsa,+wave log (and a few extra trace statements) shows
trace:dsound:PrimaryBufferImpl_GetPan (0x132258,0x32fa48) trace:wave:ALSA_wodMessage (0, WODM_GETVOLUME, 00000000, 0032F8E4, 00000000); trace:wave:wodGetVolume (0, 0x32f8e4); trace:wave:wodGetVolume wDevId 0, hctl (nil) trace:alsa:ALSA_CheckSetVolume line 470; hctl (nil) trace:wave:wodGetVolume CheckSetVolume failed; rc 8 trace:dsound:DSOUND_AmpFactorToVolPan (0x32f8c8) trace:dsound:DSOUND_AmpFactorToVolPan left=3b34, right=7e59 trace:dsound:DSOUND_AmpFactorToVolPan Vol=-611 Pan=656 ds3d.c:896: Test failed: The primary pan changed from 673 to 656
ALSA_CheckSetVolume returns right early because hctl is NULL.
I threw together a small test illustrating the problem; see the attached patch and log from problem machine. (Note that sound works on this machine, and running the main ds3d tests with WINETEST_INTERACTIVE=1 yields many tones in the headphones.) Could somebody who knows this code have a look? Thanks! - Dan