https://bugs.freedesktop.org/show_bug.cgi?id=97799
--- Comment #13 from Tanu Kaskinen <ta...@iki.fi> ---
(In reply to Niklas Haas from comment #12)
> I'm not entirely sure in which order what happens, and these things run on
> different threads. I don't know the way the audio travels up and down the
> mpv code well enough to answer ordering questions for you, though if it's
> important I could add a stats event to every call in ao_pulse to get a clear
> picture of what's going on. (And maybe reproduce it externally)
Did you interpret my message so that I was asking you questions about the
ordering of something? I did no such thing. I just stated that in this specific
case it shouldn't matter whether you use RELATIVE or RELATIVE_ON_READ on the
first write after seeking, because the read and write indexes of the stream
buffer should be the same due to the flush (and prebuffering should ensure that
the read index won't move before the first write).
Is there some uncertainty about the ordering of these calls?:
/* writes preceding the seek */
...
pa_stream_write(RELATIVE);
pa_stream_write(RELATIVE);
pa_stream_write(RELATIVE);
/* seek! */
pa_stream_cork(true);
pa_stream_flush();
pa_stream_cork(false);
/* writes after the seek */
pa_stream_write(RELATIVE_ON_READ);
pa_stream_write(RELATIVE);
pa_stream_write(RELATIVE);
...
Reading the ao_pulse code, cork/flush/uncork clearly happen in that order. The
only possible uncertainty is that is the RELATIVE_ON_READ write really the
first write after the seek.
Assuming that the ordering is as presented above, and the observations tell
that there actually is some difference between RELATIVE and RELATIVE_ON_READ,
then that indicates a bug in pulseaudio (or my understanding of the code is
just wrong).
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
_______________________________________________
pulseaudio-bugs mailing list
pulseaudio-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-bugs