Bluez and Pulseaudio

[Xander314]

I had almost finished building my amazing systemd, udev, consolekit, policykit and pulseaudio free system. But then I came to add my Bluetooth audio devices and discovered that BlueZ 5 does not support ALSA audio streaming, only PulseAudio. PulseAudio pulls consolekit and policykit, and means my audio will only work while logged into an xsession. And so now I don't know what to do. I could keep my nice system and use BlueZ 4 which is apparently unmaintained and doesn't have good Bluetooth LE support, or I could stick with BlueZ 5 and fill my system with dependencies I really don't want. What should I do? Am I being stupid trying so hard to avoid Pulseaudio and *kit? If any of you guys use Bluetooth audio, what setup did you choose? Is there any wider interest in getting ALSA support into Bluez 5, or is that unlikely to happen without a fork?

[mv]

In the dependencies of bluez, there is no pulseaudio mentioned. Are you sure that there is no way around?
Maybe you can get away with apulse?

When apulse did not yet exist, I was forced to use pulseaudio for skype. However, IIRC, I could install pulseaudio without policykit (at least, for the purpose of skype).

[ct85711]

Well, I wish you luck with using audio over bluetooth.

I'm using pulseaudio, as I wasn't interested in going through a big mess (which I still ended up doing anyways).
From what I've seen, pulseaudio is in general half a$$ed app, that is also a cluster f**k in short. For what I was wanting to do, in my use case, is simply using some bluetooth headphones to output the audio, no input. I eventually got it working, but in the process I did find out some things. Pulseaudio has no concept of default and fallback devices (from their documentation and their mailing lists). What this effectively means is that pulseaudio will default to the normal soundcard for outputting audio, and you have to manually switch the source to the other device every time. There is an option where it won't save this information, so when the stream goes away, the default device gets reset. The default is, that it will always goto the sink that you choose regardless if it is present or not (in which case no output). Oh, can't forget the other fun part that it only knows of a source if it's outputting something, once it stops pulseaudio completely forgets everything about it again.

In short you can think of pulseaudio as a child with ADD and with a 2 second attention span playing as a traffic controller.

Sadly, I won't be much help on setting it up, as I have no clue what I was doing.

[szatox]

What 'bout JACK? I'm just curious

[tclover]

[lost+found]

When I looked into this, I found this what happened:
There is an ALSA plugin in the Bluez 4 package. In Bluez 5, UNIX socket support has been removed, and because of that the ALSA plugin also.

I've read somewhere that the PulseAudio and Bluez devs work together, and don't like the ALSA devs (or vice versa).

I'll stick with Bluez 4, works fine for me.


Update: something like a2dp-alsa could be a future solution.

[Xander314]

Sorry for the belated response, but I've been rather busy recently. Thanks for all the advice. I have now managed to install PulseAudio without installing any of the *kits, so that's one step forward. I eventually settled on a hybrid ALSA/PulseAudio system with ALSA as the default and PulseAudio started on demand by applications which require it (e.g. Skype and Bluez). If anyone else is interested in this setup, it's described in the ArchLinux wiki: https://wiki.archlinux.org/index.php/PulseAudio#ALSA.2Fdmix_without_grabbing_hardware_device. (As far as I can see, ALSA's dmix and dsnoop devices always use the first soundcard they find, so in my case I did also have to write a custom dsnoop device associated with the correct soundcard.)