The sad state of audio GetPosition

[Maarten Lankhorst]

On 08/22/2011 05:31 PM, Joerg-Cyril.Hoehle at t-systems.com wrote:
> Hi,
>
> Maarten Lankhorst wrote:
>> exclusive mode wants you to fill the entire buffer at the same time.
> You're confusing this with exclusive + EVENTCALLBACK mode, which I'm not using.
> There are 4 combinations of shared/exclusive and EVENTCALLBACK or not.
> Only one of the 4 needs no GetCurrentPadding and uses a full buffer each time.
>
> So far I've only been testing without EVENTCALLBACK
> (though test_event contains some non-rendering code using it).
http://msdn.microsoft.com/en-us/library/dd370844%28v=vs.85%29.aspx

I meant an entire period then, this describes how windows handles it, my guess is that if you don't fill a period, you get
an underrun, no matter how you handle it.
>> it wouldn't surprise me if that's why it drops things..
> I'd expect GetBuffer to return AUDCLNT_E_BUFFER_SIZE_ERROR as documented for that case.
Ah true. Event driven is slightly different. :)
>
> Last week I wrote:
>> Somewhat I found the old behavior more consistent.
> Upon reflection, the new behavior is better.  It makes more sense to drop
> old frames than to keep them around thus play ghost sounds from the past.
>
> However, I'd even more prefer shared and exclusive mode to behave the same
> *and* not drop frames.
> I believe shared mode does not drop partial fills (based solely on what
> GetPosition returns) and would have expected exclusive mode to do that
> too.  I don't know why MS decided to do that but I now see
> why they recommend that programs add silence at the end of their
> sound: it works around that odd behaviour.
But it's not the same, wine doesn't officially handle exclusive mode.
Instead it might be better to just report failure and only allow shared
mode. On windows you're not required to support exclusive mode, and
you can disable exclusive mode in the audio control panel.
>
> Maarten also wrote:
>> I prefer 0 tracking, and just check the return value of snd_pcm_writei.
> I can understand that but then we need to throw rate-limiting into the
> discussion.  We are talking about GetPosition here; computing
> GetPosition solely on the base of snd_pcm_writei (let's throw in
> avail_update without delay) gives us already known bugs,
> e.g. PulseAudio backend audio 2s off video sync.
Ah true, I do think you only want to observe underruns, and not act on them in
GetPosition and GetClock, just report that all data is played. If that still breaks
pulseaudio, I think it's time to get a real pulseaudio driver..
> And without snd_pcm_delay, the sole culprit would be: Wine.
> If, OTOH, we use it, we can hope other projects will fix their bugs.
>
snd_pcm_delay would map to clock, while snd_pcm_avail maps to position,
they're not the same, so it would make sense to handle them separately.

~Maarten