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

[Tanu Kaskinen]

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