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

Sun, Xiaodong xisun at qca.qualcomm.com
Mon Oct 29 15:25:09 PDT 2012


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. 

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

- Xiaodong

-----Original Message----- 
From: Tanu Kaskinen [mailto:tanuk at iki.fi] 
Sent: Saturday, October 27, 2012 12:57 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 Sat, 2012-10-27 at 01:46 +0000, Sun, Xiaodong wrote:
> Tanu,
> 
> Thanks for your detailed explanation of sink-input. I am clear of it 
> now.
> In term of the solution, what else would you like to suggest me to try 
> from system point of view? It seems only changing module-combine-sink 
> module is not a feasible solution.

Why not? The blocker problem seems to be that module-tunnel reports the latency wrong, and I suggested a fix for that: avoid the
pa_sink_render() call in module-tunnel.c until the latency information is available. pop_cb() in module-combine-sink.c is called by pa_sink_render(), so if pa_sink_render() is called only when the latency information is correct, then the latency information will always be correct also in pop_cb().

--
Tanu



More information about the pulseaudio-discuss mailing list