Audio glitch after 40mins

Patchbox OS
1

I am using a script to broadcast to icecast, which works very well, and then 40 minutes in it starts to glitch. I have a Sure mic connected to the audio port in the PiSound.

You can here the sound here:

Check around 40minutes in, where the sound start to distort.

Here is the script I am using (no worries about the p/w it’s public),
the setting for ffmpeg are mostly for the icecast server. For Jack,
I didn’t configure much of it.

ffmpeg -ac 2 -f jack -i ffmpeg -acodec libmp3lame -ar 44100 -minrate 192k 
-maxrate 192k -content_type audio/mpeg -ice_public 1 -ice_name 'open 
meditation' -ice_url 'http://anonradio.net:8000/anonradio' -ice_description 
'damaru.yoga meditation' -f mp3 
icecast://openmic:nRNkIE@anonradio.net:8010/openmic >/dev/null 2>&1 &
sleep 5;

jack_connect system:capture_1 ffmpeg:input_1 &&
jack_connect system:capture_1 ffmpeg:input_2;

I wonder what could create that ? Underpowered raspberry pi ? Memory getting full ? Buffer overload (if it’s a thing??)

2

Running the
sudo patchbox-config
I assume I can change some of the jack setting.
Would making the buffer bigger helps or other settings?

ffmpeg audio rate is 44100 for the icecast server, does it help to have jack the same audio rate?

3

When this starts happening, try running the following commands:

free -h
top
htop

to get a sense of current system usage. Then run these commands to see the logs:

dmesg
journalctl -u jack           # Hit 'end' key to go to the latest lines

And finally, when this starts happening, try connecting system:capture_* ports to system:playback_* ports, so the captured audio goes directly to the output without involving ffmpeg or icecast, to better close in on the source of the problem.

Also, try using larger -n or -p parameter for Jack, to see if it makes a difference. In case your purpose is recording / streaming, and you don’t require immediate feedback, these params can safely be set to quite large and stable values.

Pisound only supports 48kHz, 96kHz and 192kHz rates. Ideally you’d want to use the same sampling rate for everything. I don’t think resampling to 44.1kHz is the source of the issue, unless the software has a bug. If you are running 64 bit OS, try doing the same test running on 32 bits if possible and see if there’s a difference.

4

Yes so after the bug, I did jack_connect the input to the output so I could listen in (which I should have done before) and the glitch was still there, so it’s not from ffmpeg from what I can understand. Yes I can live with a long delay as I am broadcasting and listener already have many second delay,

So a larger -n or -p parameter for Jack will only add a bit of ‘delay’ while adding stability? And would a RT kernel help in this situation?

Also can an underpowered PI create such a weird effect? I have a 2.5 amp power supply.