The sad state of audio GetPosition

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

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).

>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.


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.


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.

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.

Regards,
 	Jörg Höhle