We'll see | Matt Zimmerman

a potpourri of mirth and madness

Posts Tagged ‘Mumble

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.

Advertisements

Written by Matt Zimmerman

May 26, 2010 at 12:58