Bug 1279953 - Bluetooth headsets do not work
Bluetooth headsets do not work
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: linux-firmware (Show other bugs)
26
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: David Woodhouse
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-11-10 10:09 EST by Nathaniel McCallum
Modified: 2017-09-21 07:57 EDT (History)
18 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-09-21 07:57:28 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
bluez logs during the connection process (90.17 KB, text/x-vhdl)
2017-01-23 10:50 EST, Nathaniel McCallum
no flags Details
bluetoothd -d logs (16.49 KB, text/plain)
2017-01-23 12:28 EST, Kevin Fenzi
no flags Details
bluetooth -d logs (50.55 KB, text/x-vhdl)
2017-01-23 14:05 EST, Nathaniel McCallum
no flags Details
pulseaudio-vvvv-log.txt (252.18 KB, text/plain)
2017-01-23 14:18 EST, Kevin Fenzi
no flags Details

  None (edit)
Description Nathaniel McCallum 2015-11-10 10:09:41 EST
Pairing works successfully. However, the device does not show up in the sound settings. Restarting pulseaudio makes it show up in the sound settings. However, no sound actually gets routed to the device when selected (either in HFP or A2DP mode).

I have tried this on multiple computers with multiple bluetooth headsets. All exhibit the same problems.
Comment 1 Jan Kurik 2016-02-24 08:56:12 EST
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle.
Changing version to '24'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase
Comment 2 Nathaniel McCallum 2016-10-13 11:30:55 EDT
I have found a workaround. If you turn on the bluetooth headset and it auto-connects it doesn't work. But if you open the bluetooth preferences in gnome and manually disconnect and reconnect, everything works properly.

I'm thus moving this to bluez.
Comment 3 Kevin Fenzi 2017-01-22 16:55:18 EST
I am hitting this here too, but the workaround doesn't work for me. ;( 

I am not sure where the problem actually is. I downgraded bluez and it still was happening.

Happy to help debug, this is quite an anoying little bug...
Comment 4 Don Zickus 2017-01-23 10:21:29 EST
Hi,

Can you edit /usr/lib/systemd/system/bluetooth.service and
add a '-d' to

ExecStart=/usr/libexec/bluetooth/bluetoothd

like

ExecStart=/usr/libexec/bluetooth/bluetoothd -d

save/exit and restart bluetooth with

systemctl daemon-reload
systecmtl restart bluetooth


Then try and auto-connect and watch it fail.

capture and attach the logs

journalctl -S today > /tmp/logs

That should hopefully be a good start.

If it stays connected, then bluetooth found a sound profile to use
and everything is fine from bluetooth's perspective.  We will see
what the logs say.

Cheers,
Don
Comment 5 Nathaniel McCallum 2017-01-23 10:50 EST
Created attachment 1243637 [details]
bluez logs during the connection process
Comment 6 Nathaniel McCallum 2017-01-23 10:51:53 EST
Here's an update. I'm currently running on rawhide. The device appears to connect, but doesn't show up as an audio input/output option at all.
Comment 7 Nathaniel McCallum 2017-01-23 10:52:48 EST
No selinux denials are generated. It simply doesn't work.
Comment 8 Kevin Fenzi 2017-01-23 12:28 EST
Created attachment 1243736 [details]
bluetoothd -d logs

Here's my logs from bluetoothd -d

This is my restarting it with -d, then turning on the headset, letting it connect then going into the gnome sound prefs, changing the output to it and trying to play the test sound (with no sound appearing), then turning it off.
Comment 9 Nathaniel McCallum 2017-01-23 13:13:48 EST
I would imagine that the workflow for bluetooth headsets is probably the most common use of bluetooth. I think it would be great if we could define a Fedora QA test for this workflow.
Comment 10 Don Zickus 2017-01-23 13:44:38 EST
Hi Kevin,

Your logs seem to indicate everything connected fine.  Even the audio plugin accpeted the headphones.  Then after 30 seconds or so, the kernel received an event that your headset disappears on its own.  Either low battery or some other strangeness.  It does not appear to be the laptop?? doing the disconnecting.

Perhaps change the battery or recharge the headphones?

Cheers,
Don
Comment 11 Don Zickus 2017-01-23 13:46:03 EST
Hi Nathan,

I now have a wireless lab where we can test bluetooth devices.  I will work with folks to see if we can set that up along with bluetooth mice.  You are right, we should be better than this.

Cheers,
Don
Comment 12 Kevin Fenzi 2017-01-23 13:48:04 EST
No, that was me turning off the headset. ;) It has no power issues. 

Just during that 30 seconds that it was connected and set as the source/sink (with headset profile) it didn't work. No sound came out of it. The test sound did not play, other sound playing/recording things just hang and don't play or record anything. 

Would it be useful to connect it and play something on the other profile, then switch to headset? or is this just indicating that it's all at some other level where the problem is?
Comment 13 Don Zickus 2017-01-23 13:49:17 EST
Hi Nathan,

I forgot to responsd in the other comment, reviewing your logs seems to indicate everything started off ok, but for some reason the audio plugin just never fired to connect the headphones to pulseaudio.  During the restart of bluetooth the audio plugin connected to the headphones, but the headphones were still in a disconnected state while the daemon continued its connection process.

Could you turn off the headphones, restart bluetooth daemon, wait about 10 seconds for that to complete, then re-enable the headphones and submit those logs to me to see what is going on there?

Cheers,
Don
Comment 14 Don Zickus 2017-01-23 13:52:43 EST
Hi Kevin,

This could be at a different level.  The logs indicate everything including the audio sink connected and setup properly.  We might have to setup btmon to see if any traffic is happening.  Maybe it is stuck in pulseaudio.

I have also seen strange selinux issues recently.  Does 'setenforce 0' change the behaviour?

Cheers,
Don
Comment 15 Nathaniel McCallum 2017-01-23 13:56:00 EST
(In reply to Don Zickus from comment #13)
> Hi Nathan,
> 
> I forgot to responsd in the other comment, reviewing your logs seems to
> indicate everything started off ok, but for some reason the audio plugin
> just never fired to connect the headphones to pulseaudio.  During the
> restart of bluetooth the audio plugin connected to the headphones, but the
> headphones were still in a disconnected state while the daemon continued its
> connection process.
> 
> Could you turn off the headphones, restart bluetooth daemon, wait about 10
> seconds for that to complete, then re-enable the headphones and submit those
> logs to me to see what is going on there?

No problem. Doing it now.

Regarding a bluetooth headset test, we should probably do something like the following:

1. Pair device.
2. Audio should play over A2DP by default.
3. Use a VOIP app (or maybe bluejeans.com) and make sure A2DP => HSP happens.
4. Stop using VOIP and make sure HSP => A2DP happens.
5. Check media buttons on the headset (play, pause, back, forward).
6. Power cycle the headset. Make sure device auto-connects.
7. Run all the tests again.
Comment 16 Nathaniel McCallum 2017-01-23 14:05 EST
Created attachment 1243749 [details]
bluetooth -d logs
Comment 17 Nathaniel McCallum 2017-01-23 14:09:14 EST
13:58:39 - Restart bluetoothd
14:00:16 - Turn on headset
 ... NO AUDIO DEVICE APPEARS IN CONTROL CENTER ...
14:01:21 - Turn off headset
Comment 18 Kevin Fenzi 2017-01-23 14:17:54 EST
(In reply to Don Zickus from comment #14)
> Hi Kevin,
> 
> This could be at a different level.  The logs indicate everything including
> the audio sink connected and setup properly.  We might have to setup btmon
> to see if any traffic is happening.  Maybe it is stuck in pulseaudio.

Could be yeah. I did try downgrading pulseaudio with no luck, but it could be still something in there. I will attach a pulseaudio -vvv log.
 
> I have also seen strange selinux issues recently.  Does 'setenforce 0'
> change the behaviour?

No change with permissive. ;(
Comment 19 Kevin Fenzi 2017-01-23 14:18 EST
Created attachment 1243751 [details]
pulseaudio-vvvv-log.txt

Here's a pulseaudio log...
Comment 20 Wim Taymans 2017-01-24 03:22:42 EST
pulseaudio log seems reasonable. It gets the SCO fd, negotiates the right format and seems to be sending audio to the device without errors. Next step is probably take a more detailed log and dump the audio packets (if any). 

It could also be a quirk of the headset where it ignores all packets until it gets a magic command on the RFCOMM channel. Does this device work on any other computer/os you have (so we can check the handshake)?
Comment 21 Kevin Fenzi 2017-01-24 12:06:59 EST
(In reply to Wim Taymans from comment #20)
> pulseaudio log seems reasonable. It gets the SCO fd, negotiates the right
> format and seems to be sending audio to the device without errors. Next step
> is probably take a more detailed log and dump the audio packets (if any). 

ok. How can I do that? 
> 
> It could also be a quirk of the headset where it ignores all packets until
> it gets a magic command on the RFCOMM channel. Does this device work on any
> other computer/os you have (so we can check the handshake)?

Well, this very headset worked fine on this laptop in the past. It may have been early december since it worked, but it did work fine before. I suppose I could try a f25 live media?
Comment 22 Kevin Fenzi 2017-02-12 18:35:40 EST
ok. After a sunday afternoon of trying tons of things I finally tracked down my problem. 

linux-firmware-20161205-70.git91ddce49.fc26.noarch -> bluetooth headsets fail. 
linux-firmware-20160923-68.git42ad5367.fc26.noarch + cold boot -> bluetooh headsets work again. 

I was tripped up by needing to do the cold boot for a while but I figured it out. 

(with bad/new firmware):
% sudo journalctl -b -1 -l  | grep -i DDC
Feb 12 15:58:12 sheelba.scrye.com kernel: Bluetooth: hci0: Found Intel DDC parameters: intel/ibt-11-5.ddc
Feb 12 15:58:12 sheelba.scrye.com kernel: Bluetooth: hci0: Failed to send Intel_Write_DDC (-22)

(with older/good firmware): 
% sudo journalctl -b -l  | grep -i DDC
Feb 12 16:09:58 sheelba.scrye.com kernel: Bluetooth: hci0: Found Intel DDC parameters: intel/ibt-11-5.ddc
Feb 12 16:09:58 sheelba.scrye.com kernel: Bluetooth: hci0: Applying Intel DDC parameters completed

I'll try and file my issue upstream on kernel.org bugzilla (unless there's some better way to get intels permissions.
Comment 23 Nathaniel McCallum 2017-02-15 10:20:01 EST
(In reply to Kevin Fenzi from comment #22)
> I'll try and file my issue upstream on kernel.org bugzilla (unless there's
> some better way to get intels permissions.

Can you post the link to the upstream bug here?
Comment 24 Kevin Fenzi 2017-02-15 12:11:59 EST
Turns out it was already fixed upstream in: 
http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/commit/?id=581f24500138f5e410d51ab63b205be9a52f4c77

and jwb already pushed out a new linux-firmware package in fedora with that.
Comment 25 Nathaniel McCallum 2017-02-15 13:25:22 EST
So, some additional debugging turned out that I had two separate problems. One system I had hit the intel bug above. Another was missing the broadcom firmware altogether. Strangely, both resulted in the same symptoms.
Comment 26 Nathaniel McCallum 2017-02-15 13:26:01 EST
Earlier, I had discussed improving the user testing story of bluetooth. I discussed this with Adam Williamson at DevConf and that resulted in this bug:

https://pagure.io/fedora-qa/issue/500

The goal is to get a set of testing and debugging steps for volunteers to test before Fedora releases to make sure we don't hit some obvious bugs. It would be great to get some review on the proposed test cases. Hopefully Don can provide us with a debugging wiki page to go with the tests (as requested in the bug).

I think this will go a long way towards increasing the quality of our BT UX.
Comment 27 Fedora End Of Life 2017-02-28 04:50:27 EST
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.
Comment 28 Peter Robinson 2017-05-16 09:57:58 EDT
So i think this is a firmware issue in both cases and is now fixed?
Comment 29 Andre Dietisheim 2017-09-17 16:56:15 EDT
(In reply to Nathaniel McCallum from comment #2)
> I have found a workaround. If you turn on the bluetooth headset and it
> auto-connects it doesn't work. But if you open the bluetooth preferences in
> gnome and manually disconnect and reconnect, everything works properly.
> 
> I'm thus moving this to bluez.

I experience comment #2 on FC26 with a Sony MDR-XB950BT. 
If the headset is discovered and automatically connected, the output profile ("Output" tab in Sound settings, "Profile" combo) is pre-selected to "Headset Head Unit (HSP/HFP)". No sound is hearable in the headset though. 
Switching the profile to "High Fidelity Playback (A2DP Sink)" is executed as in UI/Combo but there's still no sound in the headset. Switching to other tabs like "Input" makes the profile return to "Headset Head Unit (HSP/HFP)". Disconnecting the headset manually and re-connecting it helps. Switching to A2DP works and one can finally enjoy sound over the headset.
Comment 30 Nathaniel McCallum 2017-09-18 11:34:40 EDT
Things are working for me now in F26 and rawhide. At the least, this bug shouldn't be needinfo on me.

Note You need to log in before you can comment on or make changes to this bug.