Even though "solved", it's really a failure, a failure to avoid PulseAudio After 2 week's work down the drain (see prior post) attempting to eliminate PulseAudio and, at this point, I have to get back to my life. I had a good plan but what ultimately defeated it is ALSA's latest complication of run-time language interactions with /usr/share/alsa/alsa.conf. For me to reverse engineer the many C++ attribute and function calls to the libalsa binary would take me a year to understand and document. They've finally made ALSA impossible. All that ever needed to happen in Linux audio was for OSS to be further developed 15 years ago, but that's probably a DRM casualty of some sort.
At any rate, I did manage to at least cripple PulseAudio so this is what I'll deal with first. With a couple of segues to failures even within the cripple process. Linux sound, man....
Cripple PA
In the simplest 3-step terms...1. install libpulse normally
Alternatively, simply install one (eg. ffmpeg) of the now tens of programs that check for PulseAudio as a dependency! Lol, but we can see it is now a dependency if we try to *remove* PulseAudio...
2. symlink libpulse binaries to /dev/null
Other than for Google applications (eg, Chromium), PulseAudio is not technically a dependency. Rather applications verify PulseAudio's presence but do not need to use it. Accordingly, we can leave PulseAudio libraries in place, and symlink them to /dev/null. The libraries pass applications' tests for their presence, but do not interfere with our OS, since they are linked to nothing. So...
ln -sf /dev/null /usr/lib/libpulse.so...but leave these two alone...
ln -sf /dev/null /usr/lib/libpulse-simple.so
ln -sf /dev/null /usr/lib/libpulse-mainloop-glib.so
/usr/lib/pulseaudio/libpulsedsp.soThese last are left as-is due to Chromium. During each start-up, Chromium checks for the size of at least one of these two libraries. Since /dev/null is "0" in size, Chromium will fail to start-up if, say common-15 is linked to /dev/null.
/usr/lib/pulseaudio/libpulsecommon-15.0.so
3. enjoy with one caveat
With this configuration, I've never had the pulse daemon auto-spawn, nor had my ALSA configurations overwritten (unless upgrading ALSA directly), nor had failures inside multi-media applications. This includes ffmpeg, OBS, vlc, Chromium, Ocenaudio, and the standard ALSA apps.
HOWEVER. At one point I broke/unlinked /dev/null from these three libs above to see what would happen. The delinking went smoothly, eg...
ln -sf /usr/lib/libpulse-sismple.so.0 /usr/lib/libpulse-simple.so...yet the results were suboptimal. That's because /dev/null does not operate like other files, and it was deleted along with the symlink. Then, without /dev/null in the OS, I encountered random operational failures by applications which rely upon its presence. So, in cases where I have to delete the symlinks, I:
- reinstall libpulse. # pacman -S libpulse.
- restart. during every startup, the kernel propagates /dev/null wherever needed in the system.
apulse - another failure
Apulse is on the AUR and looked promising. It emulated PulseAudio to placate applications which called PulseAudio, and even installs a small libpulse dummy which might do the same /dev/null moves I did above manually.
Although apulse installed fine and I was able to go back to ALSA I was still stuck with the problem that, eg, obs-studio could not detect my ALSA devices. For those without multi-media requirements such as those of obs-studio, apulse might be a solution.
jack? no
Not unless a dedicated machine for recording. Otherwise too many apps require PA. Two things learned when installing JACK however: stackex: change output card, and requires PAM modification, as I describe in this post.
complete PA install
Running as a user, pactl and pacmd are your friends, and the file ~/.config/pulse/client.conf. There's also more here, and also Arch's T-Shooting Guide. A typical issue are multiple cards detected in ALSA, but not by PA. You'll also want to clean out logs.
Is PA installed and running? Even though it's not technically a daemon (see below), it's usually running at starup from some unknown spawner. Check alsamixer and see if it's been superseded by PulseAudio's single volume bar.
After changes to any setup, we can restore ALSA with...
# systemctl restart alsa-restore.service...and PulseAudio (for changes, kill it first, then restart it) with...
$ pulseaudio -k
$ pulseaudio -D
As noted here, PulseAudio is typically not a running service nor daemon from startup. Programs call it on a per-use basis. Some applications, eg Chromium, operate with a minimal /usr/bin/libpulse. Cleanest minimal install for pa_context_connect calls (basic libpulse install enough otherwise). I'm not sure, but to stream (eg. OBS), pulseaudio-rtp (only 200Kb) might be added.
# pacman -S pulseaudio-alsa
Packages (3) alsa-plugins-1:1.2.6-3 pulseaudio-15.0-4 pulseaudio-alsa-1:1.2.6-3
Total Download Size: 1.25 MiB
Total Installed Size: 6.19 MiB
Optional dependencies for alsa-plugins
dbus: for maemo plugin [installed]
jack: for pcm_jack plugin [installed]
libavtp: for pcm_aaf plugin [installed]
libsamplerate: for rate_samplerate plugin [installed]
libpulse: for conf_pulse, ctl_pulse and pcm_pulse plugins [installed]
speexdsp: for pcm_speex and rate_speexrate plugins [installed]
ffmpeg: for pcm_a52 plugin [installed]
pavucontrol
For ease of selecting devices (recording, streaming). It's big however, due to dependencies.# pacman -S pavucontrol
Packages (7) atkmm-2.28.2-2 cairomm-1.14.3-2 glibmm-2.66.2-1 gtkmm3-3.24.5-2 libsigc++-2.10.8-1 pangomm-2.46.2-1 pavucontrol-1:5.0-1
Total Download Size: 2.95 MiB
Total Installed Size: 18.63 MiB
detection issue
configuration files
/etc/pulse/default.pa [detection issues]
/etc/pulse/client.conf [autospawn]
~/.config/pulse/client.conf
1 comment:
I don't get it.
Post a Comment