[Resending message with full context due to list archive permissions
problem which is now fixed. This reply is to allow this message to make
it to the archive]
'Twas brillig, and Lin, Mengdong at 30/05/11 16:03 did gyre and gimble:
> I?m working on a Bluetooth profile switch module.
>
> When a stereo bluetooth headset is connected , it?s set to A2DP profile
> by default (s16le, 44100HZ, stereo).
>
> And then when a GTalk phone is calling in (by hooking SINK_INPUT_HOOK),
> I change the device profile to HSP. Then the phone?s input and output
> stream will be routed to the new created HSP sink and source (sample
> spec is s16le, 8000HZ, mono). The problem is that I cannot hear the
> voice from the other side of GTalk while my voice can be heard. I can
> hear occasional voice and almost silence.
>
>
>
> So I check the Gtalk input stream?s properties and there is a strange
> ?resample? step:
>
>>>list-sink-inputs
>
> ?
>
> current latency: 0.00 ms
>
> requested latency: 128.00 ms
>
> sample spec: s16le 1ch 8000Hz
>
> channel map: mono
>
> Mono
>
> resample method: ffmpeg ? Why is resampling needed? The input spec is
> same as BT ?sco? sink?s sample spec: s16le 1ch 8000Hz, channel map: mono
> Mono. Resampling seems **unnecessary**.
>
> I recorded the voice via the monitor source of the Bluetooth sink, the
> recorded data is also bad, same as what I hear.
>
>
>
> I also tried to set my headset to HSP profile once it?s connected to my
> platform and so there is no need to change profile from A2DP to HSP for
> a phone call. Then Gtalk voice is good. And I found there is no
> resampling happened to the sink input stream of GTalk, as I expected:
>
>>>list-sink-inputs
>
> current latency: 24.12 ms
>
> requested latency: 128.00 ms
>
> sample spec: s16le 1ch 8000Hz
>
> channel map: mono
>
> Mono
>
> resample method: (null)
>
>
>
> So my question is why there is the **unnessary** resampling step for the
> sink input stream after profile switch from A2DP to HSP? The resampling
> is only necessary for A2DP sink (from 8000HZ to 44100HZ) but shall be
> unnecessary for a ?sco? sink. Does the pulseaudio still have some memory
> of previous A2DP sample spec and do a harmful resampling?
It looks like it. Perhaps we need to reset the resamplers on a stream
move... I seem to recall something about that... hold on... Hmm, can't
find any reference to this... I seem to recall that there was a patch
concerting this issue but I can't seem to find it.
I guess when moving a stream, we need to recalculate the resampler to
use. It could be that this is just shown for info as in (this is the
reampler we would use if we needed any resampling) and thus it's
harmless, but the fact you cannot hear audio would suggest there is
*something* fishy going on in there.
I will need to dig into the code to have a look at this, but on a quick
glance, I think the name of the resample method is left behind after the
move, even if a resampler is not being used, but the actual resampler is
indeed freed and reset.
This patch might fix this reporting issue (a similar patch would be
needed for source-outputs too).
diff --git a/src/pulsecore/sink-input.c b/src/pulsecore/sink-input.c
index f4f3258..b8c2db3 100644
--- a/src/pulsecore/sink-input.c
+++ b/src/pulsecore/sink-input.c
@@ -1663,6 +1663,7 @@ int pa_sink_input_finish_move(pa_sink_input *i,
pa_sink *dest, pa_bool_t save) {
0,
&i->sink->silence);
}
+ i->actual_resample_method = new_resampler ?
pa_resampler_get_method(new_resampler) : PA_RESAMPLER_INVALID;
pa_sink_update_status(dest);
update_volume_due_to_moving(i, dest);
--
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/]
