'Twas brillig, and Lin, Mengdong at 02/06/11 10:58 did gyre and gimble:
> I?m working on a module that can switch profile for a Bluetooth headset:
> A2DP for music playback and HSP for a phone.
>
> When this module detects a sink-input-put event of a ?phone? like GTalk
> and Bluetooth is the default sink, it can change BT profile from A2DP to
> HSP if necessary. Then the A2DP sink is deleted, and the phone?s input
> stream will be routed to the new HSP Bluetooth sink.
>
> My problem is: I cannot hear good voice from the other side of GTalk, I
> get bursts of audio (about 2 seconds) followed by very long bursts of
> silence.
>
> By using pacmd, I found that Gtalk input stream is connected to the BT
> HSP sink, but GTalk input stream?s latency is ?0?, very strange. Like this:
>
>
>
>>>list-sinks
>
> index: 2
> name: <bluez_sink.00_16_44_FD_36_33.2>
> driver: <module-bluetooth-device.c>
> flags: HARDWARE HW_VOLUME_CTRL LATENCY
> state: RUNNING
> ?
> current latency: 128.46 ms
> sample spec: s16le 1ch 8000Hz
> channel map: mono
> ?
> fixed latency: 128.00 ms
>
>>>list-sink-inputs
>
> index: 3
> driver: <protocol-native.c>
> flags: START_CORKED
> state: RUNNING
> sink: 2 <bluez_sink.00_16_44_FD_36_33.2>
> current latency: 0.00 ms ? this is abnormal. How PA
> calculate this value?
> requested latency: 128.00 ms
> sample spec: s16le 1ch 8000Hz
> channel map: mono
> resample method: (null)
> client: 7 <Empathy> ? This is the frontend application of GTalk
>
> And in PA log, I saw many ?protocol-native.c: Requesting rewind due to
> rewrite?. I think this means GTalk data flow is abnormal and data is
> lost. Could anyone give me some hint? How the latency is calculated for
> a sink input? And how can the application be affected?
> I think the BT HSP sink is working well, because if I connect another
> 8KHZ mono music stream to this sink at the same time, I can hear the
> music. And that music input?s latency is non-zero:
>
> ?current latency: 1982.00 ms, requested latency: 128.00 ms?.
Ultimately the value for the sink input will come from the
PA_SINK_INPUT_MESSAGE_GET_LATENCY message (see sink-input.c).
This is calculated by:
pa_bytes_to_usec(pa_memblockq_get_length(i->thread_info.render_memblockq),
&i->sink->sample_spec)
But in the sink_input_finish_move() method, I see this:
/* Replace resampler and render queue */
if (new_resampler != i->thread_info.resampler) {
if (i->thread_info.resampler)
pa_resampler_free(i->thread_info.resampler);
i->thread_info.resampler = new_resampler;
pa_memblockq_free(i->thread_info.render_memblockq);
i->thread_info.render_memblockq = pa_memblockq_new(
0,
MEMBLOCKQ_MAXLENGTH,
0,
pa_frame_size(&i->sink->sample_spec),
0,
1,
0,
&i->sink->silence);
i->actual_resample_method = new_resampler ?
pa_resampler_get_method(new_resampler) : PA_RESAMPLER_INVALID;
}
So when you move your inputs you should have a new resmapler and thus
the render_memblockq should be rebuilt.
Now the actual implementation of pa_memblockq_get_length() is:
size_t pa_memblockq_get_length(pa_memblockq *bq) {
pa_assert(bq);
if (bq->write_index <= bq->read_index)
return 0;
return (size_t) (bq->write_index - bq->read_index);
}
So to return 0, the write_index and the read_index are likely equal.
Thus no data has likely been written yet and hence the latency is zero..
Not sure if that's a thorough analysis or not, but that's certainly my
guess.
Of course the sink itself also has a latency, but the sink input does not.
I guess there is something going on here (as you say) with the GTalk
data flow, but I'm not sure quite what... It could of course just be
GTalk itself not dealing gracefully with the latency changes (e.g.
assuming fixed latency?)
Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mageia Contributor [http://www.mageia.org/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]
