https://bugs.freedesktop.org/show_bug.cgi?id=97799
--- Comment #14 from Niklas Haas <bugs.freedesk...@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.
_______________________________________________
pulseaudio-bugs mailing list
pulseaudio-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-bugs