I used to run patches on Raspberry Pi without much issue, but I am now getting really consistent crashes with the following error:

restart alsa output
alsa xrun recovery apparently failed

I can't figure out why. It seems to happen whenever I run anything even lightly intensive, but I have definitely run more complicated patches than this before. Anyone else run into this?

This seems to correlate with me starting to test things on a fresh Raspberry Pi install using the latest Raspberry Pi OS. The other funny thing that has started is that now, in order to get any sound at all, I have to specify the audio output in the command line when I launch a patch, like this

pd -nogui -alsa -audiooutdev 2 test.pd

I previously did not need to specify "alsa" or the headphone output (2).

another update - I've tried running the same patches on a newer model Pi. My previous issues were all on a Pi Model 3 B v1.2. I'm now running the same patches on a Pi 4 model B.

Overall it seems to run better, which is perhaps unsurprising. However I would have thought that a Model 3 would be able to generally perform decently well to play sound files and stuff.

The weird part is that while a patch is running on the newer Pi it will still often throw the "alsa xrun recovery apparently failed" error, but it doesn't seem to interrupt the sound output at all.

@yannseznec Solution here maybe........ https://github.com/pure-data/pure-data/issues/969 ..... but you probably need to recompile after modding src/s_audio_alsa.c
David.

hmm I'm not sure, isn't that bug fixed in the version of Pd that I'm running? I'm on 0.51.4 when I install from the Pi repo.

@yannseznec I suppose that's likely..... if you have the .c files in your distribution you could check that the bugfix code is in there.
Otherwise maybe there is more info on the RPI forums..... but if not then you could report a bug on the Pd list.... but..... maybe it is a problem with a particular Linux distro if that is different on the 3 and the 4.
Clutching at straws and although I have a RPI I don't run Pd on it.
David.

@yannseznec It looks like as of Oct 11 PiOS started to use PipeWire as the audio server. I don't know much about PipeWire yet but from what I understand it can be configured to release ALSA ports directly to applications or it can emulate ALSA for applications which do not speak PipeWire, I suspect the later is your issue, PipeWire on PiOS is likely configured for general desktop audio type tasks and not the needs of realtime audio. So you have a few options; you can learn how to get Pipewire to expose ALSA ports, configure Pipewire for realtime audio, disable/remove PipeWire completely which should be simple but could be a headache depending on how PiOS is setup, or just move to an older version of PiOS. In my limited experience with PipeWire it was not bad to work with and easy compared to PulseAudio but has yet to be fully implemented on my distro of choice so had some issues which caused me to abandon it for the time being. Personally I would learn to use it since it is going to become a fact of life in the very near future and has some nice features, but on a pi meant for live audio there is sense in just dumping it.

Edit: You could also try PipeWire's Jack emulation before digging in, might require rebuilding pd with jack enabled but it may solve the issues easily and not require having to deal with sticking to an old PiOS or dealing with OS update/fresh install configuration headaches down the road.

ok that is all super interesting, thanks! it seems likely a very likely culprit.

I think I will experiment with an older Pi OS to see whether it's better for Pd...do you (or does anyone else) have a suggestion for which version I should test with? I honestly can't remember which build I last used which worked reliably!