wrong audio pts on push-based audio outs due to incorrect driver delay calc

[llyyr]

Important Information

Provide following Information:

• mpv version e6afc53e7cabf7d36aab4a8b25a6e2688e4449c8

Reproduction steps

Try to play audio-only files with push AOs. I could only test ao=null, ao=pulse, ao=alsa, but this should be reproducible on all of them I believe.

1. open mpv in play state so it has time to build up the audio queue

2. seek to EOF, or seek to EOF with --pause --loop (only with gapless audio but it's default)

3. the audio pts will always be off by +/- 0.2-3s, causing time-remaining to never be exactly zero or in the --loop case, it'll cause the the time-pos to be a negative value on the next loop

This is most likely because of broken delay calculation on push-based AOs.

[Traneptora]

What happens if you use --pulse-latency-hacks?

[llyyr]

That makes it worse in every way, you even start getting worse display-resample performance, it's not really needed anymore imo. Anyway, it's broken for all push AOs, not just pulse.

[DanOscarsson]

For years I have used the pulse latency hacks to get good delay - and it has word well.

To get correct playing pts you have to ask the audio driver for its delay, like is done for push based audio. You can do this for pipewire too, from what I can find, but that is not implemented in mpv. The above way to calculate delay for poll based audio will not get correct delay in some cases as it does not look at how audio is buffered inside driver and what state it is in. It will only work if everything is perfect. As end_time_us is not used for push based audio it will always be zero so the delay will be wrong with the above code. I think audio driver should always be called to get delay, if possible, so correct playing pts can be calculated. Otherwise audio/video sync will not be correct. Problems with audio or video pts at end of stream, like calculating remaining time on EOF, should be fixed in that calculation. Everything is not perfect so you have to handle small differences in expected and calculated pts values to give user best response.

[llyyr]

Yeah, I'm not convinced that the diff in the original is a possible solution anymore so I'll remove it. But the delay calculation for all push-based AOs is still wrong, and it needs some investigation as to why.

[llyyr]

This issue is now "hidden" on master by d93f53b3241a1715833f1ba28d0e7f601d085911, but the clamping doesn't work for --play-dir=- so we can still see the bug in effect when playing the file in reverse