Did you set your CPU governor to performance before the broadcast? Setting this is highly recommended.
Can you make sure that all desktop effects are disabled in your desktop environment settings.
"Disable WiFi and close any programs that do not need to be open when recording such as browsers. Many have reported disabling WiFi has led to more reliable JACK performance." - Do you use ethernet or wifi?
Do you happen to have bluetooth service enabled and running? Disable it if so.
Please paste output of:
cat /proc/interrupts
and
cat /etc/security/limits.d/audio.conf
Did anything jack settings change between the shows? Please, keep a log (on paper or text doc) of your jack settings each show. You're going to have to experiment with periods/buffer size/sample rate to get something that works for you.
But you have to do some detective work::
- boot w/ low-latency kernel
- set cpu governor to performance
- with various jack settings, start test broadcast (just as you do a real show) and proceed as follows:
Try to see xrun count with jack settings: 3 periods/256 buffer size@48000. Test your settings by trying to make xruns happen... really push your system! For example, try to change songs every second or as fast as you can to see if you can force xruns. If you can force xruns, your settings need to be adjusted. Adjust the buffer size to 512 and try to force xruns again... and so on until you find a setting w/ lowest # of xruns. Make sense?
To better understand your system, you'll want to benchmark it. There is a tool that will artificially load your system to generate xruns. You can run different to tests to try to pin down optimal jack settings.
You'll have to download and build the tool in terminal like this: