So why did Bluez initiate A2DP even when the headset was the one that
established the ACL?
The bluetoothd logs help out here:
Aug 29 00:54:47 RhoPC bluetoothd[4046739]: src/adapter.c:connected_callback()
hci0 device FC:58:FA:7F:E5:18 connected eir_len 5
Aug 29 00:54:47 RhoPC bluetoothd[4046739]: src/profile.c:ext_confirm() incoming
connect from FC:58:FA:7F:E5:18
Aug 29 00:54:47 RhoPC bluetoothd[4046739]: src/service.c:btd_service_ref()
0x562f6441d710: ref=2
Aug 29 00:54:47 RhoPC bluetoothd[4046739]: src/profile.c:ext_confirm() Headset
Voice gateway authorizing connection from FC:58:FA:7F:E5:18
Aug 29 00:54:47 RhoPC bluetoothd[4046739]: src/profile.c:ext_auth()
FC:58:FA:7F:E5:18 authorized to connect to Headset Voice gateway
Aug 29 00:54:47 RhoPC bluetoothd[4046739]: src/profile.c:ext_connect() Headset
Voice gateway connected to FC:58:FA:7F:E5:18
Aug 29 00:54:47 RhoPC bluetoothd[4046739]: src/service.c:change_state()
0x562f6441d710: device FC:58:FA:7F:E5:18 profile Headset Voice gateway state
changed: disconnected -> connecting (0)
Aug 29 00:54:47 RhoPC bluetoothd[4046739]: src/service.c:change_state()
0x562f6441d710: device FC:58:FA:7F:E5:18 profile Headset Voice gateway state
changed: connecting -> connected (0)
Aug 29 00:54:47 RhoPC bluetoothd[4046739]:
src/device.c:device_profile_connected() Headset Voice gateway Success (0)
Aug 29 00:54:47 RhoPC bluetoothd[4046739]: plugins/policy.c:policy_connect()
/org/bluez/hci0/dev_FC_58_FA_7F_E5_18 profile a2dp-sink
Aug 29 00:54:47 RhoPC bluetoothd[4046739]:
profiles/audio/a2dp.c:a2dp_sink_connect() path
/org/bluez/hci0/dev_FC_58_FA_7F_E5_18
One can easily see at the end there, where something in plugins/policy.c
kicks off A2DP connection, apparently as soon as it got word that HFP
had connected.
Checking that file, the offending code seems to be this in hs_cb():
case BTD_SERVICE_STATE_CONNECTED:
/* Check if service initiate the connection then proceed
* immediately otherwise set timer
*/
if (old_state == BTD_SERVICE_STATE_CONNECTING)
policy_connect(data, sink);
else if (btd_service_get_state(sink) !=
BTD_SERVICE_STATE_CONNECTED)
policy_set_sink_timer(data);
break;
The reasoning is sound though -- if the HFP connection was locally
initiated i.e. previously in STATE_CONNECTING, then go ahead and connect
A2DP right now. Otherwise, respect right-of-way and set a timer to
connect it in around 2s, in case the headset somehow fails to do so.
The problem is, this HFP connection was NOT locally initiated. So why
was policy.c informed that it is?
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to bluez in Ubuntu.
https://bugs.launchpad.net/bugs/1941977
Title:
PC streams music over low-quality HFP/SCO connection, instead of
A2DP/AVDTP
Status in bluez package in Ubuntu:
New
Bug description:
This issue was first discovered when I got this headset 2 years back:
https://www.amazon.co.uk/gp/product/B01C2QCPYI.
STEPS
* Enable Bluetooth on the PC
* Have music or some video playing on the PC
* Power on the (already-paired) headset. It automatically connects to the PC.
EXPECTED RESULT
The PC's audio should now be streamed to the headset, over high-quality A2DP
ACTUAL RESULT
The PC's audio gets streamed over the low-quality HFP/SCO connection instead.
Stopping and resuming the stream changes nothing. I have to manually
open Blueman and right-click on the device and select "High-quality
A2DP profile", for it to switch to the expected high-quality A2DP
transport.
HCI snoop logs and verbose bluetoothd-syslogs taken in both headset-
initiated and PC-initiated connections are attached.
ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: bluez 5.53-0ubuntu3.3 [modified:
lib/systemd/system/bluetooth.service]
ProcVersionSignature: Ubuntu 5.4.0-74.83-generic 5.4.114
Uname: Linux 5.4.0-74-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.18
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: ubuntu:GNOME
Date: Sun Aug 29 03:49:08 2021
InstallationDate: Installed on 2019-06-08 (812 days ago)
InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416)
InterestingModules: rfcomm bnep btusb bluetooth
MachineType: Dell Inc. XPS 13 9380
ProcEnviron:
LANGUAGE=en_GB:en
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=en_GB.UTF-8
SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-74-generic
root=UUID=93dae559-0f0d-4e36-9318-ee7154840a9f ro
resume=UUID=01c18f00-e0eb-4891-9bf1-3110416d9b39 quiet splash
mem_sleep_default=deep vt.handoff=7
SourcePackage: bluez
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 12/14/2020
dmi.bios.vendor: Dell Inc.
dmi.bios.version: 1.12.1
dmi.board.name: 0KTW76
dmi.board.vendor: Dell Inc.
dmi.board.version: A00
dmi.chassis.type: 10
dmi.chassis.vendor: Dell Inc.
dmi.modalias:
dmi:bvnDellInc.:bvr1.12.1:bd12/14/2020:svnDellInc.:pnXPS139380:pvr:rvnDellInc.:rn0KTW76:rvrA00:cvnDellInc.:ct10:cvr:
dmi.product.family: XPS
dmi.product.name: XPS 13 9380
dmi.product.sku: 08AF
dmi.sys.vendor: Dell Inc.
hciconfig:
hci0: Type: Primary Bus: USB
BD Address: 9C:B6:D0:99:1D:20 ACL MTU: 1024:8 SCO MTU: 50:8
UP RUNNING PSCAN
RX bytes:3313120 acl:776 sco:26275 events:305102 errors:0
TX bytes:255208317 acl:298108 sco:22053 commands:6779 errors:0
mtime.conffile..etc.bluetooth.main.conf: 2020-04-27T23:21:52.866445
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1941977/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
