[Bug 29531] Folder navigation causes audio playback glitches in CDBurnerXP

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=29531

Jörg Höhle <hoehle at users.sourceforge.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hoehle at users.sourceforge.ne
                   |                            |t

--- Comment #2 from Jörg Höhle <hoehle at 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.

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.