[pulseaudio-discuss] HFP HF - Reject SCO Issue
Jomon John
jomon.john at tataelxsi.co.in
Thu Jun 9 16:59:52 UTC 2016
Hi,
>>>>> What does pacmd list-cards show? Is the bluez device listed there?
>>>> Yes, the bluez device is listed in the output,
>>>>
>>>> index: 1
>>>> name: <bluez_card.CC_C3_EA_0A_15_90>
>>>> driver: <module-bluez5-device.c>
>>>> owner module: 24
>>>> properties:
>>>> device.description = "Jo XT1033"
>>>> device.string = "CC:C3:EA:0A:17:97"
>>>> device.api = "bluez"
>>>> device.class = "sound"
>>>> device.bus = "bluetooth"
>>>> device.form_factor = "phone"
>>>> bluez.path = "/org/bluez/hci0/dev_CC_C3_EA_0A_15_90"
>>>> bluez.class = "0x5a020c"
>>>> bluez.alias = "Jo_XT1033"
>>>> device.icon_name = "audio-card-bluetooth"
>>>> profiles:
>>>> a2dp_source: High Fidelity Capture (A2DP Source) (priority 10, available: unknown)
>>>> headset_audio_gateway: Headset Audio Gateway (HSP/HFP) (priority 20, available: no)
>>>> off: Off (priority 0, available: yes)
>>>> active profile: <a2dp_source>
>>>> sources:
>>>> bluez_source.CC_C3_EA_0A_15_90/#2: Jo XT1033
>>>> ports:
>>>> phone-output: Phone (priority 0, latency offset 0 usec, available: no)
>>>> properties:
>>>>
>>>> phone-input: Phone (priority 0, latency offset 0 usec, available: unknown)
>>>> properties:
Now again 'pacmd list-cards' and other list commands doesn't shows the bluez source/sink in outputs during A2DP or HFP session, looks like something weired happening.
>>>> Can you check (with pavucontrol or in the logs) if the loopback from the phone goes to the correct sink?
>>>> As per the level changes shown in pavucontrol the audio from the other end of the phone reaching the bluez source, but level changes are not shown in the default sink, so i assume that the routing doesn't work between bluez source to default sink, also i didnt find much info about this on logs, what should i look for ?
>>>>
>>>>> Do you see messages in the
>>>>> pulseaudio debug log from both loopback modules?
>>>> yes, Other than the module load messages i didn't find much (oh sure, discarding all the "Could not peek into queue" and "Requesting rewind due to end of underrun" )
>>>>
>>>> [pulseaudio] module.c: Loaded "module-loopback" (index: #41; argument: "sink="bluez_sink.CC_C3_EA_0A_15_90" sink_dont_move="true" source_output_properties="media.role=phone"").
>>>> [bluetooth] module-loopback.c: Max request changed
>>>> [bluetooth] module-loopback.c: Skipping 6218 bytes
>>>> [pulseaudio] module.c: Loaded "module-loopback" (index: #42; argument: "source="bluez_source.CC_C3_EA_0A_15_90" source_dont_move="true" sink_input_properties="media.role=phone"").
>>>> [pulseaudio] module-loopback.c: Loopback overall latency is 353.36 ms + 2.50 ms + 4.62 ms = 360.47 ms
>>>> [pulseaudio] module-loopback.c: Should buffer 96 bytes, buffered at minimum 0 bytes
>>>> .
>>>> .
>>>> [pulseaudio] module-loopback.c: Loopback overall latency is 854.23 ms + 13.00 ms + 16.09 ms = 883.32 ms
>>>> [pulseaudio] module-loopback.c: Should buffer 96 bytes, buffered at minimum 0 bytes
>>>> [pulseaudio] module-loopback.c: [bluez_sink.CC_C3_EA_0A_15_90] Updated sampling rate to 8000 Hz.
>>>> [alsa-sink-HiFi wm8962-0] module-loopback.c: Max request changed
>>>> [alsa-sink-HiFi wm8962-0] module-loopback.c: Max request changed
>>>>
>>> The loopback modules should provide messages every 10 seconds. There should also be messages like
>>> [pulseaudio] module-loopback.c: [bluez_sink.CC_C3_EA_0A_15_90] Updated sampling rate to 8000 Hz
>>> for the other loopback.
>> Yes, such messages are there.
>>
>>> There you can see what sink is used for the second loopback. Underruns or "cannot peek into queue" messages should only occur at the startup of the modules but not during normal operation. Could you post the relevant parts of your log?
>> This part looks suspicious,
>>
>> D: [pulseaudio] module-loopback.c: Should buffer 96 bytes, buffered at minimum 48 bytes
>> D: [pulseaudio] module-loopback.c: [bluez_sink.CC_C3_EA_0A_17_97] Updated sampling rate to 8000 Hz.
>> I: [bluetooth] module-bluez5-device.c: FD error: POLLERR POLLHUP
>> D: [bluetooth] module-bluez5-device.c: Audio stream torn down
>> D: [pulseaudio] bluez5-util.c: Transport /card_1 state changed from playing to idle
>> D: [pulseaudio] card.c: Setting card bluez_card.CC_C3_EA_0A_17_97 profile headset_audio_gateway to availability status unknown
>> D: [pulseaudio] module-bluetooth-policy.c: Setting card 'bluez_card.CC_C3_EA_0A_17_97' to profile 'off'
>> D: [pulseaudio] module-rescue-streams.c: No evacuation sink found.
>> I: [pulseaudio] source-output.c: Freeing output 7 "Peak detect"
>> D: [bluetooth] sink.c: Requesting rewind due to started move
>>
>>
>> the complete log is pated @ http://pastebin.com/cddrcAxb
>>
> Looking at the log it seems like there is no data coming from the bluez sink.
How did you identified this ?, could you please point the associated error message.
> Is there anything in the bluetoothd log?
I didn't found anything fishy, the full bluetoothd log is pated @ http://pastebin.com/5MXugskH
> I've also seen that you load module-role-cork. Perhaps you should not
> use it at the moment, it might interfere if the stream does not have the correct role set.
Thank you, removed this.
Finally a clarification question regarding bluez_sink and bluez_source, the input from default source (mic) goes to bluez_sink and output from bluez_source routed to default sink(headphone/speaker), hence the name sink input ans source output, is this right ?
More information about the pulseaudio-discuss
mailing list