A few weeks ago I griped about GPIO noise in the payphone and someone pointed out that it was most likely caused by me believing that I had a pull-down resistor when I did not. I was using pin 12, you see, and that is one of the Raspberry Pi's pins that arbitrarily does not contain a built-in pull-down resistor. Because every god damned GPIO pin is a god damned special snowflake with its own arbitrary god damned set of magical behaviors. And good luck finding any of this in the documentation. Oh yeah, also the API call that turns on the resistor does not return an error status when said resistor does not exist. How very.
Anyway, having humped that heavy-ass payphone home on my back to work on it, I faced the traditional dilemma: do I upgrade the OS to avoid whatever pile of new security exploits have appeared in the last two years? Or do I leave it alone, so that shit doesn't break?
Reader, I chose poorly.
I upgraded from Raspbian 9.13 to 10.10 and -- wait for it -- sound stopped working. Are you shocked? Don't be shocked. After I figured out the set of random, poorly documented config files where I had to change a "1" to a "2" because they decided to change how audio devices are numbered, I finally got it making use of my USB audio interface again. But then, even more shitfuckery!
See, because the year is still 1991, Linux systems cannot play two sounds simultaneously.
Yes, really.
So if you are using /usr/bin/play to play an MP3 file in the background, you have to wait for it to finish before trying to play another one, or the second one gives you the completely sensible error message, "play WARN alsa: can't encode 0-bit Unknown or not applicable".
This is considered normal, and in fact not batshit insane, by the Linux community.
The Linux Sound Architecture, I am reliably informed, is considered "Advanced".
When I got this working back in the Raspbian 9.13 days of yore, I solved this problem by having my program fork "play" and keep track of its pid; and when it's time to play a new sound, kill the existing "play" process first.
Guess what, that trick no longer works in this modern jetpack future world of Raspbian 10.10.
Now, apparently, even after the play process has exited, and has been waitpid'ed, the audio device still hasn't been unlocked -- audio remains unplayable for somewhere between 250 and 400 milliseconds.
Someone on Twitter suggests that maybe this is some new kernel fuckery that appears to affect the 10.10 kernel (5.10.52-v7+ #1441) but I sure can't tell what any of them are talking about.
In summary, fuck all of this entirely.
