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

Bug #1487889 reported by Pat McGowan on 2015-08-23
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Canonical System Image
Critical
John McAleely
bluez (Ubuntu)
Critical
Simon Fels

Bug Description

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

Changed in canonical-devices-system-image:
importance: Undecided → Critical
status: New → Confirmed
Simon Fels (morphis) wrote :

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) wrote :

@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)?

Bill Filler (bfiller) on 2015-09-02
Changed in canonical-devices-system-image:
milestone: none → ww40-2015
assignee: nobody → Bill Filler (bfiller)
Changed in bluez (Ubuntu):
assignee: nobody → Simon Fels (morphis)
importance: Undecided → Critical
Simon Fels (morphis) wrote :

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) wrote :

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

Pat McGowan (pat-mcgowan) wrote :
Pat McGowan (pat-mcgowan) wrote :

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

Pat McGowan (pat-mcgowan) wrote :

syslog after turning bluetooth off and on again

Simon Fels (morphis) wrote :

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.

Changed in bluez (Ubuntu):
status: New → Confirmed
Changed in telephony-service (Ubuntu):
status: New → Invalid
tags: added: bluetooth
Simon Fels (morphis) wrote :

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

Bill Filler (bfiller) wrote :

seems clear the fix will be bluetooth releated

Changed in canonical-devices-system-image:
assignee: Bill Filler (bfiller) → John McAleely (john.mcaleely)
Pat McGowan (pat-mcgowan) wrote :

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.

Changed in canonical-devices-system-image:
milestone: ww40-2015 → ww46-2015
status: Confirmed → In Progress
no longer affects: telephony-service (Ubuntu)
Changed in canonical-devices-system-image:
milestone: ww46-2015 → ww02-2016
tags: added: bluez5

@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?

Changed in canonical-devices-system-image:
status: In Progress → Incomplete
Changed in canonical-devices-system-image:
status: Incomplete → Fix Committed
Changed in bluez (Ubuntu):
status: Confirmed → Fix Released
Changed in canonical-devices-system-image:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments