Hello, I feel like I've been blowing the forum up recently, sorry if I'm coming across as needy

This seems like it would be discussed a lot online but I cannot find relevant advice on it despite some intensive searching.

I'm running a Pure Data audio patch on a RPi, with an external USB soundcard. The patch samples from an external microphone and plays back the sounds in a sequence to a beat. When this 'beat sequence' playback happens, it is routed and recorded as another discrete sound file. Recording and playback are triggered by buttons connected via an Arduino Nano and the pduino object.

As I've been working towards my deadline to finish the device and ship it, the patch has become more prone to a specific audio glitch where it freezes mid sound, kind of like a skipping CD. I've experienced this before on other projects but never this frequently! I would assume I am demanding more than I should of the RPi, but I don't feel like it's a particularly processing-heavy project.

Are there ways I can avoid this glitching/skipping/freezing, either by making changes within the patch or by somehow optimizing the way my RPi is set up and running? It's only required to run this patch, so I'm wondering if purging a load of unneeded software that came with the OS might help.

Here's the patch in case that is a useful reference (I have a few abstractions I've put in there):

Any advice gratefully received - I'm worried this won't be up to a usable standard if it keeps glitching out during use!

@Dizzy-Dizzy Try putting this.......... one.pd just after all the bangs that are sticking.
They will all let just one message pass... and they can all be reset at the same time by sending any message into a [send reset]..... just a temporary measure to see what is going on.......
Maybe you can then verify that it is an audio hang rather than repeat messages from the arduino switches.
If the bang still sticks but audio is good then you have repeat messages.
If the audio still glitches then it is back to other solutions.

It is likely that reducing USB to 1.1 means that you have a lower rate of messages from the arduino switches as they bounce, and so bigger jumps between messages.
As you are not likely to push the same button again within 2 tenths of a second maybe you should lock messages out for 200ms in [button_debounce_time]
What do you have inside that abstraction?

Try replacing [vline~] with [line~] as you are just doing a fade in and out and [line~] is good enough for that.
In fact [line] would be good enough and if it "zips" you can set a finer grain than the 20ms default.
[vline~] is more expensive...... scheduling across block boundaries, and the [vline~] are doing their stuff just as you write and read files.

Replace the audiolab highpass filter with [hip~ 120]....... again, likely to be less expensive.
As a last resort get rid of [realtime] and just use [delay 5000]
But really the patch (if we are seeing it all) is not very heavy so I would put my money on those switches.....

David.

I don't have too much experience with RPi, but sometimes on other linux machines you have to set certain values in limits. https://jackaudio.org/faq/linux_rt_config.html
Again idk that much about RPi (what does it use for 'disk'?) but the bottleneck could be reading from and writing to whatever it uses to store the soundfiles.

@seb-harmonik.ar Usually they use the same flash drive that stores the OS..... so certainly faster than a hard drive...... but flash drives are of variable quality.

@Dizzy-Dizzy You could also disable the Wi-Fi and network cards if it has them..... and you are not using them....... basically anything that can interrupt the processor and cause DPC latency.

Plus....... maybe important...... delay the "1" message to start [readsf~] by a few milliseconds...... maybe 5 or 10 which should be unnoticeable. That gives it time to load a little of the file to ram before it starts playing.
You could compensate anyway for that delay in the delays after your [metro]....... so that the file is opened just before you need to play it.

And..... run Pd with the command flag -rt
You will have to start Pd from a script for that I think..... unsure... it Windows it would be something like
start "c:/path to Pd/pd.exe" -rt
In Linux only that runs Pd with real time audio.
David.

@whale-av here's the inside of the debounce abstraction: I set the one on my 'record button a bit longer (400ms, on the left) to see if that would help... I seem to be getting 0 messages from the button before it is released, which cuts off recording too early, sometimes before any audio is even captured! Maybe I need to replace the button itself?

@Dizzy-Dizzy I don't know how many buttons are available, but maybe you could use one for start and another for stop?
But do they send continuous messages?
A [change] after the inlet of the debouncer might help generally (not with the record button problem though)..
David.

@whale-av I had four buttons, so I changed up what they are controlling and have dedicated one for start and one for stop, which seems to have helped a lot. Adding the [change] object is also a great tip. Thank you!

This whole thread has been so useful, thanks all. I will be returning to it for future project also, when I have more time and I'm starting a bit earlier in the process.

Audio outputs saturated ?

@Il-pleut Can you expand on this? Saturated as in over zero?

Ensure your USB Soundcard is pi compatible?

Hi,

I haven't read the whole discussion, so I don't know if this was mentioned. I've worked a lot with RPi's and Pure data and here are my suggestions from experience.
First, get a Rasperry Pi 4 with 16 gigs of RAM. Since I've been using that I've had no problems, no glitching at all. Also, get rid of all the toggle boxes and number boxes, and any other GUI objects. Use a counter instead of a toggle and use a float object instead of a number box, things like that. I think the gui objects slow down everything.

I hope that helps.