Thanks everyone. For anyone in the future requiring help on this: I got this working relatively easily thanks to a silly oversight - I had simply not connected the ground of the Teensy to the ground of the Raspberry Pi. I am now also powering the Teensy from the 5v of the Pi and it works well.

I have also been having some issues with stable Serial connection, and after some digging I learned that the Pi has a default Serial baud rate of 115200. That is likely faster than I need, but I couldn't figure out how to change this on the Pi (all the advice online seems to be for earlier OS versions...). So I instead changed the baud rate on the [comport] object to 115200 and it seems to work much better so far.

I'm not sure what you mean by "audio destruction" but perhaps my sound destroyer patches would be of interest https://github.com/yannseznec/soundDestroyer

I’m hoping to use serial data transmission between a Teensy and a Raspberry Pi using the Pi GPIO pins rather than a USB cable.

I have been using the [comport] object to do this previously over USB Serial, and that works (mostly) fine. However I have not yet managed to make it work by connecting the TX/RX pins between the Pi and the Teensy.

I am most likely doing something wrong, but before I dig too deep into what that might be I’m wondering if anyone has succeeded with this setup in the past, or is there some specific limitation that makes this not possible?

I'm wondering if there's any way of writing a signal to an array at something other than the current sample rate. I have always used tabwrite~ for writing signals to arrays, of course, but there does not seem to be much control over the speed of writing, you can choose a start point and then just start writing at the sample rate until you stop. Is it possible to write to the array at a slower rate?

I suspect that what I'm describing would require something like the poke~ object in max/msp, if that makes sense.

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!

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.

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.

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).

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?

For anyone stumbling onto this thread, including a future version of me:

I made an extremely bare-bones but functional example that takes button inputs from Raspberry Pi GPIO pins and sends them to Pure Data, I’ve put a minimalist example up on my GitHub along with some documentation: https://github.com/yannseznec/gpioOSCpd

I think it would be pretty straightforward to do GPIO outputs too, I just don't need to right now so I didn't bother!