Bluetooth headphones on Arch: a new twist in the saga

As of a few days ago the official blueman build for Arch switched from depending on bluez4 to bluez (which is to say, bluez5). If you missed my previous post, I already had gotten my bluetooth headphones working pretty well with bluez4, ALSA and blueman. This new update broke my setup, and sent me on my way to new adventures in bluezland(TM).

I haven't gotten much to work yet. I'm sorry. But as I get things working I'll update this post. This is what I've done:

Tue Nov 5 11:51:07 CST 2013
I updated my system and everything was "broken". I sent a few bug reports, posted a few things on Arch forums, the usual. There are a few problems, and I'll describe them as best I can. First off, bluez5 dropped ALSA support, so I had to install pulseaudio-git from the AUR, since the official repo version of pulseaudio does not yet have bluez5 support. Then there's the issue that blueman-manager and blueman-applet won't work anymore, they just error out with a dbus error that seems to indicate (to my limited knowledge) that they were not properly updated to the new bluez5 API. So I turned to knowledge gleaned from recent edits of the Arch Wiki and tried to use the new command like tool that comes with bluez5, bluetoothctl. At first, this looks awesome. It has its own little shell, color output and everything. The main problem is that it doesn't really work. I can't use it to pair my headphones, and I can't use it to connect to them. The errors a terse, to say the least. So I looked for another alternative and tried using gnome-bluetooth, which is what most people use, I think. The problem with gnome-bluetooth is that, unless you're running gnome, it doesn't come with a system tray applet anymore, so there is no way to connect to your device. This is what I ended up doing: 1. install gnome-bluetooth; 2. run bluetoothctl and remove your device from the list, if it is there; 4. install and run pulseaudio; 3. run bluetooth-wizard and pair with your device, it will also autoconnect and it should now work (test with running speaker-test). The one issue I ran into is turning the headphones off and back on. They will not automatically reconnect they way they did under blueman. Instead, it seems to work to go into bluetoothctl and manually connect (see image).

The other problem is a lack of control over the bitpool rate (maybe there's a way, but I don't know it yet) so every once in a while the sound gets chopped up and dropped.

Mon Nov 18 13:26:28 CST 2013
I managed to figure out how to only use bluetoothctl for pairing and connecting, so that I don't have to rely on gnome-bluetooth any longer. The trick was to turn the agent on before trying to pair. Note that tab completion works inside bluetoothctl, so all these calls are pretty easy to make.

# bluetoothctl
[bluetooth]# power on
Changing power on succeeded
[bluetooth]# agent on
Agent registered
[bluetooth]# scan on
Discovery started
[CHG] Controller 00:13:46:4D:6A:C6 Discovering: yes
[NEW] Device 00:1D:BA:29:50:D3 DR-BT50
[bluetooth]# pair 00:1D:BA:29:50:D3
Attempting to pair with 00:1D:BA:29:50:D3
[CHG] Device 00:1D:BA:29:50:D3 Connected: yes
[CHG] Device 00:1D:BA:29:50:D3 Paired: yes
Pairing successful
[CHG] Device 00:1D:BA:29:50:D3 Connected: no
[bluetooth]# connect 00:1D:BA:29:50:D3
Attempting to connect to 00:1D:BA:29:50:D3
[CHG] Device 00:1D:BA:29:50:D3 Connected: yes
Connection successful
[bluetooth]# scan off
Discovery stopped
[CHG] Controller 00:13:46:4D:6A:C6 Discovering: no
[bluetooth]# exit

Bluetooth headphones and Arch Linux: the endless battle

So a few years back I had the brilliant idea to get on the bluetooth bandwagon and get me a nice pair of headphones, because, you know, wires are for suckers. Pretty standard pair of Sony DR-BT50. And pretty much for as long as I've had the headphones I've had headaches. Not that they're physically uncomfortable... quite the opposite. The cushion is made of the softest skin, probably ripped straight off of a newborn baby's ass. No, it's the bluetooth that's been giving me the problems. Not so much in Windows, but who uses Windows anyway? They worked for a while on my MacBook, although with a bunch of caveats and weird behavior (I could lock my computer up if I accidentally closed the lid before turning the headphones off... WHAT?!) until the screen broke and while I was fixing it I accidentally nicked the bluetooth antenna that's weirdly placed behind the LCD.

But mostly I use Linux on a day to day basis, especially at work where I listen to most of my music. And I need headphones, because me blasting Cynic before noon would get the rats all agitated and whatnot. And let me tell you, blutooth on Linux is about as developed as cuisine on an airplane. Except where airplane food has stayed the same over, I dunno, the past 50 years or so (has there been any time when they did not offer peanuts and soda?) bluetooth on Linux changes about every six months. The main stack is called bluez and the developers are churning the versions and modifying the API something fierce. Not so much with the documentation. In fact it seems like the documentation has been dwindling in size. For example, there used to be a wiki. Was it amazing? No, but it gave people a starting point. Now the only way to get to the wiki, which is mostly about bluez4 (the version most people are still using) is to use the way back machine. Anyway, this guy here does a much better job than me at describing all the ridiculousness surrounding the topic.

What I meant to say before I got off the rails is that, every time some update to bluez or pulseaudio rolls in, my poor headphones stop working. And even if they do work, there's a lot of crackling and just general instability. So the other day I said "enough is enough!" and started looking at the issue like a researcher. I did not get as far as James Bond (see above) but I'll tell you what I did find. This is how my setup works now, it's relatively simple, and I might simplify it even further later, as things start breaking more.

For one, I am running Arch, and somehow Arch decided that bluez5 is the default version of the bluetooth stack even though nothing really seems to work with it yet. Whatever, first step is to install bluez4, which is bluez 4.101 or something
along those lines. Next you need something to help you pair and connect to your headphones. I've heard you can use the command line for this, but the actual commands seem to change every few months so I haven't been able to get it to work. Instead I installed blueman. Now, I paired my headphones, it asked for a PIN, had to look it up and it turns most headphones use 0000 a their PIN. Next, in order to get them to connect I had to add

Enable=Sink,Source,Socket

in /etc/bluetooth/audio.conf. Connected like magic!

One big step done, we move on to getting sound through. For the longest time I used pulseaudio, which is supposed to work
out of the box with bluez. Blueman even has a nice plugin to switch the output to your headphones when you connect them and then switch it back when you disconnect. The problem with this setup is that everything is magic. I have no idea how any of this works, it's code that talks to other code on dbus in ways I'd have to spend a month or more to figure out. So, after having some issues with this and being able to figure out nothing, I completely ditched pulse and switched to good old ALSA. What this means is I added this file in my ~/.asoundrc:

pcm.btheadset {
   type plug
   slave {
       pcm {
           type bluetooth
           device 00:1D:BA:29:50:D3
           profile "auto"
           bitpool "31"
       }  
   }  
   hint {
       show on
       description "BT Headset"
   }  
}

ctl.btheadset {
  type bluetooth
}

You'll want to change the device to match the mac address that blueman gives you for your particular headphones. Everything else is pretty self explanatory except for profile (I have no idea what it does) and bitpool, which I will explain momentarily.

Having done the above you can check your also read it by connecting your headphones and running aplay -L. Your new bluetooth sink should come up. You can even get sound by running speaker-test -D btheadset. Not very pleasant, but it tests that things are working. Now you should be able to select the btheadset output in your media player of choice.

After all this hassle there is one thing left: sound quality. I was getting interruptions and hangs every few seconds with the default config. This is where the bitpool value comes in. I don't actually know what it means and what it does, but reading a bunch of forums I realized it might be helpful. It's not even documented very well... I had to read the source file in C to see that it was in fact set to some magic numbers at compile time by default. Anyway, I played around with it, and it seems to be some sort of quality vs. skips control. The higher the number the higher the chance of a skip, but the better the sound quality between skips. Make the number too low and you'll get phone quality on your headset. Since I listen to my music over ssh, and have it downsampled to 128bits anyway, I care not about high quality, so I probably made that number slightly smaller than I needed to, but I get absolutely no skips now. And that does it. This should hold me for a while, until bluez4 goes completely out the window and bluez5 forces us to use pulseaudio with its magic touch and cryptic error messages that nobody understands... Anyway, I leave you off with a track from the new Cynic album. Enjoy!