"Advanced" Linux Sound "Architecture"

I can't believe that this 1994 clown car has still not disgorged all of its passengers, but here we are. I'm running Raspbian 9.6 and if mpg321 is interrupted before it finished playing the file, about 10% of the time the machine gets into a state where it can't play sound any more and launching any process takes ~5 seconds. At that point, I haven't found a recourse other than rebooting.

Any suggestions, other than "get a less annoying hobby"?

Previously, previously, previously.

Tags: , , , , , ,

32 Responses:

  1. David Glover-Aoki says:

    Have you considered using "play", instead of mpg321, from the SoX project?

    It should be in the Raspbian package manager as "sox".

    • jwz says:

      Other than playing CADT Roulette, do you have any actual reason to believe that will work any better?

      • David Glover-Aoki says:

        Admittedly I’m basing this mostly on the fact that mpg321 was last updated in 2012... but that does seem like a long time.

        • Ryan Farmer says:

          There's mpg123 and that's current.

          As I understand it, the mpg321 program only existed because mpg123 used to be under a non-free license.

          I don't have any MP3s though as I used Ogg Vorbis and more recently went back and transcoded my FLAC collection to Opus instead. (VLC on Android plays them fine).

  2. Steve Baker says:

    You're not using the in-built raspberry pi audio are you? If so, stop, get a hifiberry

  3. Duality K says:

    Not sure what your use case is, but I have reduced the ALSA bullshit in two different ways, for two different machines, without stacking additional bullshit (jack, pulse, etc) atop it.

    On my principal music computer I run mpd, controlled from a phone with MALP (or from a computer with whatever). mpd seems to be pretty good about not breaking even when flipping quickly through songs. No special configuration, straight to hw:0,3, my HDMI port.

    On my desktop, which is always 48khz stereo over SPDIF, I have a custom .asoundrc that can (and sometimes does) mix multiple inputs, and that may keep mpg321 from zombie-trashing the audio:

    pcm.!default {
    type plug
    slave.pcm "dmixer"
    }
    pcm.dmixer {
    type dmix
    ipc_key 1024
    slave {
    pcm "hw:0,1" (or whatever)
    period_time 0
    period_size 1024
    buffer_size 4096
    rate 48000
    }
    bindings {
    0 0
    1 1
    }
    }

    It's been a while for the latter example but I do recall it fixed a bunch of execrable BS. Of course, if the problem is that the Pi just has buggy audio hardware (and it might, they're kinda heaps), you might still be up the creek.

  4. CJ says:

    https://youtu.be/pgyI8aPctaI?t=88 comes to mind.

    (This is just a link to a joke about Linux, not anything helpful)

  5. mjog says:

    tl;dr run pulseaudio, and use a player that interfaces to that

    XScreensaver uses OpenGL rather than a low level driver interface, so use an audio player that does the same.

  6. Published Name says:

    pulseaudio -k && sudo alsa force-reload

  7. I've found lsof /dev/snd/* helpful in figuring out which rogue program is hogging my ALSA devices and not letting the apps I want to play sound play sound.

    (I've blamed PulseAudio for my troubles in the past until I finally did the lsof thing and figured out timidity-daemon that I installed long ago on a lark and never ever used would sometimes with the race and hog the ALSA audio device for itself.)

    The 5 second pause is worrying. I'd take a look at dmesg and see if the kernel sound driver is making any complaints?

  8. Paul N says:

    Genuinely surprised that this does not appear as a "previously": https://www.jwz.org/blog/2005/06/fuck-the-skull-of-alsa/ .

    • jwz says:

      Fixed. Also, a friend just helpfully interjected:

      Here's the deal: mpg321 is utter and complete trash. It never releases a lock unless everything goes wonderfully. ALSA makes mpg321 look like an enterprising little pig built it out of bricks. It's a pile of bad intentions and infighting. The problems here are that you're dealing with 20 odd years of crusty teenager socks, abandonware from the dark ages, Raspberry Pi's legendarily shitty ecosystem, and your own insistence on using perl and half a pack of bubblegum to make flint knives into motorboats.

  9. Zygo says:

    The key detail here is that it's a Raspberry Pi. Nothing you might read online about PC desktop/laptop audio on Linux will help you fix a Pi.

    The ALSA driver emulates an audio device using the Pi SoC's PWM controllers. It's roughly equivalent to PC speaker emulation, but at least it's a real hardware PWM so you get some bit depth (and there's more than one PWM so you can get stereo). Various Pi clones and hats add proper audio codec hardware chips, but these come with their own drivers, and if you had one of those and you had installed it correctly, you would be enjoying music right now instead of having this conversation.

    If you're on a stock Pi, everything that isn't omxplayer (the native Raspberry Pi media player) is probably going to suck. omxplayer sucks too (don't try to play anything shorter than about 5 seconds with it) but at least it can push audio in most formats mp3 format out the HDMI port for several hundred hours between forced reboots.

    Also note that "Pi occasionally hangs, doesn't crash completely, but needs to reboot to work again" is a symptom of a slightly-below-spec power supply. It could be related to audio problems only because the higher CPU usage during audio playback draws enough power to brown out. You could try swapping out USB wall-warts until you've tried a diverse set of those, or the problem stops, whichever comes first.

    • jwz says:

      I'm using a USB audio device so if the Pi's PWM controllers are involved in that, things are even more insane than I realized.

      I did suspect a power problem, but my meter says the power supply is in fact 5V 2A. I realize that answer is not always to be believed, but I don't remember what those circumstances are.

      • Torkell says:

        It's worth also checking the voltage at the Raspberry Pi itself. I've been caught out by a USB cable that had enough resistance to drop a whole volt when loaded at 500mA.

        • Dan says:

          I just had this happen yesterday. I'm just starting out with a Pi, and after hooking it all up, started getting low voltage warnings from the system immediately after booting. I was using a long USB cable, so I switched to separate power and it's fine. It really must run at the edge of what's possible with a normal USB port/cable.

      • David Konerding says:

        TBH you should absolutely question your power supply. I have 4-5 5V 2A supplies and only one of them actually makes the Pi work properly under load.

  10. Bill Paul says:

    As much as it may seem like dragging yet another clown out of the car, I'm forced to agree with the suggestion of using pulseaudio, assuming of course that you're not doing that already.

    You mentioned you're using a "USB TRRS headset adapter." I can understand the rationale for this: it allows you to avoid both the Pi's own sound hardware (which based on earlier comments seems a little primitive) and the need for screwing around with custom drivers (you can just use the USB audio drivers included with Linux).

    But it comes with a trade-off, because now you have the complicated mess that is the audio subsystem tied together with the complicated mess that is the USB subsystem, and you have to worry about:

    - Potential bugs in the kernel audio framework
    - Potential bugs in the kernel USB stack
    - Potential bugs in the USB audio driver
    - Potential bugs in the USB host controller driver

    You say the problem starts if you terminate mpg123 unexpectedly. That implies that the process could exit while an I/O transfer is still in progress. A graceful shutdown implies flushing any pending transfers in the audio layer _and_ any corresponding pending transfers in the USB layer, then closing down the device's USB descriptors. The two big secrets to getting this right are 1) implementing proper mutual exclusion so that shutdowns that occur while transfers are in progress don't result in corruption of internal state, and 2) knowing enough about the hardware to abort a transfer correctly in the first place.

    Oh, you also say that once things go wrong, sound is totally boned and attempts to start a process stall for about 5 seconds. I have a question: if you unplug the USB headset adapter at this point, does it have any effect on behavior? I ask, because the problem could be in the USB stack and there's a small chance that the resulting surprise removal event and deletion of the USB audio device might jog something loose.

    If mpg123 is accessing /dev/sndwhatsis directly in order to play audio, then my money would really be on a race condition bug that triggers when trying to close down the I/O channel while a transfer is in progress. In theory getting mpg123 to use pulseaudio might avoid this problem by letting the pulseaudio daemon manage the file descriptor access instead. I know this is like putting a firewall around the problem instead of fixing it, but debugging the Linux kernel is a lot more hassle.

    It looks like you can use "mpg123 -o pulse /some/audio/file" to do this, but your installation of mpg123 has to include the pulseaudio output module. Look under /usr/local/lib/mpg123 and see if there's an output_pulse.so dynamic object.

    • jwz says:

      You mentioned you're using a "USB TRRS headset adapter." I can understand the rationale for this

      That, plus I also need sound input, which onboard Pi hardware doesn't have.

      if you unplug the USB headset adapter at this point, does it have any effect on behavior?

      Tried that, nope.

      I'm giving sox's "play" a try now, and so far I haven't seen it fail again, so, fingers crossed?

      • Bill Paul says:

        Hm. Well that tends to blow a hole in my theory since I'm assuming the sox play utility is also accessing /dev/dspwhatsis directly. It might depend on the usage pattern (maybe mpg123 is fondling the device with a particular ioctl() that's making it mad). Or maybe it's just fucking magnets.

  11. Zygo says:

    OK, so USB audio counts as a proper third-party audio codec chip, so it should work with the USB audio drivers (which are just the drivers in a vanilla Linux kernel), to the extent that USB works on a Pi.

    I have noticed with USB network devices on Pis (mostly WiFi on USB-battery-powered setups), the very first thing that dies on a dodgy power supply is the USB device. The rest of the Pi will keep going after the USB device is dead, but the Pi has not detected a USB disconnect, the device is not working, and nothing short of disconnecting the USB device will fix it (alas, hotplugging a USB device on a Pi tends to reset the hardware). USB runs at 5V while everything else on the Pi board runs at 3.3V or less, so it's not surprising that USB devices die first. What is surprising is how strict about 5V some USB devices are, even though internally they're mostly 3.3V devices too. There's a wide range there--depending on the particular USB device, it might stop working properly when the power drops below 3.6V, or it might die right at 4.999V. An audio device sounds like the kind of device that might be strict about its input voltage.

    A powered USB hub between Pi and USB audio device might help. Also possibly helpful: use a shorter cable between the 5V supply and the Pi, use a cable with thicker wires, and/or replace an older cable with a new cable (old USB cables have worn connectors that carry less current due to reduced contact surface area, dirty contacts, or metal corrosion).

    I've put a raspberry Pi on an oscilloscope and watched the power ripple at 20MHz, 0.001V resolution. Sometimes identical-power-supply-A works with an actual Pi while identical-power-supply-B does not. Sometimes you do get to see where the slope of the power curve is too steep after the Pi switches instantly from drawing 1W to 3W--but more often, you don't, because the problem is some dynamic interaction between parts of the circuit that are hard to probe without drilling holes, or your measuring equipment changes the behavior of the circuit you're testing. The solution (if this is the correct problem) is the same in any case: swap hardware until the problem goes away.

    If none of that works...maybe install pulseaudio, then rip out the "helpful" modules like module-suspend-on-idle one at a time until you find all the modules that try to mess with apparently-idle audio device ports. That might work around something unfortunate happening in the USB audio stack (firmware bug, kernel bug, power spike, maybe even all three). Pulseaudio also normalizes buffer sizes and keeps applications from feeding random jun into the kernel audio driver, so it might accidentally work around some application-level defect I've never heard of.

    • dan mcanulty says:

      I know this is preaching to the choir, but USB 2.0 spec is that devices should function correctly down to a voltage sag of 4.40v. I say this, mostly so that if anybody else who designs usb powered devices is here, don't forget to check those things. At the very least, even a marginal and finicky device should be designed to handle 4.7v, because that's well within the usb output spec and a lot of hubs regulate to 5 and sag from there.

      A few companies have made power supplies that regulate to the 5.25v upper spec so they have a little extra room, but I think most hubs and such seem to just aim for a flat 5v and basically never hit it under load.

  12. kwk says:

    I have no help, but that is amazing. I was just telling a junior coworker about how miserable sound was on linux when I last used it on my personal computer in like 1999.

    • David Konerding says:

      Sound on linux in '99 was a relatively reliable thing. It wasn't very good but it mostly worked (when I first used linux, there was even a crazy driver that drove the hardware speaker as an audio device). It was the multiple projects (ALSA, pulse, jack) that messed things up (but were necessary to compete with other desktop OSes like Mac and Win that have great audio support). Actually, I like Jack, it's ALSA+Pulsa that is just constant "WTF why do I have to restart this daemon to use audio".

  13. Djarrp Fumpntzqump says:

    May i point you to https://github.com/ThomasKaiser/OMV4_for_Raspberries and
    https://forum.openmediavault.org/index.php/Thread/18991-New-approach-for-Raspberry-Pi-OMV-images/ ? This person seems to know what he is talking about, i know of him because of the armbian forums, which deals with all sorts of more or less crappy ARM SBCs under their debian/ubuntu based builds.