Using Mumble with a bluetooth headset
At Canonical, we’ve started experimenting with Mumble as an alternative to telephone calls for real-time conversations. The operating model is very much like IRC, based on channels within which everyone can hear everyone else as they speak.
Mumble works best with a headset, which offers better audio recording quality due to the proximity of the microphone, and avoids problems with echo and feedback. I like to pace around while I talk, and so I’ve already invested in a Plantronics Calisto Pro, which includes a DECT handset, a Bluetooth headset and a nice charging base. My laptop has bluetooth onboard, so I set about trying to get Mumble set up to use the headset via bluetooth.
The first thing I tried was to click on the bluetooth icon on the panel, and select Set up new device.... After setting the headset to pairing mode, I waited quite some time for it to show up in the list, but it never did. After opening the preferences dialog, I discovered that this was (presumably) because I had already paired it, ages ago.
So, I went about trying to get PulseAudio to talk to it. After some hunting, I tried:
pactl load-module module-bluetooth-device address=00:23:xx:xx:xx:xx
This created a new Card in PulseAudio, which I could see in the Hardware tab of the Sound Preferences dialog and in pactl list, but it was inactive:
Card #1
Name: bluez_card.00_23_XX_XX_XX_XX
Driver: module-bluetooth-device.c
Owner Module: 17
Properties:
device.description = "Calisto PLT"
device.string = "00:23:XX:XX:XX:XX"
device.api = "bluez"
device.class = "sound"
device.bus = "bluetooth"
device.form_factor = "headset"
bluez.path = "/org/bluez/13899/hci0/dev_00_23_XX_XX_XX_XX"
bluez.class = "0x200404"
bluez.name = "Calisto PLT"
device.icon_name = "audio-headset-bluetooth"
Profiles:
hsp: Telephony Duplex (HSP/HFP) (sinks: 1, sources: 1, priority. 20)
off: Off (sinks: 0, sources: 0, priority. 0)
Active Profile: off
The Hardware tab confirmed that the device was Disabled, and using the “Off” profile. I could manually select the “Telephony Duplex (HSP/HFP)” profile, but this had no apparent effect. There were no Sources or Sinks to send or receive audio data to or from the headset (and thus nothing new in the Input or Output tabs of the preferences dialog). syslog hinted:
pulseaudio[15239]: module-bluetooth-device.c: Default profile not connected, selecting off profile
At this point, I recalled that when I suspend this laptop, the bluetooth driver gets unhappy. I don’t commonly use bluetooth on this laptop, so I hypothesized that the driver was in a weird state, and I decided to try unloading and reloading the btusb module. Once I did so, the device showed up in the panel menu, with a “Connect” menu item. Aha! The manual module loading above may turn out to be unnecessary if the device shows up in the menu initially.
I selected the Connect menu item, and a bunch of magic happened, with the result that I heard the headset’s tone to indicate it was activated. Sound Preferences now showed it under Hardware as active using the Telephony Duplex profile, and it appeared under Input and Output as well. pactl list showed its sources and sinks. Mumble offered it as a choice for the input and output device. Progress!
Some experimentation (thanks, Colin) revealed that other people could hear me through the headset just fine.
However (Problem #1), I couldn’t hear them clearly through the headset. If I switch Mumble’s output to my speakers, they sound fine, so it’s not Mumble. So I tried:
paplay -d bluez_sink.00_23_XX_XX_XX_XX /usr/share/sounds/alsa/Front_Center.wav
…which also sounds awful. There is a whining noise, which gets louder when the audio signal is louder, which makes it very difficult to hear. I don’t know if the problem is with PulseAudio, bluez, the kernel, or the device, but using speakers for output is a workaround. This does seem to cause some echo, though, so I’ll need to track this down eventually.
Problem #2 is that Mumble seems to prevent PulseAudio from suspending the headset’s source. Even if I set it to “Push to Talk” mode, the headset stays active all the time, which will drain the battery. PulseAudio seems to do the right thing, and kill the radio link, if the source is left idle, and brings it up when there is activity, so this looks to be Mumble’s fault. I’ll need to fix this as well.
We'll see | Matt Zimmerman 
Yay for another NIH. It’s not like SIP or IAX can’t do low-latency conferencing.
martin f. krafft
May 26, 2010 at 14:12
The experience that it provides is pretty compelling for our needs, and I’m not aware of anything comparable which was built on SIP or IAX. I don’t know whether this is due to a lack of technical capabilities or not. I’m honestly not that interested in what protocol it uses under the hood so long as it works.
Matt Zimmerman
May 26, 2010 at 16:40
If the protocol it used under the hood was a standard (or if there was a protocol bridge), you could tie into it from a wide range of devices through a whole lot of methods.
For example, instead of fighting bluetooth and headsets under linux, you could register your mumbles client onto your PBX as an extension, and “dial in” to the software with an IP phone you have plugged into your LAN, and use a hardware speakerphone/handset/cordless phone/conferencing phone. Or, you could connect to a mumbles session from your cell phone by calling into your private PBX and calling the mumble extension.
In other words, using standards protocols gives you unbridled flexibility. That kind of freedom is why the original commenter and others wish it had that support already.
Michael David
July 9, 2010 at 15:11
yeahh… bluetooth audio has always been a bitch. one of the problems 3 years ago was the fact that BT audio can send “zero length” packets, which are used to indicate “please keep the BT stream active, thank youuuu”.
i belieeeve that one of the other problems is the wake-up time required for the BT device. BT audio devices can be asleep at the time when the ALSA system triggers a connection to them. this turns into an arbitrary-length delay, the result of which is that applications simply cannot cope.
so… i think you’ll find that using BT audio is going to be _massively_ problematic, and that you’d be better off getting a hardware solution (!)
by that i mean see if you can find a BT audio receiver device, with which you can register the BT headset, and it has a line-in and line-out or a MIC/SPK socket, and get one of those USB AC97 dongles and plug the BT audio receiver into it.
whilst this may sound truly dreadful it’s far more likely to work reliably than anything that the free software community can come up with, unless someone with extraordinary cross-project skills is given the task of fixing and rewriting the linux kernel, the ALSA subsystem and modifying at least one of these VoIP apps to do a proper stateless multi-error-capable job.
Luke Leighton
May 26, 2010 at 16:21
It doesn’t seem that far off from plug-and-play, and I’m inclined to tinker with it a bit more to see if we can offer a simple experience out of the box in Ubuntu.
If it’s not feasible with the current stacks, I have a fallback plan, as the Plantronics unit also has a USB audio interface. That will require some driver work, but I’ve got the basic pieces working.
Matt Zimmerman
May 26, 2010 at 16:42
Have a look at blueman, which automates that process. You might need to enable a few plugins.
Luca Invernizzi
May 26, 2010 at 21:56
Mumble needs continual audio input. Without it, you can’t adapt noise filtration, gain control and echo cancellation (yes, as long as the microphone and headphone is physcially connected, there is echo, even in a headset). So if you “fix” this, it will come at a steep cost in audio quality ;)
Thorvald Natvig
May 27, 2010 at 19:09
Surely it only needs audio input when I’m actually talking. When I’m muted, or not in a conversation at all, surely this isn’t necessary?
Matt Zimmerman
May 28, 2010 at 16:28
Technically speaking, it will adapt in 15-30 seconds. So if you change the way mute works so that you enforce a 30 second “grace” period after unmuting, you should probably be fine. That’s going to me incredibly annoying though.
You can’t adapt only when talking, as it’s really hard to detect the stationary background noise when you’re talking on top of it. And background noise changes subtly all the time, so you can’t “adapapt once and be done” either. In effect, unless you’re already adapted by the time you start transmitting to the remote end, the start of your transmission will be noisy and include echo.
If you want, you can simulate this; if you open the settings and hit “apply”, you’ll restart the filters.
Thorvald Natvig
May 28, 2010 at 16:35
Gnome-bluetooth automates this graphically since Karmic, you can just pair and select you bluetooth headset there and it will do all the pulseaudio stuff for you! :-)
Ernst
June 1, 2010 at 23:38
I would hope so. However, as you can see in the post, gnome-bluetooth doesn’t seem to be working properly for me after a suspend/resume cycle (no devices show up in the list). I haven’t yet tracked down the problem.
And of course, gnome-bluetooth won’t do anything about the two problems I noted, one of which is Mumble-specific and the other not.
Matt Zimmerman
June 2, 2010 at 08:14
I’ve since confirmed that, if I restart bluetooth-applet before doing anything else, this all works as expected:
0. Restart bluetooth-applet (XXX)
1. Select the already-paired device from the Bluetooth menu
2. Select “Connect”
3. Select the headset where desired for audio output
Matt Zimmerman
June 2, 2010 at 08:22
(well, except for the two problems noted, one of which is unique to this headset)
Matt Zimmerman
June 2, 2010 at 08:22
I’d be happy to see a useful debug output for all that.
Bastien
October 19, 2010 at 00:44