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!

Installing ROS on Arch (part 1)

Call me masochistic, but today I try and install ROS on Arch Linux. If you guys don't know Arch is this really cool distro that's pretty much always on the bleeding edge of things and has a huge and supportive community behind it. There are plenty of pre-compiled packages for the core and a huge user repository where everyone can make their own package to be downloaded and compiled by others. It is quite peachy. ROS on the other hand is this monster of software that's basically only supported on Ubuntu and has a dependency tree larger that xorg or gnome combined (citation needed).

Now, why would I want to run ROS on Arch? It's simple: Arch is my current system and I have it set up the way I like it, but I need to use ROS to write code for this new piece of awesome technology we bought, the Allegro Hand. It's currently a secondary project, but I plan on getting the hand running on my machine so I don't have to ssh (or, even worse, physically log in) to a Ubuntu machine every time I want to test out code. But, back to the problem at hand (hehe).

Along with this huge dependency tree there's another problem: the default python on Arch is python3 while ROS assumes that everyone in their right minds would use python2 as their default, so it simply hardcodes the string "python" in every script and path because... well... why would anyone have /usr/bin/python point to anything else than python2? Does a different version of python even exist? (deep sarcasm). Anyway this is a problem I'll get to later, because we don't encounter it until we download the sources, which is itself sort of a pain. 

First off, the best thing you can do for yourself if you are running Arch is to install yaourt, from the french repositories. The french word for yogurt, this is an awesome little tool that lets you install AUR packages with more or less the same amount of effort as regular packages. It's also a transparent wrapper for pacman, so all the commands you know and love work exactly the same way.

Now that you have yaourt it's time to install some dependencies. These are the things I had to install:

aur/wstool-git
aur/python2-rospkg
aur/python2-catkin_pkg
aur/python2-rosinstall_generator-git
aur/ros-arch-deps

That last one took a long time and maybe the first four should be listed as dependencies to it, I don't know. Maybe one doesn't even need it. Let me know if you know. Anyway, I installed it. Then, I followed the steps in the ROS installation document:

$ mkdir ~/ros_catkin_ws
$ cd ~/ros_catkin_ws
$ rosinstall_generator desktop --rosdistro hydro \
> --deps --wet-only > hydro-desktop-wet.rosinstall
$ wstool init -j8 src hydro-desktop-wet.rosinstall

 What this did was pull the source for hydro with the desktop variant in ~/ros_catkin_ws/src

Ok now that we're here we're gonna skip the call to rosdep because that's going to just give us errors saying that we don't have the required dependencies because they don't exist on arch. I am NOT patching rosdep to take care of that. Instead I go right ahead and try and build the damned thing:

$ ./src/catkin/bin/catkin_make_isolated --install

But guess what! This errors out, because catkin_make is a python script and it calls python expecting it to be python2, but instead it gets python3 on my system. None of the things we just installed are present for python3, since they only have python2 versions. Ugly ugly.  I still don't know how to fix this, other than a sed on all the files in the src folder. And for those asking, hell no I'm not gonna change my default python system wide. It's not a matter of ease, it's a matter of principle dammit.