brainstorm: what are the audio stumbling blocks?

[Maarten Lankhorst]

Hey Joerg,

Op 27-01-12 16:35, Joerg-Cyril.Hoehle at t-systems.com schreef:
> Maarten,
>
> thank you for participating!
>
>>> Provide a hidden API in mmdevapi?
>> No need, you know how mmdevapi behaves, you can write it in such a
>> way without adding latency by using GetCurrentPadding or the clock.
> I don't know what you mean.  What I mean is follows:
>
> mmdevapi has no notion of rewinding.
> Rewinding is what PulseAudio recommends to master latency:
> http://0pointer.de/blog/projects/guide-to-sound-apis.html
> "Use snd_pcm_rewind() if you need to react to user input quickly.
>   Do not assume that snd_pcm_rewind() is available and works and to which degree."
>
> Let's say DSound uses a 200ms primary buffer.  It can (and I believe
> Wine's DSound did that) mix all of the playing secondary buffers and
> feed 200ms of samples to ALSA.
> Effect: 200ms audio playing with nothing else to do.
>
> Now let' suppose after 50ms, Play is invoked on an explosion buffer.
> DSound can query the hw pos and remix the remaining 150ms (or 140 to
> play safe) to include that noise.  With ALSA, it can do so
> - either by using snd_pcm_rewind or
> - via direct access to the ALSA buffer (mmap).
>
> The key point is that DSound's model (the HW buffer) is compatible
> with both feeding arbitrary large amounts of data in advance *and*
> quickly adding sounds with as little latency as possible.
>
>
> Enters mmdevapi.  No rewinding.  A Release'd frame will be played,
> unless you Stop and Reset.
>
> If you Release 200ms of data now, additional samples can only be heard
> afterwards.  The solution so far: write next to nothing in advance --
> 10ms! -- and rely on super fast interrupt&  wake-up to reliably submit
> another 10ms just in time.
>
> Assessment: failure.
> Wobbling sound and underruns reported in bugzilla.
> No wonder MS sells w7 with new machines only.  The old ones
> can't stand the 10ms interrupt rate.
I'm fairly confident older machines handle that properly too. Just 
requires properly written drivers.
Windows vista was a lot more bloated than 7.
I wouldn't count on rewinding for alsa either, I'm not even sure if dmix 
finally supports it or not, buffer slightly more data instead. I think 
this is what IAudioClient::GetStreamLatency is meant for.

> Alternatives:
>
> A. Every DSound secondary buffer gets its mmdevapi stream.
>     DSound::Play immediately calls IAC::Start.
>
> Some says this is not useable because every mmdevapi stream maps 1:1 to
> snd_pcm_open and it's rumoured that cards would not support the
> amount of simultaneous connections corresponding to the number of
> secondary buffers that DSound apps typically use (rumour has it over
> 20).  Again, DSound is not my domain of expertise.
Doesn't work on streams where you can alter the frequency..
> That's why I've been arguing in bug #29531 that mmdevapi implements
> its own mixer.  ALSA would only see one connection.
> How to implement that mixer?  Now we circled once and are back at the
> above point about rewind/mmap.
>
> B. Special DSound hooks that bypass mmdevapi's streaming design,
>     allowing to both write 200ms of data in advance and overwrite part
>     of it as needed -- hidden API or COM interfaces.
>
> C. Other?
>
> Well, that was the old DSound.  XAudio2 ("the rage bug #28723")
> apparently goes the "every 10ms" route, hence Wine needs to support
> that in any case.
>
> I've repeatedly argued that the fact that an app may may use 10ms (and
> risk gfx and sfx glitches and write 3GHz quadcore as min. requirement
> on the back of the DVD cover) should not cause apps using 200ms
> buffers to suffer glitches.  How to meet both ends?
Or just fix things properly and use rtkit for time critical threads,
the real problem would be context switches with wineserver. The
extra task switches and reliance on the scheduler to get
things right could cause more problems..

~Maarten