PulseAudio and ALSA co-exist in EasyOS

October 12, 2020 — BarryK

I had better write this up while I still remember what I have done, or at least post some basic notes. Here is the previous blog post about implementing PulseAudio:

https://bkhome.org/news/202010/problem-with-pulseaudio-and-bluetooth-audio.html

...no, I haven't solved that problem. There was another problem that came up, and I joined the online throng trying to solve that PA problem in addition. Got too frustrated, and wanted to go back to the relative simplicity of ALSA.

Arch Linux have excellent wiki pages, and this page is extremely useful:

https://wiki.archlinux.org/index.php/PulseAudio#ALSA

I was using their 'pulseaudio-alsa' package, which only contains one single symlink, at '/etc/alsa/conf.d/99-pulseaudio-default.conf, which is a link to /usr/share/alsa/alsa.conf.d/99-pulseaudio-default.conf, which has this in it:

# Default to PulseAudio
pcm.!default {
    type pulse
    hint {
        show on
        description "Default ALSA Output (currently PulseAudio Sound Server)"
    }
}
ctl.!default {
    type pulse
}

...effectively, this tells PulseAudio to take over.

However, last night, in a moment of frustration, I decided on a different strategy. If you keep reading that wiki link, quoting:

You may want to use ALSA directly in most of your applications while still being able to use applications which require PulseAudio at the same time. The following steps allow you to make PulseAudio use dmix instead of grabbing ALSA hardware device.

Remove package pulseaudio-alsa, which provides compatibility layer between ALSA applications and PulseAudio. After this your ALSA apps will use ALSA directly without being hooked by Pulse.

Edit /etc/pulse/default.pa.

Find and uncomment lines which load back-end drivers. Add device parameters as follows. Then find and comment lines which load autodetect modules.

That is what I have done, almost. ALSA-based apps all work as normal, as does the MSCW (Multiple Sound Card Wizard). However, PulseAudio is still there, not just for apps such as the official Firefox binaries that require it, but especially for Bluetooth audio.

If a developer wants to study my implementation, I suggest download the latest woofQ tarball (not yet uploaded), and look at these folders and files:

packages-templates/bluez
packages-templates/blueman
packages-templates/pulseaudio
rootfs-skeleton/usr/sbin/mscw

Oh yes, an important detail. Study these files, to see users and groups required by PA:

rootfs-skeleton/etc/passwd
rootfs-skeleton/etc/group

Blueman is the Bluetooth tray applet. You use this to connect to a Bluetooth device. In the case of connecting to an audio output device, MSCW has to also be run to select that device. This is the same procedure as when using 'bluez-alsa', that EasyOS has in current releases.

And, just like with 'bluez-alsa', MSCW will create a /root/.asoundrc, but in this case it will have the content exactly as shown above for the 99-* file. In other words, when Bluetooth audio output is selected, PulseAudio is instructed to take over.

Note that MSCW retains compatibility with 'bluez-alsa', in case I decide to roll back to using it.

I won't bore you with nitty-gritty details, enough to say that this setup works surprisingly well.

I would like to work on streamlining the connection of Bluetooth audio devices, so that MSCW is invoked automatically. And then there is the reconnection problem, PA not recognizing when my Audiosonic speaker is turned on. Ideally, I want to be able to turn on my speaker, and that's it, it works. Like on my Android phone.

EDIT 2021-11-13:
Update, back in 2020 I reverted to ALSA, without pulseaudio. However, November 2021 have returned to pulseaudio. Blog post overview:

https://bkhome.org/news/202111/how-pulseaudio-is-implemented-in-easyos.html

Tags: easy