Hi,
IMHO AudioClient_Stop must not map to snd_pcm_drop. It is more like snd_pcm_pause. Or perhaps simply lead ALSA into an underrun.
afaict pause, with reset mapped to drop,
Indeed.
IMHO, the confusion around which of pause/reset/drop/drain applies arises because Wine does not behave like mmdevapi closely enough.
All my tests converge on showing that native's processing occurs on period ticks only(?/mostly) and that it sends data to the underlying HW devices in chunks of period size frames. In particular, it does not send megabytes of data down the pipe in advance.
If Wine were to write no more than a period worth of data to ALSA/OSS/CoreAudio, then IAudioClient_Stop could do exactly what MSDN says: "This method stops data from streaming through the client's connection with the audio engine." IOW, just let the underlying device enter an underrun, which the code must handle anyway. There would be no need for any of snd_pcm_pause/drop/drain!
The need for pause etc. arises in Wine because it may feed a whole buffer (200 times! period size, e.g. 2s vs 10ms) to ALSA/OSS/CoreAudio. Ensues complexity and deviant behaviour as snd_pcm_drop is not applicable since Stop is defined *not* to throw these 2s of data away, snd_pcm_drain is not callable in non-blocking mode, snd_pcm_pause may not be supported, etc.
OTOH, I recognize that sending 2s of data down the UNIX pipe lets one sleep well and without glitches.
The question becomes: can Wine act like native's mmdevapi? Can it be guaranteed sustained rates of wake-ups every 10ms? Was too tight timing a known cause of glitches in the past such that we're very happy that mmdevapi allows a much larger buffer than period size? Is 100 wake-ups per second too much for a simple winmm:PlaySound on a laptop runing on batteries?
Note that no game will probably use 2s buffers except for BGM. It will expect tight timing and little latency (I'd say < 80ms, e.g. 2 video frames at 24fps).
On native, the question does not arise: mmdevapi is the low-level interface to audio, part of the OS. The OS will make tremendous efforts such as drive its audio engine(s) at the highest priority ("Audio Pro") (+ a couple other measures out of topic) so as to guarantee a wake-up every 10ms.
Benefits I see in equating mmdevapi periods with ALSA/OSS periods: - Get as close to ALSA/OSS recommended programming practices as possible, e.g. may even end up using a) blocking mode in the player; b) snd_pcm_wait(period) to sleep for the next relevant event instead of using a timer unrelated to actual audio throughput. - Hopefully get low response times from Linux as sleeping on an event then doing little processing fast is exactly what the kernel people recommend for threads to be scheduled timely.
Benefits I see in throwing large data in advance at ALSA/OSS: - Don't worry about glitches, let others care. - Don't care about 10ms periods for BGM, PlaySound or MCIWAVE.
Regards, Jörg Höhle