Bluetooth HSP/HFP

I am having a bad one as it should be possible to use

    index: 1
    name: <bluez_card.9B_FD_D5_6E_01_CA>
    driver: <module-bluez5-device.c>
    owner module: 23
            device.description = "A10"
            device.string = "9B:FD:D5:6E:01:CA"
            device.api = "bluez"
            device.class = "sound"
            device.bus = "bluetooth"
            device.form_factor = "headset"
            bluez.path = "/org/bluez/hci0/dev_9B_FD_D5_6E_01_CA"
            bluez.class = "0x240404"
            bluez.alias = "A10"
            device.icon_name = "audio-headset-bluetooth"
            device.intended_roles = "phone"
            a2dp_sink: High Fidelity Playback (A2DP Sink) (priority 40, available: unknown)
            headset_head_unit: Headset Head Unit (HSP/HFP) (priority 30, available: no)
            off: Off (priority 0, available: yes)
    active profile: <a2dp_sink>
            bluez_sink.9B_FD_D5_6E_01_CA.a2dp_sink/#1: A10
            bluez_sink.9B_FD_D5_6E_01_CA.a2dp_sink.monitor/#1: Monitor of A10
            headset-output: Headset (priority 0, latency offset 0 usec, available: unknown)

            headset-input: Headset (priority 0, latency offset 0 usec, available: no)

I have read about that hsp/hfp is only supported by ofono and I am trying valiantly but failing to set it up.

Anyone got any guides on setting up hsp/hfp on a Pi with a bluetooth dongle as am aware of the bluetooth problems.
Its sort of nuts as Ubuntu is the same but other distro’s, android and win all work perefect just the debian bases seem a complete mare!

Hey Stuart, I saw in chat that you might have had some success with this.

If there’s anything we can add to our docs for the future, please let us know. :slightly_smiling_face:

Still at it, as the sco routing in the hfp/hsp profile isn’t working with bluealsa.
Both bluealsa and the pulseaudio-bluetooth-module support Ofono which supposedly works with hfp/hsp but the qt dependencies just seems so much bloat.

I want to try and get bluealsa working and if you have an a2dp mic/speaker rather than hfp then it works.
Prob is they tend to be mainly high end price and the idea is low price means you can scatter these around.
My growing collection of bluetooth dongles and speaker mics is awaiting a budget bt5 arival which I am hoping will be a2p mic/speaker and maybe even dual mode where you can hang 2 speaker/mic off it but that might just be a sink and not with the hfp/hsp subset.
If not its just a matter of a another dongle for each as they don’t tend to interfere.
I don’t have a a2dp speaker/mic or headset to try with mycroft yet, but if alsa it can be used as mycroft depending on setup needs both (alsa/pulseaudio) depending on modules.

So fired a load of logs off at the dev and awaiting deliveries, so will have to see. the main guy is pretty active and guess will just have to see but things are quite fresh.
BT support in Linux because of bluez dropping hsp/hfp in v5, that bluez made it a somebody elses problem and pulseausio did the same.
Its messy and extreme bloat hence why I have my fingers crossed for the bluealsa dev, which is a raspbian package even though old and hsp/hfp definately doesn’t work with whats shipped in Buster.

@StuartIanNaylor Scrolling a bit through the forum, reading some posts that I might have missed the last few weeks. This is one of them :wink:

I have this exact same task on my (long) todo list as well. Have not started it yet, but thought I might give you my saved bookmarks/pointers about HSP/HFP

If I remember correctly the onboard BT chip of the RPi needs some help for the SCO packets. Anyhow, here are my pointers I found from HassOS

They might help you or at least give you some additional clue’s about where to look next / google for.

Even if you fire off the Pi BT and use a dongle its far from simple.

Because BlueZ dropped HSP/HFP pulse have said you can do it through ofono.
Which also needs ofono phonesim as really what it does is a create a virtual phone so you can connect to that and the virtual phone uses pulseaudio.
Its such a horrid fudge in implemenetation that I am not going to bother.

Bluealsa is still a work in progress.

It actually installs QT4 and even after that it didn’t work for me but started to wonder if ofono was set up for a system-wide pulseaudio session and root credentials whilst we are running user sessions.

Its just far easier to find a2dp devices aka BT 5.

I am a big fan of the Pi and did try the SCO fixes and there are still open issues on github with it.
The combo unit on the Pi is relatively sucksville as also can produce wifi co-existance problems.
But there is a 3rd problem with the Pi 4 as I have got one of those lovely ‘armour’ heatsink cases and my temps are nothing.
But I am expecting in this heatsink the range will be pants also if I could get it working.

My opinion is just turn off the BT and get a $5 BT5 dongle that will stick out of a USB port and also gain range.

There is a problem as it wasn’t just Linux or the Pi that had problems with HSP/HFP and a lot of manufacturers have created many proprietory solutions.
Hence in 5.2 they have released LE Audio that part of it is to pull back and adopt a common standard.

If you are buying its much easier just to get BT5 and a2dp and scrap the idea of HSP/HFP which I think is going to eventually happen.
Even then with Bt5 its dependent on device.
I think some 4.0 untits will work but you need EDR+ and don’t think the PI supports currently.

Linux and sound architecture is already a nightbare. Add Bluetooth to that mix and you loose even the last couple of hairs… :smiley:

I haven’t really dived into the whole BT things as of yet, other then just enabling it to make mycroft act as a bluetooth speaker. (Send music to it from any other mobile device) Works great, using A2DP so stereo if you would connect a stereo speaker system of course.

Anyhow, that brings me to the point why I have HSP/HFP on my list to do it the otherway around. Connecting a headset to mycroft to use the mic and speaker as input/output device. If I remeber correctly A2DP is stereo but because of that also uni-directional. This does not make it the best setup for mycroft as you can not barge into mycroft when it speaks. So no ducking support and making it kind of useless if you want to tell mycroft to stop your music playback.

I don’t use ALSA and would like to stay away from it. Pulseaudio although having it’s own challenges is the path I follow for all sound for my project.

First of all, never start a service as root. Just run it under a/the dedicated pulse user and make sure the system rights are setup correctly (for bluetooth this also means you need to add that user to the “lp” group)

I will see if I can move the task up on the list, so we could work on this stuff together. 4 eyes might get us both faster at the point of success.

For now, here is my implementation of bluetooth within my project. Not one-on-one to be used with rasbian, but might give you some pointers again.

But again, this is still for the other way around.

I will leave it you you :slight_smile: tell me how you get on.
If you run into problems check the ofono service and ofono d-bus profile as yeah running pulseaudio as usual as user session, but its ofono is set up as root and I think it rejects d-bus calls.
Dunno I bagged it off at that stage as was having a tantrum how convoluted hsp/hfp profiles where.

Right, I already have so little hair left… :wink:

Your OK don’t worry as with me its my sanity I worry about :slight_smile:
Good luck and hopefully you will crack it as satelite bluetooth speakers/mics is a great addition.

PS @j1nx my other thought was just to have a Pi zero W and a dongle in operation with the Broadcom combo and just have two a2dp streams and 2 dongles.

1 Like

@j1nx Peter another thing I just remembered as well as the SCO fix you also need to do the MTU fix.
The broadcom use a MTU of 64 whilst in pulse is set to 48.

Improved bluetooth MTU configuration

The packet size (a.k.a. MTU, “maximum transmission unit”) that PulseAudio uses with the bluetooth HSP profile was previously always configured to be 48 bytes. That worked with most hardware, but some adapters require a different packet size. Now PulseAudio asks the kernel what packet size should be used, which fixes the problem.

However, a new problem appeared: some adapters that used to work with 48 byte packet size don’t any more work with the size that the kernel tells PulseAudio to use. If you find that HSP audio stopped working when upgrading to PulseAudio 11.0, you can revert to the old behaviour by passing option “autodetect_mtu=no” to module-bluetooth-discover in /etc/pulse/

So I presume autodetect_mtu=yes as hopefully the kernel will report 64 on the Pi as presume its a config option.
But profile switching will work just playback will freeze and pop due to the MTU missmatch.
So it would be module-bluetooth-discover autodetect_mtu=yes headset=ofono.

So if you navigate to Bluetooth
Install ofono and ofono-phonesim and remember its ofono-phonesim on the cli and not phonesim.

Just check

sudo useradd -g bluetooth pulse

The D-Bus access policy also doesn’t allow pulseaudio to communicate with ofonod by default when running pulseaudio in the system mode. To grant the permission, add this to /etc/dbus-1/system.d/ofono.conf:

  <policy user="pulse">
    <allow send_destination="org.ofono"/>

To set up phonesim, first create or edit the file phonesim.conf in /etc/ofono. It should contain the following lines:
If have forgot the dir for the raspbian ofono-phonesim install but you will find it and edit with.


For now just run from the cli but ofono-phone should be a service.
ofono-phonesim -p 12345 /usr/share/phonesim/default.xml&
With also being part of that service

dbus-send --print-reply --system --dest=org.ofono /phonesim org.ofono.Modem.SetProperty string:"Powered" variant:boolean:"true"

Once the modem is set up properly, you can connect your headset and the “Headset Head Unit (HSP/HFP)” profile should be available in pulseaudio.

But I find not.

As to ALSA vs pulseaudio isn’t really an argument as they are both unescapable and any interoperable by many tools and pulseaudio is just a server and abstration layer of ALSA and for a headless system could be considered bloat.

I don’t mind either and if bluealsa did work then I would use it because of an aversion to the massive bloatware ofono.

1 Like

Great info! Bookmarked next to the other stuff I have saved for it.

I will give it a go in a few days. At the moment I am in progress of updating Buildroot, kernel and drivers, so have to push it forward a bit till I have a fresh bootable OS again, but after that will have a look.

Keep you posted…

1 Like

Please do and thanks for the input, fingers crossed.
I almost wrote that out verbatum from memory and with my memory is extremely indicative of its been tried too many times.
It might just need another pair of eyes and could be something simple or dumb by me, it often happens.

There is also the AUR package for Archlinux that I cloned just for reference that gives you an alternative datum.
The new master of Ofono and phonesim has been updated to QT5 but raspbian still has QT4 in the repo aswell.

1 Like

I’ve tried to bring up bluealsa from the following tutorial and successfully bought the interface up with a JBL Bluetooth speaker with inbuilt mic (Tested by recording and playing sound with arecord and aplay). But Mycroft is not able to recognize this as a source or a sink when I run “pactl list cards”. I would think that if this stream were to be connected as HSP/HFP source and sink in pulseaudio, things would work. Any ideas on how to do that?