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:[email protected]]
Sent: Thursday, November 01, 2012 6:01 AM
To: Sun, Xiaodong
Cc: [email protected]
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
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
