After disconnnecting from car bluetooth, audio is still routed to bluetooth

[Pat McGowan]

MX4 r96

This has been happening fro a few weeks
Phone automatically connects to the car, you don't have to make or receive a call
Leave the car and disconnect
Place a call
The audio starts out using the phone as expected, after a few seconds the audio switches to bluetooth
You can manually change the audio in the UI
This happens until you reboot

[Simon Fels (morphis)]

I tried to reproduce this under similar conditions with a headset as I don't have access to any carkit at the moment but didn't had success. There are two possible reasons for this:

* the device doesn't get disconnect any stays connected as device for bluez
* the device disconnects properly but the upper stack (telepathy-ofono, telephony-service, pulseaudio) doesn't recognize this correctly

I will try to get this reproduced next week with my own carkit at home.

Tiago also mentioned there was a major rework of the code part in telepathy-ofono recently (ota6?) handling these things. He will attach a package without this rework included to let us verify if this is the reason for the behavior we see here or not.

[Simon Fels (morphis)]

@Pat: I tried to reproduce this today but didn't had success.

A few more questions:

1. With "Leave the car and disconnect" you mean the phone automatically disconnects as it goes out of range or do you actively disconnect the car?
2. How long did you wait to place the call after you left the car? You saw you were disconnect from the car (through the indicator)?

[Simon Fels (morphis)]

Both Gustavo and me tried to reproduce this with our cars but couldn't see the behavior Pat is describing. Waiting right now for Pat to get this reliable reproduced with verbose debug logging enabled.

[Simon Fels (morphis)]

@Pat: You had any success in reproducing this again?

[Pat McGowan (pat-mcgowan)]

yes

syslog during the event
http://pastebin.ubuntu.com/12329857/

pactl list
http://paste.ubuntu.com/12329778/

bluez-list-devices
http://paste.ubuntu.com/12329831/

[Pat McGowan (pat-mcgowan)]

turning off bluetooth does not remove the car bt from pactl list

[Pat McGowan (pat-mcgowan)]

syslog after turning bluetooth off and on again

[Simon Fels (morphis)]

What happens here is now pretty clear:

The car gets disconnected but the rfcomm/sco channels aren't. Due to that the audio card is still kept in PulseAudio which in turn lets the UI think it can still use it.

However what is not clear yet is why this happens. The attached syslog sadly doesn't show the point where the device disconnection happen. This could be a problem in bluetoothd itself failing to handle a rfcomm/sco channel disconnection or the kernel never sending the right event for this.

[Simon Fels (morphis)]

Currently trying to find a solution together with Pat for this.

[Bill Filler (bfiller)]

seems clear the fix will be bluetooth releated

[Pat McGowan (pat-mcgowan)]

Using the new bluetooth stack I have not seen this issue again on arale

fastboot flash boot boot-arale-newer-bt-stack-1.img
fastboot reboot

Now verify that the kernel is really what it should be:

$ sudo dmesg | grep Bluetooth
[ 0.198808] Bluetooth: Core ver 2.20
[ 0.198863] Bluetooth: HCI device and connection manager initialized
[ 0.198888] Bluetooth: HCI socket layer initialized
[ 0.198910] Bluetooth: L2CAP socket layer initialized
[ 0.198965] Bluetooth: SCO socket layer initialized
[ 0.867176] Bluetooth: RFCOMM TTY layer initialized
[ 0.867213] Bluetooth: RFCOMM socket layer initialized
[ 0.867248] Bluetooth: RFCOMM ver 1.11
[ 0.867277] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 0.867293] Bluetooth: BNEP filters: protocol multicast
[ 0.867319] Bluetooth: BNEP socket layer initialized
[ 0.867336] Bluetooth: HIDP (Human Interface Emulation) ver 1.2
[ 0.867361] Bluetooth: HIDP socket layer initialized

and that the hci0 device is up

$ hciconfig hci0
hci0: Type: BR/EDR Bus: UART
        BD Address: 38:BC:1A:1F:7E:96 ACL MTU: 1021:8 SCO MTU: 244:4
        UP RUNNING PSCAN
        RX bytes:716 acl:0 sco:0 events:43 errors:0
        TX bytes:1475 acl:0 sco:0 commands:43 errors:0

Then continue to use your device as normal.

[Jean-Baptiste Lallement (jibel)]

@Pat, according to your last comment you couldn't reproduce the issue with the new bluetooth stack, do you confirm that it is fixed with latest rc-proposed build?