[pulseaudio-discuss] a question about audio synchronization between local sink and tunnel sink
Tanu Kaskinen
tanuk at iki.fi
Sat Nov 3 04:36:06 PDT 2012
On Fri, 2012-11-02 at 01:02 +0000, Sun, Xiaodong wrote:
> Tanu,
>
> This is pa_sink_render_noise():
> void pa_sink_render_noise(pa_sink*s, size_t length, pa_memchunk *result) {
> pa_mix_info info[MAX_MIX_CHANNELS];
> unsigned n;
> size_t block_size_max;
>
> pa_sink_assert_ref(s);
> pa_sink_assert_io_context(s);
> pa_assert(PA_SINK_IS_LINKED(s->thread_info.state));
> pa_assert(pa_frame_aligned(length, &s->sample_spec));
> pa_assert(result);
>
> pa_assert(!s->thread_info.rewind_requested);
> pa_assert(s->thread_info.rewind_nbytes == 0);
>
> result->memblock = pa_memblock_ref(s->silence.memblock);
> result->index = s->silence.index;
> result->length = PA_MIN(s->silence.length, length);
> return;
> }
Ok, no problems there then. (I don't understand the logic behind the
function name, but that's not important.)
> stream_get_latency_callback() in module-tunnel.c returns delay 0. I
> think it is normal because remote device current latency is 0 (event
> though fixed latency may not be 0)
Zero device latency is impossible, so if the remote device latency is
reported as 0, the report is wrong.
> and server-side buffer are empty (no playback started yet).
There's also the transport delay, which i'd expect not to be 0.
> Because tunnel sink's latency includes remote device current latency,
> server-side buffer and client-side buffer (output render buffer)
> introduced latency, its value is different when any one of them
> changes. Its initial value (the one we get after
> SINK_MESSAGE_UPDATE_LATENCY is processed) for sure is not a stable
> one. Am I wrong?
I'm not sure what you mean by "stable". Latency reports give you the
latency at a certain point in time. The device latency will inevitably
get lower and lower all the time, until more data is pushed to the
device, at which point the latency will jump up. The latency from the
buffered audio jumps up and down when the client (module-tunnel) writes
more data and when the device asks for more data. There will never be
"stable latency".
You don't need stable latency to synchronize the combine sink's streams.
You only need an accurate latency report once. It seems that the problem
is that you're not getting an accurate latency report.
--
Tanu
More information about the pulseaudio-discuss
mailing list