I've spent a while studying the snoop/syslogs and Bluez source, and I believe I've narrowed down the issue.
* From the Headset-Initiated snoop, we can see where the headset connected the ACL (23:54:47 UTC), followed shortly by connecting HFP (successfully). * Very soon after the headset connected HFP, the PC/bluez initiated an AVDTP connection, a bid to connect A2DP -- this is unfriendly behaviour, since the general convention is: whomever created the ACL gets to create the profiles. Or at least is given enough time to connect them, before the other end starts its own attempt. The result of this behaviour is that the headset, probably getting ready to connect A2DP itself, now gets confused by this incoming PC connection, its firmware apparently not strong or flexible enough to handle this A2DP crossover scenario, manifesting as follows: That AVDTP channel (for A2DP signalling) does get established, but then strange behaviour is seen while setting up the media-channel -- the headset takes 3s to respond to the AVDTP_DISCOVER command. These 3s end up being costly because... * The PC creates a SCO connection to the headset around this time -- I believe this is because the PC must route my current audio stream somewhere, and since A2DP media isn't setup yet after all this time, it (PulseAudio?) will settle for HFP/SCO. (Even this SCO connection takes 5s to complete, headset still not out of the woods.) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1941977 Title: PC streams music over low-quality HFP/SCO connection, instead of A2DP/AVDTP To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1941977/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
