There is currently no HSP support in PulseAudio for BlueZ 5.

(In reply to comment #1)
> There is currently no HSP support in PulseAudio for BlueZ 5.

Given that (critical, IMHO) functionality gap/regression, is there any plan or ETA on an implementation of HSP in PulseAudio?

João Paulo Rechi Vita is working on it, or at least has been. I haven't heard anything from him for a while. There shouldn't be huge amounts of work left, since patches already exist for the functionality (and are being used in Tizen at least). Those patches just need to be ported to current master and finalized.

As for being a "critical regression", it's a distro regression, not PulseAudio regression (which you might already know, but I just wanted to make it clear here).

Is there any update on this issue?

Where would these patches that need porting to current master be?

Adding João to CC. João, could you give an update?

Brian, as far as I know, the most recent work is in the bluetooth-hf-audio-agent branch of João's git repo, which you can find here: http://cgit.freedesktop.org/~jprvita/pulseaudio/

I believe the "Tizen version" of the patches can be found here, in the tizen_devel branch: https://github.com/otcshare/pulseaudio/

There are two profiles that can be used for using bluetooth headsets with full duplex voice (low quality) audio: HSP and HFP. Most headsets out there support both of them, the difference being that HFP supports full remote call controlling while HSP supports only the Audio Channel and volume up and down.

Support for both of these profiles have been removed from BlueZ in 5.0 to be implemented as external profiles. The Handsfree Unit role (that is, the role where the speakers and mic are) of HFP is currently implemented in oFono, and I have patches to add support for routing it's audio in PulseAudio.

The Audio Gateway role (that is, the one that is producing/consuming the audio data played/recorded on the HF role) is currently not supported in oFono nor anywhere else. There should be nearly zero work to route it's audio in PulseAudio when the logic bits are implemented in oFono, but adding that logic is not trivial.

HSP logic is not implemented anywhere at the moment. The idea is to create another daemon to do so, since none of the projects already involved (BlueZ, oFono and PulseAudio) thinks that logic bits fits into its role. I want to write this HSP daemon myself, but first I have to finish upstreaming the oFono-HFP support in PulseAudio.

I'll try to summarize all the different features and their status. Please correct me if I've understood something wrong.

Feature: HFP/Handsfree Unit role
 * Use case: Connect your laptop to your mobile phone, pretending that the laptop is a headset (call downlink comes out from the laptop speakers and call uplink gets its audio from the laptop microphone).
 * Status: oFono upstream is ready, patches exist for PulseAudio (not submitted for review yet).

Feature: HFP/Audio Gateway role
 * Use case: Connect a headset to your laptop.
 * Status: Code doesn't exist for oFono nor PulseAudio.

Feature: HSP/Headset role
 * Use case: Connect your laptop to your mobile phone, pretending that the laptop is a headset.
 * Status: Code doesn't exist for PulseAudio nor whatever component would be used to implement the BlueZ profile.

Feature: HSP/Audio Gateway role
 * Use case: Connect a headset to your laptop.
 * Status: Code doesn't exist for PulseAudio nor the planned new daemon.

It seems that I had understood some things wrong. Specifically, I thought that the Audio Gateway role for HFP would be ready at the same time as the Handsfree Unit role.

Tanu's summary on comment #7 is correct.

Patches to add support for BlueZ+oFono+PulseAudio to work as a HFP head unit are already on the PulseAudio's mailing list.

The submitted patches will be reviewed after the 5.0 release.

Any progress here, or an ETA?

No progress.

I expect to get around to reviewing the patches within 2 weeks, but that's not a promise.

Is there any progress on this?

I reviewed the patches, no other progress. There are changes needed, and somebody needs to do them. My understanding is that João isn't anymore available to do the work, but Luiz von Dentz said he'd do it at some point. I added him to CC now. Luiz, would you like to comment?

Not sure about anyone else, but what I really want to know is this going to make the Fedora 21 release (train)?

http://fedoraproject.org/wiki/Releases/21/Schedule

It would be a pity for this to miss another release of Fedora since it's disappearance in the first place was an unfortunate disruption.

I realize this project is in no way supporting Fedora development but I'm just trying to ascertain if a "heads up" is needed to be made in the Fedora world about this or if there is coordination happening already.  I'm happy to go give the heads up if it's needed.  I just need to know if it's needed.

It's not clear to me which of the deadlines on the Fedora schedule are relevant, but I wouldn't count on this being ready on time for Fedora 21.

We don't have any coordination with Fedora developers that I know of.

(with my fedora maintainer/packager hat on)... no coordination other than monitoring upstream development and offering testing and feedback where appropriate.  It is indeed true there aren't currently many folks actively working to implement this, particularly none from fedora/redhat that I'm aware of.

I've been trying a couple of things to get this moving. My goal was to make audio playback work on my external bluetooth Headset. 

1) Pulseaudio registers itself as a Headset Audio Gateway to the profile manager. It then continues to set up the RFCOMM connection with the headset and hooks into some of the existing code for setting up the card/source/sinks and set up the SCO transport. See first commits of [0]

 + Selfcontained solution and simple solution.
 + can reuse some of the existing bluetooth module code
 - needs to do communicate with AT commands, many of those are not relevant to
   pulseaudio but to a telephony stack.
 - needs some fairly lowlevel socket code for setting up the SCO connection

2) Make pulseaudio use the MediaEndpoint API. See next commits of [0]

 + simulates what bluez4 used to do
 + can reuse more of the existing code
 - more complicated, needs to have either pulseaudio do all async DBus calls or
   run the MediaEndpoint/Profile in separate threads. (I did not attempt this).
 - still need to handle AT commands and socket code
 - need to punch DBus holes for calling the MediaTransport API.

3) Implement the Profile in a separate program, calling the MediaEndpoint API on pulseaudio to configure the stream. See last commits of [0] and [1] for the daemon

 + more like what bluez4 used to do, can revive old headset code
 - need to simulate old bluez4 behaviour in the new app
 - still need to handle AT commands, can't easily have telephony stack take over.
 - needs to punch DBus holes so that pulseaudio can call the app implementation of the MediaTransport API.
 - needs more SELinux permissions to be able to pass fd from new app to pulseaudio.

4) Implement new daemon that handles headsets and exposes a new DBus API to be used by pulseaudio and the telephony stack. See daemon part in [2] and pulseaudio module in [3]

 + relatively straightforward
 + we can expose API to let the telephony stack handle the AT commands
 + we can let pulseaudio handle the audio
 + separate pulseaudio module, no bluez knowledge needed
 - new API, new system daemon, DBus config, SELinux rules to pass fds.

[0] http://cgit.freedesktop.org/~wtay/pulseaudio/log/?h=hfp-gateway
[1] http://cgit.freedesktop.org/~wtay/bluez-profile/log/
[2] http://cgit.freedesktop.org/~wtay/headset-daemon/
[3] http://cgit.freedesktop.org/~wtay/pulseaudio/log/?h=headsetd

The way forward, in my opinion, is to make the headset devices available with a new DBus API. Either as a new service or through new Objects in the pulseaudio DBus service. 

A telephone stack should be able to discover and talk AT commands with the headsets but when it wants to make sound, it should go through the pulseaudio API. You might, for example, want to control the telephony stack with the handsfree headset but have the sound go somewhere else.

What do you think?

(In reply to comment #18)
> I've been trying a couple of things to get this moving. My goal was to make
> audio playback work on my external bluetooth Headset. 
> 
> 1) Pulseaudio registers itself as a Headset Audio Gateway to the profile
> manager. It then continues to set up the RFCOMM connection with the headset
> and hooks into some of the existing code for setting up the
> card/source/sinks and set up the SCO transport. See first commits of [0]
> 
>  + Selfcontained solution and simple solution.
>  + can reuse some of the existing bluetooth module code
>  - needs to do communicate with AT commands, many of those are not relevant
> to
>    pulseaudio but to a telephony stack.

Only if you are talking about HFP, in case of HSP all AT command are audio related so doing it in PA would actually make sense and in fact reduce the latency.

>  - needs some fairly lowlevel socket code for setting up the SCO connection

Well the fd passed is a already a SCO socket or you are talking about bind + listen logic? I was thinking that perhaps this could be handled by bluetoothd as well and then maybe it delivered SCO fd via a second NewConnection.


> 4) Implement new daemon that handles headsets and exposes a new DBus API to
> be used by pulseaudio and the telephony stack. See daemon part in [2] and
> pulseaudio module in [3]
> 
>  + relatively straightforward
>  + we can expose API to let the telephony stack handle the AT commands
>  + we can let pulseaudio handle the audio
>  + separate pulseaudio module, no bluez knowledge needed
>  - new API, new system daemon, DBus config, SELinux rules to pass fds.
> 
> [0] http://cgit.freedesktop.org/~wtay/pulseaudio/log/?h=hfp-gateway
> [1] http://cgit.freedesktop.org/~wtay/bluez-profile/log/
> [2] http://cgit.freedesktop.org/~wtay/headset-daemon/
> [3] http://cgit.freedesktop.org/~wtay/pulseaudio/log/?h=headsetd
> 
> The way forward, in my opinion, is to make the headset devices available
> with a new DBus API. Either as a new service or through new Objects in the
> pulseaudio DBus service. 
> 
> A telephone stack should be able to discover and talk AT commands with the
> headsets but when it wants to make sound, it should go through the
> pulseaudio API. You might, for example, want to control the telephony stack
> with the handsfree headset but have the sound go somewhere else.
> 
> What do you think?

Well this is actually what oFono has been doing so I don't see why we need another daemon, if the problem is that there is no telephony stack that can handle HFP (e.g. desktop) then HSP can be used instead.

(In reply to comment #19)
> Well this is actually what oFono has been doing so I don't see why we need
> another daemon, if the problem is that there is no telephony stack that can
> handle HFP (e.g. desktop) then HSP can be used instead.

Work is ongoing to get ModemManager to have telephony support, so this would be needed to support that case as well.

(In reply to comment #20)
> (In reply to comment #19)
> > Well this is actually what oFono has been doing so I don't see why we need
> > another daemon, if the problem is that there is no telephony stack that can
> > handle HFP (e.g. desktop) then HSP can be used instead.
> 
> Work is ongoing to get ModemManager to have telephony support, so this would
> be needed to support that case as well.

You can have your own backend for MM no problem, the thing is that for HSP none of this is required so doing it directly on PA should not interfere with whatever you guys are planning for HFP.

> 
> Only if you are talking about HFP, in case of HSP all AT command are audio
> related so doing it in PA would actually make sense and in fact reduce the
> latency.

Well almost, HSP has RING and the button press event. In practice you will use HFP but theoretically, the phone stack could also do a RING on a pure HSP headset.

> 
> >  - needs some fairly lowlevel socket code for setting up the SCO connection
> 
> Well the fd passed is a already a SCO socket or you are talking about bind +
> listen logic? I was thinking that perhaps this could be handled by
> bluetoothd as well and then maybe it delivered SCO fd via a second
> NewConnection.

I am talking about the bind + connect code. This is among things what got removed from bluez5, you say it should be added again? It's really not complicated but the main problem is that you would then need the bluez5 headers to compile the module (and if you use any of the functions, also link to bluez).

> 
> Well this is actually what oFono has been doing so I don't see why we need
> another daemon, if the problem is that there is no telephony stack that can
> handle HFP (e.g. desktop) then HSP can be used instead.

I have been looking at ofono as well but could not get this part to work. I made a litte testapp to register an AudioAgent and wait for NewConnection() but I could not make it work, no Cards showed up when I connected a headset. The API looks like it would work. What do I need for this to work?

(In reply to comment #22)
> > 
> > Only if you are talking about HFP, in case of HSP all AT command are audio
> > related so doing it in PA would actually make sense and in fact reduce the
> > latency.
> 
> Well almost, HSP has RING and the button press event. In practice you will
> use HFP but theoretically, the phone stack could also do a RING on a pure
> HSP headset.

iirc RING is BT specific meaning a Telephony stack would not do anything with it, in fact I believe RING is more of an indication to the headset to play the ringtone if inband is not supported.

> 
> > 
> > >  - needs some fairly lowlevel socket code for setting up the SCO connection
> > 
> > Well the fd passed is a already a SCO socket or you are talking about bind +
> > listen logic? I was thinking that perhaps this could be handled by
> > bluetoothd as well and then maybe it delivered SCO fd via a second
> > NewConnection.
> 
> I am talking about the bind + connect code. This is among things what got
> removed from bluez5, you say it should be added again? It's really not
> complicated but the main problem is that you would then need the bluez5
> headers to compile the module (and if you use any of the functions, also
> link to bluez).

Yep, I think we should avoid any extra dependency thus my suggestion to actually handle this in bluetoothd for HSP alone, for HFP we cannot do it because since version 1.6 it does have a much more complicated setup, one that involves codec negotiation via AT commands so the HFP entity has to have control over the SCO socket.
 
> > 
> > Well this is actually what oFono has been doing so I don't see why we need
> > another daemon, if the problem is that there is no telephony stack that can
> > handle HFP (e.g. desktop) then HSP can be used instead.
> 
> I have been looking at ofono as well but could not get this part to work. I
> made a litte testapp to register an AudioAgent and wait for NewConnection()
> but I could not make it work, no Cards showed up when I connected a headset.
> The API looks like it would work. What do I need for this to work?

Try with this one:

https://gitorious.org/pulseaudio/vudentzs-mainline/commits/fceee2a876110186f8fdc87743e3ee7f7bf8c1ae

Make sure you have compile it with --with-bluetooth-headset-backend=ofono and you must have a modem registered in oFono, apparently the modem cannot be a bluetooth one (e.g. a phone connected via BT) for some reason (possible a bug), without that oFono won't register for HFP Audio Gateway, for HFP Headset should work.

I understand that this is a development in progress, but is there any workaround that is available now? Like possibly downgrading some component to get a working combination.

You'll have to wait till our next release, most likely. If you're using GNOME 3, other system components depend on BlueZ 5, so the downgrade will not help. Hopefully you won't be waiting too long.

I just found this proposed patch on Fedora's bugzilla.
What is your opinion about this?
https://bugzilla.redhat.com/show_bug.cgi?id=1045548

If they are the same as the last 3 patches Wim posted to the mailing list (I see a lot more in the Fedora bug, but those are likely dependencies), then it should be pretty similar to what's going upstream.

This is more or less fixed in master. There's a bug with volume control that needs to be pinned down before the final 6.0 release.

Does the fix need the ofono backend?
I tried the master at commit 5dfa83385c457766954d40d8998eda028ed7d57b on Gentoo with gnome 3.12 and bluez 5.21 and without ofono.

It does recognize my Philips SHB 7000 Headset and provides the HFP profile.

But switching to it has no effect (using pavucontrol). No input device appears. Output device stays but I think it is still A2DP. When I change the profile to “off” and then to “HSP/HFP” no output device appears.

When using the gnome volume control there is a bug which leads to multiple output device entries (everytime I click on one another one appears). They are all coupled (when changing profile it is changed on everyone). But profile switching has no effect there, too.

Should I be patient and wait for the release or is there any more information I could provide?

Thanks for testing this. You don't need ofono for this to work, the card should turn up once the device is connected, with either or both of A2DP and HSP/HFP depending on what your headset supports.

Could you run the server with verbose logs (pulseaudio-k; pulseaudio -vvvv) and attach those logs?

Created attachment 108717 [details]
pulseaudio.log while pulseaudio startup

Created attachment 108718 [details]
pulseaudio.log while pavucontrol startup

Created attachment 108719 [details]
pulseaudio.log while Philips SHB7000 connect

Created attachment 108720 [details]
pulseaudio.log while Philips SHB7000 profile switch from OFF to HSP/HFP

Created attachment 108721 [details]
pulseaudio.log while Philips SHB7000 profile switch from HSP/HFP via OFF to A2DP

Created attachment 108722 [details]
pulseaudio.log while Philips SHB7000 profile switch from A2DP to HSP/HFP

I created the requested log (splitted into several files covering the steps I took).
The switch to HSP/HFP is rejected with “Refused to switch profile to headset_head_unit: Not connected”. This is not made clear to the user (me).

W: [pulseaudio] module-bluez5-device.c: Refused to switch profile to headset_head_unit: Not connected

I don't know why that would happen. Could you try disconnecting and reconnecting? Does this reliably happen every time?

Reconnect did not help. But after restarting bluetoothd, removing the coupling with the HSB7000 and recouple, pulseaudio is now able to switch to HSP/HFP and the input device occurs (and works … I did a successful Skype test call).

So it seems to me that it could be a bluez problem. I will try bluez 5.24 instead of bluez 5.21.

Now I am on bluez 5.24. Currently it works (but so did it with bluez 5.21 after restart).
The “multiple output device” bug in gnome audio control remains (it occurs when switching vom HSP/HFP to A2DP. I think it's a gnome problem. Neither pavucontrol nor the audio switch shell extension has this problem.

I will let you know if any other problems occur.

Thanks

Okay, obviously I am stuck to HSP/HFP now. When trying to switch to A2DP via pavucontrol:

W: [pulseaudio] module-bluez5-device.c: Refused to switch profile to a2dp_sink: Not connected

After a bluez restart switching between profiles works again.

I can't pin it down. Device reconnect does not trigger the problem. Nor does using the gnome audio control.

I think I will live with the workaround unless I found a way to reproduce the phenomenon.

Thanks a lot for working on this. I've updated pulseaudio to master. I'll be doing more testing tomorrow.

Something I did notice: When my headset goes slightly out of range, it crackles and "jumps" in time, as in it stops receiving for say, 50ms and the sound ends up 50ms behind. This is additive and can end up in the headset being several seconds behind. Reconnecting to the bluetooth headset resets that delay.

This doesn't do it on android. Faulty hardware or server issues? I can't tell if it's a regression.

(In reply to Jerome Leclanche from comment #43)
> Something I did notice: When my headset goes slightly out of range, it
> crackles and "jumps" in time, as in it stops receiving for say, 50ms and the
> sound ends up 50ms behind. This is additive and can end up in the headset
> being several seconds behind. Reconnecting to the bluetooth headset resets
> that delay.
> 
> This doesn't do it on android. Faulty hardware or server issues? I can't
> tell if it's a regression.

The buffering doesn't happen in PulseAudio, so it's either in the kernel or in the hardware (local bluetooth adapter or the headset). I don't know how Android avoids this problem - it would be very good to get it fixed on normal Linux too...

I think this is mostly working now. There might still be Bluez 5 bugs to sort out, but in general HSP + Bluez 5 is implemented, and in fact you can use it with both native and ofono backends.

I've been doing some fresh testing with pulseaudio 5.99.2-15-g5effc8 and bluez 5.27, and I'm finding the exact same behaviour as in comment #37. 

Pavucontrol lets me switch to HSP but silently reverts to A2DP when I restart (the switch doesn't actually happen). 

[4:15:31] adys@azura ~ % pactl set-card-profile "bluez_card.90_03_B7_AE_5F_B5" "headset_head_unit"
Failure: Input/Output error

In journalctl, this stuff shows up:
jan 29 04:15:25 azura pulseaudio[752]: [pulseaudio] module-bluez5-device.c: Refused to switch profile to headset_head_unit: Not connected

(In reply to Tanu Kaskinen from comment #44)
> (In reply to Jerome Leclanche from comment #43)
> > Something I did notice: When my headset goes slightly out of range, it
> > crackles and "jumps" in time, as in it stops receiving for say, 50ms and the
> > sound ends up 50ms behind. This is additive and can end up in the headset
> > being several seconds behind. Reconnecting to the bluetooth headset resets
> > that delay.
> > 
> > This doesn't do it on android. Faulty hardware or server issues? I can't
> > tell if it's a regression.
> 
> The buffering doesn't happen in PulseAudio, so it's either in the kernel or
> in the hardware (local bluetooth adapter or the headset). I don't know how
> Android avoids this problem - it would be very good to get it fixed on
> normal Linux too...

Regarding the buffering, it's making the headset unusable in any mode. I'm not sure where to file a bug about it, but I'd definitely like to figure the issue out. Ideas?

Hi,

I am on Kubuntu 15.10 with bluez 5.35, and I have the same issue with my Jabra Classic 0.5.1:
http://www.jabra.com/products/bluetooth/jabra_classic/jabra_classic

If I have well understood, because I need the microphone, the interesting profile for me is HFP, and like in post 39 it get stuck in A2DP unless I reboot bluetoothd + redo the pairing:
https://bugs.freedesktop.org/show_bug.cgi?id=73325#c39

Consequently, I am quite surprised to see this issue as fixed... especially by looking at how the comments ended. Is there another issue with a more adapted title? Or is it the right one to post in? And additionally (of course), is there some fixes for this issue shown in post 39?

I am on arch linux with bluez 5.36 and pulseaudio 7.1 and I am experiencing the same problem. My headset (divacore addict) connects with the a2dp_sink profile and I can see the headset_head_unit profile but I am unable to switch to it, getting the same error: "W: [pulseaudio] module-bluez5-device.c: Refused to switch profile to headset_head_unit: Not connected"

However in my case restarting bluetoothd, removing the coupling and recouple still results in not being able to switch to HSP/HFP.

Should I create a new bug?

I am having the exact same problem on fedora 23 with bluez 5.36 and pulseaudio 7.1-1. "Fixed it" by downgrading to bluez 5.35 and rebooting. 

dnf downgrade bluez --allowerasing

I've found a way to use pc like an headset with Android phone (for making callings).
!!! I've use pulseaudio from jessie-backports: I don't know how much this takes risks ;-) !!!

In /etc/apt/sources.list add:

deb http://ftp.jp.debian.org/debian/ jessie-backports main contrib non-free
deb-src http://ftp.jp.debian.org/debian/ jessie-backports main contrib non-free

$ sudo apt-get update
$ sudo apt-get install pulseaudio=7.1-2~bpo8+1 pulseaudio-utils=7.1-2~bpo8+1 \
    pulseaudio-module-x11=7.1-2~bpo8+1 pulseaudio-module-bluetooth=7.1-2~bpo8+1 \
    libpulse-mainloop-glib0=7.1-2~bpo8+1 libpulsedsp=7.1-2~bpo8+1 libpulse0=7.1-2~bpo8+1 \
    libpulse0:i386=7.1-2~bpo8+1

create a file (with same ownership of /var/lib/gdm3) (create directories if necessary)
/var/lib/gdm3/.config/pulse/client.conf

autospawn = no
daemon-binary = /bin/true

[http://www.gem.mydns.jp/daitei/linux/jessie/bt-headset/]


Install "ofono"

in /etc/pulse/default.pa 
modify the line:
load-module module-bluetooth-discover
in:
load-module module-bluetooth-discover headset=ofono

Restart pulseaudio:
killall -9 pulseaudio
(is not necessary "pulseaudio --start" because from pulseaudio 6 it will restart automatically)

For now it seems that:
- if in /etc/pulse/default.pa you have add "headset=ofono" you will have the headset;
- if not you will have a2dp (restart pulseaudio every time).

Good luck

UPDATES
About parameters of "load-module module-bluetooth-discover":
headset=native -> only a2dp
headset=ofono -> only headset
headset=auto -> a2dp and headset !!!

so in /etc/pulse/default.pa 
add "headset=auto" to line "load-module module-bluetooth-discover":

load-module module-bluetooth-discover headset=auto

It works!

Hello,

I'm having the same problem : I'm running Bluez 3.36, and I cannot connect into HSF/HFP... When I try to, I have the error :

module-bluez5-device.c: Refused to switch profile to headset_head_unit: Not connected

I tried all tricks about ofono... but no one works. Please, help me to solve this very annoying problem.

I will attach the output I get from "pulseaudio -vvvvv" when I run it. You can jump into the part of the execution by searching for the '#' symbol.

Thank you in advance.

Created attachment 127367 [details]
pulseaudio-vvvvv

The "not connected" problem is pretty common, but I haven't heard of anyone figuring out a solution for it. bluetoothd should connect the HSP profile, but apparently that doesn't happen, so it looks like a bug in bluez.

Note also that trying to use ofono won't work, because ofono doesn't support headsets. Ofono only works to the other direction: connecting to e.g. a mobile phone.

After chatting with another user with HSP problems, it seems possible that the conflict between gdm's and normal user's pulseaudio instances might be the reason why the HSP profile doesn't get connected.

If you have the problem that the A2DP profile connects but HSP doesn't, I'd like you to try the following workaround and report the results back (I'm interested in both success and failure):

1. Copy /etc/pulse/default.pa to /var/lib/gdm3/.config/pulse/default.pa

2. Remove module-bluetooth-discover from /var/lib/gdm3/.config/pulse/default.pa

3. Reboot.

I'm not sure if /var/lib/gdm3 is the home directory of the gdm user on all distributions. You can check the gdm user's home directory from /etc/passwd.

I recommend using this workaround for all bluetooth problems. It may not always help, but at least it removes one source of problems.

That doesn't help, on F24 at least.

What happens for me is that when I turn on my headset it connects to bluetooth automatically but with:

	Profiles:
		headset_head_unit: Headset Head Unit (HSP/HFP) (sinks: 1, sources: 1, priority: 20, available: no)
		a2dp_sink: High Fidelity Playback (A2DP Sink) (sinks: 1, sources: 0, priority: 10, available: yes)
		off: Off (sinks: 0, sources: 0, priority: 0, available: yes)
	Active Profile: off

I then have to disconnect the headset from bluetooth and reconnect it as Handsfree to have the headset_head_unit: Headset Head Unit (HSP/HFP) available.

If hsp doesn't work when turning on the headset, but works after reconnecting the device, this bluez patch may fix that:

https://git.kernel.org/cgit/bluetooth/bluez.git/commit/src/profile.c?id=ccd29841c3799c68ed90eb050661ffeccea78c9b

The fix is included in bluez version 5.43.

Fedora 24 already has bluez-5.43 which I upgraded to and /usr/libexec/bluetooth/bluetoothd was restarted after the upgrade.

Is that sufficient to have the benefits of that patch?

(In reply to Brian J. Murrell from comment #59)
> Fedora 24 already has bluez-5.43 which I upgraded to and
> /usr/libexec/bluetooth/bluetoothd was restarted after the upgrade.
> 
> Is that sufficient to have the benefits of that patch?

Yes, I think that should get the new code in use.

(In reply to Tanu Kaskinen from comment #60)
> (In reply to Brian J. Murrell from comment #59)
> > Fedora 24 already has bluez-5.43 which I upgraded to and
> > /usr/libexec/bluetooth/bluetoothd was restarted after the upgrade.
> > 
> > Is that sufficient to have the benefits of that patch?
> 
> Yes, I think that should get the new code in use.

So with that all done, I still have this problem.  Unfortunately.  :-(

I am on F25 with pulseaudio 9.0.1.fc25 and bluez 5.43-1.fc25 and this issue is still present as well

I'am on Arch Linux bluez 5.43 pulseaudio 10.0 and experiencing this issue. My headphone connects only on a2dp_sink mode, and if there's a failure during the streamingI get the same amount of "lag" so videos get desynced. None of the fixes here does any difference, but on pacmd headset_head_unit is listed as "available: unknown" instead of the no some people have reported.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/122.