mmdevapi: playing silence is introducing delays

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

Hi,

Andrew Eikum replied:
>> - Questionable use of BUFFERFLAGS_SILENT in WOD_PushData.  When no data
>>    is available now, the buffer is flooded with silence, hence data
>>    submitted shortly afterwards will be delayed by as much (PulseAudio
>>    will accumulate 2 seconds of buffer data...), not by a minimal amount.
>Are you sure? BUFFERFLAGS_SILENT shouldn't silence the whole buffer,
>just insert avail_frames worth of silence, which is what was intended.
>We should only accumulate 2 seconds if there is a 2 second underrun from
>WinMM's client. That seems like sane behavior to me.

I opened issue #27937 which is related.

This may surprise people, but I argue that winmm and mmdevapi (in rendering mode) have *no* notion of underrun.
Therefore there's nothing like "insert avail_frames of silence, which was intended" there.

- Send no data to winmm, and it will play nothing (silence). Send data again and it will start immediately (modulo HW period size).
  The API doesn't even tell you that a HW underrun occurred. You notice it indirectly when
  all your wave headers are returned...

- mmdevapi in SHARED MODE implements a mixer. Send it no data and it will mix that
  with all other currently playing sounds, possibly optimizing the case when no app sends any sound.
  Start sending data again and I *bet* it'll start immediately (modulo 10ms as the native mixer seems to operate in chunks that size).
 GetCurrentPadding of zero is an indirect indicator that an underrun likely happened (some data may still be buffered with USB devices...)

This is radically different from ALSA! Stop sending data for 10 seconds, and you need to either
 - restart or
 - quickly send 11 seconds worth of data, of which the first 10 will be ignored by ALSA!!
   Watch avail_update grow and snd_pcm_delay decrease towards minus infinity (modulo 32bit) while this happens...
   -- I wonder if that alone can explain a few issues in bugzilla where no sound is heard --
  You can even pump the late data in chunks much larger than buffer size! e.g. 10MB
  Alternatively use snd_pcm_forward.
  It is only after you filed the gap that subsequent data will be fed to the speakers again
  and you are returned to normal mode where you can't write more than buffer_size and avail_update < buffer_size.

OTOH, mmdevapi capture mode has that glitch flag. But I wasn't talking about capture here.

All in all, I think ALSA's behaviour is good for sync'ing audio with video but otherwise quite surprising.

That's why I argue that playing silence in mmdevapi is introducing delays that don't exist with native.

Regards,
 Jörg Höhle