Choppy sound on older Raspberry Pis

[albedozero]

Originally posted by @insomniacUNDERSCORElemon in #1 (comment)

Not sure my Pi fast enough for it, though... it didn't take long to crash, and sound is choppy most of the time.

if I understand correctly that you're using a Raspberry Pi 2B, that would explain your audio issues. I consider the Pi 3B+ to be the baseline model for the synth to work smoothly. I notice some latency on a Pi 3B. I used to have a Pi 2 available, and sound was pretty choppy. You can improve this by increasing audio.period-size and audio.periods in the SquishBox/fluidpatcherconf.yaml file, but at the cost of audio latency.

I'm not sure this is the issue. A single note can play just fine. Playing at a moderate pace or multiple notes is where it gets choppy, like the CPU is not fast enough to process it (and keeping at it causes it to crash). Probably depends on the sound font too.

[albedozero]

Not having enough audio buffers or buffer space could still cause this issue - if you're playing a single note the CPU doesn't have to generate a lot of voices, so it has enough cycles to get the audio out with the smaller buffers. Once you're playing more notes, the slower Pi 2 can't keep up and you get choppy audio.

When you say the Pi crashes eventually - can you be more specific? Are you getting any error messages? That might help diagnose.

[insomniacUNDERSCORElemon]

When you say the Pi crashes eventually - can you be more specific?

It shuts the Pi down (and again, this is during playing not when switching fonts/patches). I am not sure if there are any log files (or how to see it over SSH when it happens).

You can improve this by increasing audio.period-size and audio.periods in the SquishBox/fluidpatcherconf.yaml file, but at the cost of audio latency.

I doubled the default values (because it seemed right and you didn't give a reccomendation) and it did not improve it (it sounds exactly the same). Also I looked at htop, it is at 100% CPU and 100% swap (218/429 on memory though) when not even playing any notes. I'm not sure if it was this high before, but I suspect it was and that's the issue.

Maybe CPython or something else similar could help?

Though also I took a screenshot and something else is running _apt with /usr/lib/apt/store using some CPU too. I didn't actually notice this when I was looking at it live so I'm not sure how much it's contributing.

[albedozero]

Possibly fixed/improved by #8

[insomniacUNDERSCORElemon]

I manually edited this into the .service file, the initial run started at 50% cpu and seemed to almost work for slow-tempo (long notes consistently hitched a little, same with multiple notes simultaneously especially more than 2). It still crashed after a short time, the boot after that was just entirely a mess just like before (though it's possible I did something wrong with the edit though it did run the first time).

Sidenote: a small addition you could add would be a startup-jingle (3-5 played notes, see the Steam Controller jingle that has multiple options), this would make knowing when the boot process is done easier (rather than mashing a key until it plays).