Random freezes running a plugin sushi

Elk Audio OS
1

Hi everyone,

I’ve been experiencing random full system freezes when running some plugins with sushi. I made some experiments and could reach some (potentially wrong) conclusions:

  • Freeze does not seem to be related with CPU temperature or usage: I constantly monitor temperature and does not go above ~50º, also CPU usage always stays at ~25% and freezes happen also when I’m not sending any notes to the plugin and there are no active voices
  • Freezes do not happen with all the plugins. I can build the ELK JUCE example and I get no freezes, but if I deploy the plugin I’m making myself (compiled using the exact same JUCE version and toolchain) I do get freezes.
  • Freezes sometimes happen right after loading the plugin, sometimes after 5-10 minutes of using it.
  • I see no logs in sushi nor system logs that happen at freeze time.
  • When the system freezes, if the plugin was making a sound, the audio outputs a constant (quite annoying) tone until I power off the raspberry pi
  • If I don’t have sushi running, I get no freezes
  • This happens with ELK Audio OS 0.9, but it also happened with previous versions

Obviously there seems to be something wrong with my plugin and I’ll do some further investigations by modifying parts of it. However, I guess there should be some way to get more hints on what is going on. Any suggestions of how could I debug that?

Thanks!

frederic

2

Hi Frederic
From your description, it does sound like there would be something wrong with your plugin. Though it’s hard to be specific from your description.

If you are logged in to a terminal on the board, do you see anything printed when the board freezes?Any dmesg prints or anything?

Perhaps a long shot, but most of the cases I’ve seen of outright freezes have been related to timer calls in a xenomai thread, i.e clock_gettime() or gettimeofday(). For some reason, those system calls seem to be able to break more things than “regular” syscalls like mallocs or mutexes.

Regards
Gustav

3

Hi @Gustav, thank you very much for your response.
I’ve been doing some more debugging and I could finally see that, as you say, some timer call were made in the audio thread. The issue is that I was not aware about these calls because these were made from a 3rd party library. I replaced the calls with twine versions of them and now I don’t seem to get freezes anymore!

thanks

2 Likes
4

Great to hear that you fixed it!