http://bugs.winehq.org/show_bug.cgi?id=29497
Jörg Höhle hoehle@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hoehle@users.sourceforge.ne | |t
--- Comment #1 from Jörg Höhle hoehle@users.sourceforge.net 2011-12-31 10:40:03 CST --- This is possibly a duplicate of bug #29472 -- DSound erroneously using mmdevapi GetPosition -- rather than bug #29299 -- ALSA needs a full period to start.
DSound is fed 50KB of data, yet PerformMix only sends 512 frames to mmdevapi. It is perhaps confused by GetPosition returning 0 because ALSA has not yet started to play. ALSA will not start yet because it wants at least one period worth of data. DSound must nevertheless stream data into mmdevapi.
After start at time 2908ms, it is only ~1s later at time 3848ms that DSound writes another 512 frames, causing ALSA to start. Does the app then play the sound effect twice (like old bug #26878)?
AudioClient_Initialize ALSA period: 940 frames AudioClient_Initialize ALSA buffer: 3763 frames AudioClient_Initialize MMDevice period: 441 frames AudioClient_Initialize MMDevice buffer: 5120 frames
You appear to be using ALSA's rate converter plugin + dmix, running at and resampling to 48000 Hz while the app requests 44100. We'll have to keep in mind that when rounding is involved, pcm_set_periods_near(4) does not guarantee that ALSA's buffer is an exact multiple of the period size in frames. In this case, the period time is 21333.333µs (a little more than 940 frames) and ALSA computes 3763 frames, not 3764 or 3760!