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?
Thanks
Amanda
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
