Using a Bluetooth headset under Linux
Par jd le vendredi, décembre 12 2008, 16:21 - Free Software - Lien permanent
… is a no.
It just does not work. I mean, it does work if you want to listen to music using mplayer in 8 KHz quality, but don't even think to use it to phone using SIP.
I've first tested with bluez 3 which is part of Debian. It roughly work, but sometimes it stops working and you have to restart hcid, or to clean its cache. Not very stable.
I've then tried using bluez 4, compiled from scratch. It works much better, i.e. I can run mplayer a thousand of times without having it stopping to work, but I'm totally unable to use it with twinkle or ekiga.
And I don't even talk about ekiga still unable to set a custom ALSA output. I even try to hack it via gconf-editor!
That's really a shame.
Commentaires
I didn't get it working with linphone because whenever the phone call ended, the PC disconnected from the headset, which meant it had auto-power-off'd before the next call came in. Seen that one at all?
I'm using wired headphones and a wand mic instead now.
There's no real easy automated way of doing it, no, but plenty ways it does work. My favourite is having a small script that creates a gstreamer sink, connecting to the headset and then choosing that as output. But you can also create a sink in alsa, and other ways as well.
Not friendly, but it does work, and it is high quality sound from any app.
Any example to provide ? That'd be lovely.
I suspect those voip application just get the alsa API wrong. aplay and arecord does work like a charm but skype and other application attempt to open the device again and again causing it to lock the device.
The userspace parts of the Linux bluetooth stack leave a lot to be desired. Too many bits trying to talk together via evil dbus will inevitably go wrong.
The layering principle in the bluetooth spec has been taken a bit too literally in the implementation.
I've talked to the kernel bits "the hard way" (ie: with my own userspace implementation) in an embedded environment and this worked very well.
I don't think you're afraid of interfacing with complicated things (there's evidence you interface with things like X11 ;-)) so you're likely to have more success if you just get rid of the userspace bits of the bluez stack and do something simpler yourself.
#5
You must be right, dbus is shit, lets create yet another ipc to talk to your perfect daemon which does all things that bluez/bluetoothd does. Now serious, maemo use it, distros use it, even android uses bluez, although they don't use the audio plugin all the rest is basically bluez, so why do you thing you have a better solution? And why nobody is using it? Btw, I never saw you suggesting anything on bluez ml or irc channel, so you basically decided doing your "the hard way"? Common give me a break.
I don't think bluez is the culprit.
SIP applications unable to use ALSA correctly are most likely...
The latest pulseaudio versions have bluetooth module that should allow semi decent bluetooth audio experience. I don't know first hand if it works, but it's still progress =)
In my experience, using Voice over IP in Linux is a big no. You'll get lost in a little maze of muted mic channels, broken ALSA mixers and non-working NAT traversals.
Unless you buy a device where everything's preinstalled and preconfigured (e.g. Nokia N8x0, but then again the current software on those does not support Bluetooth headsets).
Yea, the pulseaudio module in 0.9.13 worked great for me in a2dp mode. Getting pulseaudio compiled was the difficult bit.... and the only distro i could find that ships 0.9.13 is fedora 10.
Did you install the appropriate alsa plugin for libpt?
Right, PulseAudio's module-bluetooth-discover is supposed to fix all this.
(BTW, french descriptions on comment entries my posting a guesswork).
I remember this used to work for me, about a year ago; unfortunately, the appropriate software/versions of a2dpd+friends were never packaged for Debian, and I lost my custom setup on a reinstall...