http://bugs.winehq.org/show_bug.cgi?id=29531
Jörg Höhle hoehle@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hoehle@users.sourceforge.ne | |t
--- Comment #2 from Jörg Höhle hoehle@users.sourceforge.net 2012-01-15 12:19:30 CST --- The ancient winealsa module said: /* unless someone makes a wineserver kernel module, Unix pipes are faster than win32 events */ and used pipes and poll to wakeup. We don't need pipes any more since there's nothing else but the timer to wait for. However, the DeleteTimerQueueTimer features an event-based protocol to guarantee that callbacks have finished executing. We'd have to find something else should we move away from them. DSound uses timeSetEvent.
22.385...22.569:0041:err:alsa:alsa_write_data tick was masked before because we put a whole bunch of data into the ALSA buffer
Can you explain how the old code could bridge a gap of 184ms? I can't believe DSound would exhibit such a latency.
Log line 30550 shows where time jumps from 25.155 to 25.228ms. It is also a place where 3 threads 0009, 41 and 42 access DSound. mmdevapi doesn't seem involved. As a property of timeSetEvent(?), DSound's event is then signaled 8 times in a row without delay, until the situation stabilizes again and 10ms intervals are restored.
There's an even worse situation at time 18.515 - 18.939 -- 400ms! 0041:trace:dsound:DSOUND_timer entering at 18515 0041:trace:dsound:DSOUND_timer completed processing at 18939, duration = 424 No other threads are involved, but DSound is not playing at that time. I'd say the Linux scheduler simply put the task to sleep.
My conviction is not that timer queues are unreliable, rather than that our current mmdevapi design is fragile, because of the following tension: - glitch free sound wants buffers as large as possible; - we made the buffer really small in bug #28723 to support the "fill at most 10ms each turn" use case; - I mentioned in bug #28723, comment #61 that even a quadcore Linux does not manage to guarantee a steady 50ms wakeup. There will be hiccups since the introduction of the completely fair scheduler in the kernel.
I've sketched in bug #28723 an alternative design that would allow to use large(r) buffers -- when the app supplies more data. That would help winmm, but I see that CDBurnerXP uses DSound. Currently I don't know whether DSound could be designed in such a way as to behave differently from XAudio2. XAudio2 seems to use the above 10ms use case. For what DSound action games wants to do, namely offer minimal latency, that is IMHO exactly the right behaviour: write as little as possible in advance so as to produce sounds of explosions close to when they happen.
Perhaps the old DSound implementation could remix data, however mmdevapi has no concept of seeking backward. Once you submit data, it's definitive.
From there you can derive that mmdevapi is a bad backend for DSound -- unless
you equate DSound's mixer with mmdevapi's. Then you could supply large numbers of samples for glitch-free BGM. Even short-latency explosions might render glitch-free, if their sound is not computed dynamically rather than a secondary buffer that's just told to Play (=mix in now).
We might even reinvent DSound HW buffers. These use their own connection to ALSA, whereas the SW buffers all get mixed into one ALSA snd_pcm_open connection.
BTW, what happens if you revert my winealsa patch "GetPosition() using snd_pcm_delay"? Bug #29472 shows that it can interfere with DSound.