rickrollrc
rickrollrc copied to clipboard
keroserene
Prefer paplay over aplay on systems with PulseAudio
I did not have aplay on my system and the audio did not work. Added a line to play the audio with paplay (which is PulseAudio's replacement for aplay) and to actually prefer it over aplay since many modern Linux systems have PulseAudio as their sound system.
I think aplay should be checked for first because that will work with Pulse, then fall back to paplay if aplay doesn't exist. I say this because I have PulseAudio, but I don't always have it running (I use JACK), which means using paplay won't work. aplay should work in both situations.
Actually aplay doesn't work on my system with pulse, but that's because of the -D plug:default. Pulseaudio already does sample rate conversion, and it seems using the plug: prefix in front of the PA plugin does something weird and hangs without actually playing anything (bug, I assume).
You could try actually using paplay first and then fall back to aplay, or you could try aplay with the default device name without plug first and fall back to plug if that fails. This does have some interesting interactions with the cleanup code though, you have to make sure cleanup kills whatever worked without it being considered a failure and retrying with another version.
Ok, so this is a difficult one, because I want this solution to be not intrusive. I don't know if it is possible to find the optimal solutions for the multitude of possible configurations and clashes between different sound systems. I assumed that almost every major distro uses PulseAudio as a default, but I did not take into account custom configurations. I need more input from you so that we can decide on the best version of this fix.
Would it be a good idea to first check if PulseAudio is running and then run paplay and otherwise fall back to aplay?
There's nothing special about my system as far as I know, it's a pretty bog standard Arch Linux install on a ThinkPad with Intel HDA audio. My guess is this is a pulseaudio ALSA plugin bug. The ALSA plugin has never been particularly great, e.g. it's always been kind of crappy with software like Wine, and it wouldn't surprise me that it interacts in some degenerate way with plug: since it's redundant. I just tried it on a Gentoo system and it does work, so it might be related to the PA version or some other issue triggers the bug.
You should be able to use something like pacmd stat to check for a running PA daemon. If it exits with failure, no daemon is running.
I just checked on my system and pacmd stat indeed fails without the daemon running, so I think @marcan's suggestion would be the best way to do it. Something like has? paplay && pacmd stat >/dev/null 2>&1 (because it's assumed that if you have paplay, you should also have pacmd), and then the aplay check.
@tpenguinltg @marcan Thank you for your input! I've updated and tested the solution and it works for me. Please test it for yourselves and tell me if it works on your both configurations.