Substained 10ms periods in Wine audio?

[Joerg-Cyril.Hoehle at t-systems.com]

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