[pulseaudio-discuss] a question about audio synchronization between local sink and tunnel sink

[Sun, Xiaodong]

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;
}

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) and server-side buffer are empty (no playback started yet).

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?

BR
Xiaodong

-----Original Message-----
From: Tanu Kaskinen [mailto:tanuk at iki.fi] 
Sent: Thursday, November 01, 2012 6:01 AM
To: Sun, Xiaodong
Cc: pulseaudio-discuss at lists.freedesktop.org
Subject: Re: [pulseaudio-discuss] a question about audio synchronization between local sink and tunnel sink

On Mon, 2012-10-29 at 22:25 +0000, Sun, Xiaodong wrote:
> Tanu,
> 
> I changed module-tunnel.c function send_data() like this:
> 
> ...
>         if (!latency_updated)
>             pa_sink_render_noise(u->sink, u->requested_bytes, &memchunk);
>         else
>             pa_sink_render(u->sink, u->requested_bytes, &memchunk); 
> ...
> 
> latency_updated is a static variable initialized to 0 and set to 1 
> when SINK_MESSAGE_UPDATE_LATENCY is processed.
> 
> I saw the same log as before: tunnel sink's latency is 0 while alsa 
> sink's latency is 0.88ms.

What's the code behind pa_sink_render_noise()? Have you checked what values stream_get_latency_callback() in module-tunnel.c receives when it's called for the first time? If the received information is wrong, then it would be nice to know why.

> The reasons I said this method won't work are:
> 
> 1. It is hard to calculate and compensate the initial latency between 
> different sinks, because the initial latency is affected by buffering 
> and it will take a while to stabilize. We don't know the time required 
> to get sink's stable initial latency, especially in tunnel sink case.

Why does it take a while to stabilize? The buffering status should be accurately reflected in all latency reports. I don't see any fundamental reason why there should be a "stabilization period".

In any case, if you really need a stabilization period, then you can generate silence in module-combine-sink's pop_cb() for a while, and only after that check what the latency is and adjust the read index of the input buffer.

> 2. Even we can get stable initial sink latency, if new sink's latency 
> is bigger than the other sink's, we use pa_memblockq_drop() to skip 
> some samples in new sink's output memblockq in order to reduce its 
> latency. But if new sink's output memblockq is empty,
> pa_memblockq_drop() will do nothing since there is no sample to drop 
> at all. Isn't it?

pa_memblockq_drop() will always move the read index forward (unless prebuffering is enabled and active, but module-combine-sink doesn't enable prebuffering for the memblockqs that it creates). If the read index becomes larger than the write index, that doesn't cause any special actions. If data is written to the queue while the write index is smaller than the read index, that data will effectively get discarded until the write index reaches the read index again. And that's the behavior we want here, so this is not a problem.

--
Tanu