http://bugs.winehq.org/show_bug.cgi?id=28517
--- Comment #23 from Jörg Höhle hoehle@users.sourceforge.net 2011-10-06 02:38:30 CDT ---
["soft underruns"] this should never happen?
That's what he wrote. My experience is different, and there are posts too about users expressing their surprise with dmix not stopping.
[#samples < period never start] Have you seen this happen?
Bug #27087, comment #12. That was before 1.3.25.
[ALSA buffer < mmdevapi period]Another ugly problem... e.g. 0.37 seconds @ 44100Hz
My memory was wrong about the 8000Hz case. The period is truly 8(!) frames, 1ms, however the buffer is large enough with 8192 frames, >1s.
I don't know the maximum allowed mmdevapi period (500ms?) In our case, I'd say a FIXME is enough for now: if (10 * alsa_buffer_time <= 12 * mmdevapi_period) FIXME("Tiny ALSA buffer %u. Expect underruns\n"); The 12/10=20% margin is because ALSA's "buffer empty" is not sync'ed with mmdevapi's feeder event.
Perhaps I should add a call to alsa_write_data() in Start().
Maybe at a later time (there's potential for underrun depending on the amount and how far away the next event tick is). For now, let's behave like what I believe the native mixer does: every 10ms it mixes all available data, nothing more. Perhaps, in shared mode, all streams start on the 10ms boundary! (I've been thinking about an audible test with two streams with 180° phase delta not written at the same time, yet they should all enter the same 10ms period and might annihilate themselves...)