http://bugs.winehq.org/show_bug.cgi?id=28723
--- Comment #61 from Jörg Höhle hoehle@users.sourceforge.net 2011-11-30 08:31:47 CST ---
Found another gotcha for GetPosition
No surprise, XRUN is not handled correctly yet.
If I stop pumping the data out and start polling the value returned by IAudioClock_GetPosition - I get devpos steadily approaching the samples_ written count and stay there constantly until I pump out some more data.
Thank you. Winealsa is a little bit different. As soon as the local ALSA buffer catches an underrun, ALSA stops and both avail_update and delay freeze. Typically avail_update frozen < buffer_size; frozen delay > 0 I.e. the reported values are the last ones before underrun in XRUN=>stop mode occurs. So if there were a 2s audio network latency, GetPosition would freeze before reaching samples_written. Winealsa must account for that and IMHO bump position as needed.
- What is "gcp" here? GetCurrentPadding?
Indeed the discrete value that it must return, jumping in increments of 10ms.
more traditional-math like
Well, assuming MulDiv is like round: buffer_size = MulDiv(duration, rate, 10000000); period_size = MulDiv(period, rate, 10000000); for Wine (which shouldn't care about HDA alignments and use 10ms).
we would kind-a be "protected" from "skips" in output stream
I recently came back from a meeting where a quadcore Linux was reportedly unable to steadily handle 50ms hard deadlines until after a central part of the app was moved to (soft) real time priorities. When you know that these run above normal root priorities, regularly feeding 10ms from a user app makes me worry. Occasionaly, there would be hick-ups, up to 150ms. Often enough, they would not happen in the first hour after booting...
In general, processing data in large chunks boosts speed. Same for audio, e.g. why feed BGM ("background!") in 10ms chunks?