katherine:
Could you try pair/connect this headset to a system with bluetooth debug log?

Seen also on the LG HSB 1100 (will merge that bug into this one)

Logs attached are from choak@'s headset.  Bluetoothd debug flag was on.

Deleted: bluetoothctl.txt 77.3 KB

bluetoothctl.txt 77.3 KB View Download

Deleted: btmon.txt 153 KB

btmon.txt 153 KB View Download

Deleted: Screenshot 2016-07-11 at 2.41.17 PM.png 122 KB

	Screenshot 2016-07-11 at 2.41.17 PM.png 122 KB View Download

Deleted: messages 802 KB

messages 802 KB View Download

 Issue 625483  has been merged into this issue.

hychao@ and I are ordering the LG HSB 1100, and will take a look at the connection problem when it arrives.

It's only Samus that seems to be affected, as I'm able to connect/use LG HBS1100 with: Android Wear (Nemo), Apple Watch, Nexus 6P, iPhone 6S, MacBook Air.

This affects all of Chrome OS, not just Samus (or at least it affects Minnie, Cyan, Celes, and Samus)

With a first look, LG HBS-1100 does not show itself as an audio device with something like Class=0x240404. It is possible that chrome browser uses this information to register an audio device with the cras audio server. Will look deeper and report.

Were we abel to determine why BLE audio devices are not being registered in proper class by Chrome? 

I believe this is the same underlying issue as  crbug.com/625886 

 Issue 625886  has been merged into this issue.

(duped and marking as P1 since a lot of people are getting hit by this)
So Chrome is not actually getting this device from Cras at all. Cras uses BlueZ to see devices get added but it only creates a new device node when BlueZ exposes an a2dp endpoint. For some reason, even though BlueZ does see the a2dp profile on the device, it doesn't expose the end-point.

I am unsure of why this happening, still investigating.

So I've figured out why this is happening but am unsure on how to fix this.
The problem is that the headphones are making a dual mode connection. So when we connect, we discover all the profiles, but right before we would connect to the profiles, there is a check to see if the address type is BREDR or LE, which is set to LE public, so we return out.

Fixing this here doesn't fix the problem. There are checks all over the code for BREDR and LE which do not account for the possibility for a dual mode connection.

Currently correcting the check in dev_connect, only leads the connecting to the profiles to fail with various different errors. It seems that setting the default btaddr_type to BREDR for all dual mode devices might be a solution, but I don't know all the ramifications that would have.


Luiz, we could use some advise here. What would you suggest we do to be able to have dual mode devices work correctly.

Why can I successfully pair and connect my headphones using bluetoothctl?

So I am able to successfully connect the QC35s and have audio working with them with a hack.

If I force the connection to pair over BR/EDR, from that point onwards, everything works fine. This doesn't work with the LG, for some reason they keep failing authentication (haven't investigated this yet).

This also causes all LE functionality to disappear though. According to dmitrygr@, we are not supposed to simultaneously open a LE and classic connection to the same device - which BlueZ is clearly doing (it does the LE Create Connection and then the Create Connection HCI commands).

Still thinking about ways to fix this - but if anyone has any ideas, please feel free to suggest something :)

So I suspect the device is advertising over LE which usually means connect over LE, but perhaps it is advertising with BR/EDR flag set which is kind strange for an A2DP device to do it. Had anyone contacted Bose to know what is their intention with this? Does it work with any other stack?

It is advertising over LE and is discoverable to inquiry. We just happen to see the LE scan first, so we try connecting over LE.

This is not just Bose, but also the LG. Both of these devices work fine with Android and Mac OS.

BTW, BlueZ sees that the device is LE and classic, since we issue both the Create Connection and LE Create Connection HCI commands.

Yep, and that probably why we get errors such as this:

2016-07-11T14:43:34.263999-07:00 ERR bluetoothd[5598]: connect error: Device or resource busy (16)

Looks like we are all fine with SDP discovery until we add the device to the whitelist, my guess is that since the device has LE as well we trigger a passive scanning which trigger the LE connection as soon as we find the device advertising which probably BR/EDR in the process.

Currently Android also connects to these headphones over bredr. We can fix the problem currently with a hack - if the device we are connecting to reports its class as an audio streaming device, we force it to connect over BR/EDR.

I've tested this with a local patch to BlueZ and it works fine with the Bose QC35s.

The LG's are unfortunately not reporting their class - so we can't do this with them. In fact, it also fails pairing because we don't try to any autopairing since we have no idea what the class of device it is. Pairing the LG with my Android phone also fails.

I'll file a separate bug for this, but the solution for the LG lies with the manufacturer. There are several things wrong with how they attempt to pair. They don't report their device class, don't report auto-accept pairing in capabilities, leaving any Bluetooth stack with very few options.

Lg Platinum pairs to Nexus 6P and Nemo just fine--Android phone and Wear. Is it possible a firmware update will resolve the chromeOS issue with LG?

I'm attempting to pair with my Nexus 6P, it fails over and over again. Could you get me a HCI snoop log of it pairing with your phone? (settings -> developer settings -> enable HCI snoop logs, then pull it by using adb - adb pull /sdcard/btsnoop_hci.log).

I also am able to pair with Nexus 6P. So odd.

I will be investigating this in BlueZ side, since I don't have any of these devices that are affected Im probably emulate them with a second controller, hopefully I can simulate the same conditions but that will probably eliminate other problems such as pairing, etc.

So for the LG, it looks like I just have a broken pair. chaok@ came by and I tested my fix and he could pair his headphones with my Chromebook.

I'll commit this fix and request merge to M-53. For the overall dual mode device issue, I'll file another detailed bug.

Awesome!

CL is out for review: https://chromium-review.googlesource.com/#/c/366816/1
Luis, let me know if this looks reasonable to send to BlueZ upstream.

I specifically want to target only audio devices since if we do this for all dual mode devices, we don't really know what will break. There could be other devices that may be depending on the connection to happen on LE.

Thanks rkc@ for making time for us to meet FTF about this and glad were able to verify that your patch fixes ChromeOS with LG Platinum! SOrry your pair is a defect. 

Chrome OS Test gave me that pair, so all good ;)

I think that LG manufactured a bunch of these that were defective (the pair that Joseph had in Taipei also did not report their class). After seeing issues in the field, they must've fixed the issue and manufactured the rest of the batches with them correctly reporting their device class.

Here is my patch proposal, this was tested with 2 controllers so it may have different outcome with the headsets so please test:

http://marc.info/?l=linux-bluetooth&m=147065287612593&w=2

The actual problem was that since we connected over LE service_accept was called and set all the BR/EDR to connecting state while they were not really connecting, with this patch this wont happen the Device.Connect will work out normally and should attempt to connect over BR/EDR if the profile require it.

Does anybody care that I have a pair of LG bluetooth headphones that work great with my Pixel 2 Samus? Do you want me to share the model number of those headphones when I get home today?

Is it specific models of LG causing issues?

Luiz, I've filed https://bugs.chromium.org/p/chromium/issues/detail?id=636078 to handle dual mode devices correctly, which includes a design doc with the various proposals and links and quotes from the relevant parts of the specs.


Till we fix this problem correctly, I would like to land our temporary fix so that for M-53, people's headphones start working at least. I am fine with this being purely a Chromium specific BlueZ patch that we won't upstream. We'll only upstream patches that will contribute to a more permanent fix to the dual-mode device issue.

That should be fixed by the following patch:

http://marc.info/?l=linux-bluetooth&m=147085615903772&w=2

So we should now prefer BR/EDR whenever it is set as supported in the advertisement flags.

Feedback sent 6PM EDT Aug 10, 2016

Bluetooth connecting and sound switching to BT headset took several tries.
Audio 66 BT sport headset

Hopefully you can see what was going on. Maybe for  Issue 615111  ?

1. open Amazon music app
2. BT is enabled in settings > start playing a playlist
3. turn on BT headset
4. settings > BT > showed the headset not connected > click on it > nothing
5. settings > volume > only speaker output
6. disabled/enabled BT
7. showed headset connecting > nothing > click on headset  > connecting again > nothing
8. headset showed in volume output settings
8. did something else and BT headset connected at some point and began sound playing from headset

Sorry feedback today Aug 11.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/bluez/+/395bca6e3d608b552d6747ac4f0bc21bddc6a469

commit 395bca6e3d608b552d6747ac4f0bc21bddc6a469
Author: Rahul Chaturvedi <rkc@google.com>
Date: Thu Aug 11 21:39:29 2016

CHROMIUM: Pair and connect over BR/EDR for Audio devices.

Audio devices that both advertise on LE and respond to BR/EDR inquiry
are susceptible to be considered LE devices, disabling their classic
profiles. This breaks a lot of newer generation headphones.

Instead, for this particular class of dual mode devices, we instead pair
and connect to them over br/edr, ensuring that the devices are able to
discover their classic profiles and play audio. With the revised patch
set, the devices will also be able to discover and see their GATT
services.

BUG= chromium:615111 
TEST=Bose QC35 and LG HBS-1100 headphones pair and audio works
correctly.

Change-Id: I5515a3da88dee88a4735e0cb38a4bd38003d326a
Reviewed-on: https://chromium-review.googlesource.com/368347
Commit-Ready: Rahul Chaturvedi <rkc@chromium.org>
Tested-by: Rahul Chaturvedi <rkc@chromium.org>
Reviewed-by: Miao-chen Chou <mcchou@chromium.org>

[modify] https://crrev.com/395bca6e3d608b552d6747ac4f0bc21bddc6a469/src/device.c

I'll test this in the next canary then request merge to 53.

Your change meets the bar and is auto-approved for M53 (branch: 2785)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/bluez/+/6e47def60e27f1e5ac178c8117d60396df5b69d4

commit 6e47def60e27f1e5ac178c8117d60396df5b69d4
Author: Rahul Chaturvedi <rkc@google.com>
Date: Thu Aug 11 21:39:29 2016

CHROMIUM: Pair and connect over BR/EDR for Audio devices.

Audio devices that both advertise on LE and respond to BR/EDR inquiry
are susceptible to be considered LE devices, disabling their classic
profiles. This breaks a lot of newer generation headphones.

Instead, for this particular class of dual mode devices, we instead pair
and connect to them over br/edr, ensuring that the devices are able to
discover their classic profiles and play audio. With the revised patch
set, the devices will also be able to discover and see their GATT
services.

BUG= chromium:615111 
TEST=Bose QC35 and LG HBS-1100 headphones pair and audio works
correctly.

Change-Id: I5515a3da88dee88a4735e0cb38a4bd38003d326a
Reviewed-on: https://chromium-review.googlesource.com/368347
Commit-Ready: Rahul Chaturvedi <rkc@chromium.org>
Tested-by: Rahul Chaturvedi <rkc@chromium.org>
Reviewed-by: Miao-chen Chou <mcchou@chromium.org>
(cherry picked from commit 395bca6e3d608b552d6747ac4f0bc21bddc6a469)
Reviewed-on: https://chromium-review.googlesource.com/371964
Commit-Queue: Rahul Chaturvedi <rkc@chromium.org>
Reviewed-by: Rahul Chaturvedi <rkc@chromium.org>

[modify] https://crrev.com/6e47def60e27f1e5ac178c8117d60396df5b69d4/src/device.c

Fixed on 53. Detecting class requires an EIR response, which can take anywhere between 3-30 seconds. I would suggest leaving discovery open for at least 30 seconds before trying to pair.

In 54, we'll do all dual mode devices so this issue should be mitigated, but for 53, this is the best we can push out.

Is there an issue to track the proper fix?

This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

THese may require new bugs, but I've finally been able to try this code commit on Canary. 
Using Version 54.0.2831.0 canary, Samus, LG Platinum 
1. It technically connects, but I think it's using the phone, not A2DP channel--the audio-quality is very low-quality and intolerable.
2. When selecting the headset via the bluetooth search list in status bar:
a. It's not possible to select the device using ENTER or SEARCH+SPACEBAR (cvox-click)
b. The device selection only occurred with SPACEBAR, which I tried out of randomness

53 is too far gone to fix this any further. I'll try to land another fix for 54. I'll update this bug.

Kevin, the issue you're describing sounds like  crbug.com/621207 
The dual mode aspect of the device should not interfere with which services are connected to.

Could you update that issue with your experiences? 

This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Further work on this is being tracked at  crbug.com/636078 .
For M-53, headphones should be fixed.

THere may have been a regression? LG HBS1100 says it's "connected/paired", but audio remains on ChromeBook.

Is this trunk, 54 or 53?

Canary 54

When I test LG HBS1100 for 543444 yesterday(bluez sync'ed to CL:368347), I see this issue reproduced once, and only once. The device state remain 'connected' but none of A2DP or HFP/HSP is connected.
If I see this happen again, I'll attach log.

It happens to me 100%, so would it be helpful if I provide logs? If so, how can logs be retrieved?

It's non-Samus specific, as I also had issue successfully connecting  LG HSB1100 to Dell ChromeBook

Is this change needed in M53?

See comment #46.

There's a workaround landed in 53 and the proper fix is in 54. 

I've tried on M54 Dev and M55 Canary, but Samus connects to LG Platinum, but audio isn't transmitted.
Is there a workaround required? I've placed the BT headsetin into pairing mode > enable CrOs BLuetooth > scan/connected to HBS1100 > tried some Audio on ChromeBOok > audio remains on Pixel 2

I can see the same issue as in #65 on samus M-54 8743.45.0 build.

Deleted: log-092916-115357.tar.gz 595 KB

log-092916-115357.tar.gz 595 KB Download

Deleted: Screenshot 2016-09-29 at 11.53.38 AM.png 184 KB

	Screenshot 2016-09-29 at 11.53.38 AM.png 184 KB View Download

Repros on: 55.0.2866.0
I've continued to use Bose SoundSports, which connect to 3.55 audio-jack, but am anxiously waiting for the day when I can use BLE audio-headset (LG Platinum).

cychiang@ has merged a few changes to address similar issue, could you try it out again on image of version > 8839.0.0 ?

1. Attempted to connect via Bluetooth device list in Status  tray, but: ENTER, SPACEBAR, and SEARCH+SPACEBAR wouldn't check the LG Platinum checkbox.
2. Was able to connect in Bluetooth list of chrome://md-settings > Advanced, but had to switch headset OFF/ON before audio-output changed. Volume-quality is quite-low, as I have to have it at 83% to be at a comfortable listening-volume. I would have expected to be able to use it at 30-50% volume.
3. Multi-point didn't auto-connect, so had to manually select LG HBS1100 on iPhone 7, but it's only in HFP, as VoiceOver/music doesn't get transmitted to headset, but phone-calls do.

Version 55.0.2878.0 canary (64-bit)
Platform 8859.0.0 (Official Build) canary-channel samus
Firmware Google_Samus.6300.174.0

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/bluez/+/39ee1df94ee1c422fe1954289bed1e12a3185f44

commit 39ee1df94ee1c422fe1954289bed1e12a3185f44
Author: Rahul Chaturvedi <rkc@google.com>
Date: Thu Aug 11 21:39:29 2016

CHROMIUM: Pair and connect over BR/EDR for Audio devices.

Audio devices that both advertise on LE and respond to BR/EDR inquiry
are susceptible to be considered LE devices, disabling their classic
profiles. This breaks a lot of newer generation headphones.

Instead, for this particular class of dual mode devices, we instead pair
and connect to them over br/edr, ensuring that the devices are able to
discover their classic profiles and play audio. With the revised patch
set, the devices will also be able to discover and see their GATT
services.

BUG= chromium:615111 
TEST=Bose QC35 and LG HBS-1100 headphones pair and audio works
correctly.

Old-Change-Id: I5515a3da88dee88a4735e0cb38a4bd38003d326a
Change-Id: I9d7425fe0cadb1d98507d38175e4574509ac4456
Reviewed-on: https://chromium-review.googlesource.com/392110
Reviewed-by: Shyh-In Hwang <josephsih@chromium.org>
Reviewed-by: Miao-chen Chou <mcchou@chromium.org>
Commit-Queue: Miao-chen Chou <mcchou@chromium.org>
Tested-by: Miao-chen Chou <mcchou@chromium.org>
Trybot-Ready: Miao-chen Chou <mcchou@chromium.org>

[modify] https://crrev.com/39ee1df94ee1c422fe1954289bed1e12a3185f44/src/device.c

Is this still reproducible with BlueZ upstream? At least the Bose AE2 SoundLink  I have seems to work just fine.

The issue of the connecting and pairing should be fixed. There still is an issue with connecting profiles correctly, which is being tracked on  crbug.com/636078 

I have this issue An unknown error occurred trying to connect to "04:52:C7:7B:26:0E". with new Bose headphones.