[pulseaudio-tickets] [Bug 97799] Discontinuity in the interpolated delay after corking, flushing and uncorking.

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=97799

--- Comment #14 from Niklas Haas <bugs.freedesktop at haasn.xyz> ---
> Did you interpret my message so that I was asking you questions about the
> ordering of something? I did no such thing.

No, I was just pointing out that care needs to be taken when making assumptions
about what order various calls happen in. Although I now realize the point you
were making is independent of the order of events because it does not concern
the delay measurement, just the seek mode.

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

Here is my code for reference:

diff --git a/audio/out/ao_pulse.c b/audio/out/ao_pulse.c
index 5a68553..a02ccb3 100644
--- a/audio/out/ao_pulse.c
+++ b/audio/out/ao_pulse.c
@@ -62,6 +62,9 @@ struct priv {
     char *cfg_sink;
     int cfg_buffer;
     int cfg_latency_hacks;
+
+    // XXX testing
+    bool want_reset;
 };

 #define GENERIC_ERR_MSG(str) \
@@ -518,9 +521,15 @@ static void cork(struct ao *ao, bool pause)
 static int play(struct ao *ao, void **data, int samples, int flags)
 {
     struct priv *priv = ao->priv;
+    enum pa_seek_mode seekmode = PA_SEEK_RELATIVE;
+    if (priv->want_reset) {
+        seekmode = PA_SEEK_RELATIVE_ON_READ;
+        priv->want_reset = false;
+    }
+
     pa_threaded_mainloop_lock(priv->mainloop);
     if (pa_stream_write(priv->stream, data[0], samples * ao->sstride, NULL, 0,
-                        PA_SEEK_RELATIVE) < 0) {
+                        seekmode) < 0) {
         GENERIC_ERR_MSG("pa_stream_write() failed");
         samples = -1;
     }
@@ -545,6 +554,7 @@ static void reset(struct ao *ao)
         !priv->retval)
         GENERIC_ERR_MSG("pa_stream_flush() failed");
     cork(ao, false);
+    priv->want_reset = true;
 }

 // Pause the audio stream by corking it on the server

Based on the way I implemented it, the stream flushing could should affect the
seek mode of exactly the next pa_stream_write and no more. play() itself
will only ever be called by a single thread, so it can't be the case that
two threads enter this code at the exact same time. But I'll add some printf
debugging to this to be sure:

...
relative
relative
relative
relative
relative
want_reset = true
relative_on_read
relative
relative
relative
relative
...

So yes, it happens in exactly that order.

I double, triple and quadruple checked (running the test multiple times for
each
case) and confirmed that the result is definitely different: With this patch
applied, I get only small spikes in ao-delay which translate to small
discontinuities of about 10-20ms in ao-dev.

If I take the exact same source code, replace PA_SEEK_RELATIVE_ON_READ by
PA_SEEK_RELATIVE in the branch I added, recompile and rerun the test, I get the
same behavior as in my first post again, which is the same behavior as without
this diff. So it isn't just down to pure chance.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/pulseaudio-bugs/attachments/20160913/f84002a1/attachment.html>