Guitar pedal bad sound using Juce cross compiled VST3 and HifiBerry DAC + ADC

This one has me baffled, maybe someone here can help diagnose what I’m seeing. I’m running my own cross compiled VST3 guitar plugin on Elk Audio OS, Raspberry Pi 4, and HiFiBerry DAC + ADC, setup shown below:

But when I run my plugin in sushi and plug in my electric guitar, I hear no sound out. If I loosen the guitar input (1/4" to stereo 1/8")) by pulling it out slightly but still allowing some connection, I hear a sound out. It sounds like what my plugin should do (overdrive), except there’s bad static sound as well. Not sure if this is from the poor physical connection or internal processing. I recorded the sound and posted to soundcloud:

Keith Bloemer · Rpi4HifiBerryElk BadSound

I’ve tried both 1/4" inputs (using the adapter shown in setup picture), and changing the config for mono instead of stereo, and different samplerates, but I get the same result, complete silence when it’s fully plugged in, and the above sound when loose in the connector. The HiFiberry card has a jumper for changing input impedance, and I tried all these settings (0dB, 12dB, 32dB) with the same result (just louder for the higher dB).

I thought maybe the adapter cable was bad, but example mda fx guitar plugin works fine with my guitar fully plugged in, and it sounds the same when it’s loose in the connector. Here is my config file (which I copied from the mda fx config):

I cross compiled the vst3 using JUCE and the elk toolchain, as instructed in the Elk documentation (including the O3 optimization export):
And I also made all the required modifications to the projucer file.

If I use the exact same makefile and use just “make” on Ubuntu 18, the vst3 compiles and runs normally in my DAW (normal build, not headless) Note that this is using an intel based laptop.

When running in sushi I get no error, but I do have a high cpu usage for sushi, which might be correct (my plugin does alot of computation under the hood) but I’m not positive. I double checked and Im using the Release build, not Debug. Here is the usage printout:

As you can see, one of the sushi processes is at 99%. I did notice that increasing the buffer size from 64 to 512 helped me hear the underlying sound of my plugin better. Maybe the static sound is coming at the beginning or end of each buffer and not from the dsp in the plugin? Another thought I had was maybe I didn’t remove the GUI elements properly in my plugin source code, and it’s causing some kind of processing issue/high cpu usage there. I did use the Juce 6 build lines directly from the Elk documentation though, and that includes the headless build flag.

I’m not sure what to try next, so I wanted to ask here and see anyone has ideas. I’m using JUCE 6.08

Thanks in advance!

After reading this:

I’m wondering if the strange behavior and high process usage is being caused by mode switching. Is there a way to tell from my process output? My plugin uses some large c++ libraries like Boost and things for matrix computation so I’m not completely sure what’s going on in there with memory allocation.

2nd Update:
When I use a XLR to Balanced 1/4” connector I hear sound out when it’s plugged in all the way, but it still has the bad static sound. So I think I have two separate issues (one being the bad static sound and the other being the input connection issue). There’s a difference in the connector (left is Balanced from a mic, right is unbalanced guitar line in). The other difference would be the level (dynamic mic vs guitar line). Still don’t know why the mda plugin would work with the guitar fully plugged in, but mine doesn’t.

Hi and thanks for trying Elk!

Fortunately I can see that your’e not having mode switches. You can tell by looking at the MSW tab of the cat /proc/xenomai/sched/stat output. Having a few constant ones on boot is normal. The thing to look out for is when that number is increasing while running.

From listening to your soundcloud file (thanks for providing) and looking at the stat output I’m fairly certain the issue your experiencing is buffer underruns due to heavy processing. As you can see your plugin is using 99.7 % of the cpu. As this is an average it’s quite likely that it’s even going over 100% at times.

I don’t think any left in GUI components would be a problem as they should mostly only contribute to the binary size since were never creating the GUI in sushi. Then again it depends on how the GUI was implemented.

I would suggest you look at ways to further optimize the plugin. Maybe there are some parts that can be removed to make it run better? I’m guessing even on your Ubunutu PC it would be using a noticeable amount of CPU even though it has more processing power than the RPi. One thing I had trouble with while porting open source plugins was convolution reverb so if you’re using that maybe try without it?

1 Like

You could also try to profile your plugin to get a better picture of where the bulk of the work is done. It’s possible to do on the RPi but even a result from your Ubuntu should be representative

1 Like

Thanks for the response, that’s good news, although I have my work cut out for me in optimizing the code. It’s something I wrote myself using neural networks, Im confident it can be optimized further but it’s going to take some time to figure out. What are your thoughts on multi threading with sushi? Since the Rpi4 has four cores (2 for real time and 2 for non RT?) is this doable?

I’m planning on trying a balanced line in and see if that solves my connection problem. I also noticed that the HiFiberry has a higher input voltage limit on balanced vs unbalanced, so maybe I’m reaching that limit with my unbalanced guitar cable.

Thanks again and very excited about using Elk!

Update: Using a balanced input cable fixed the connection problem I was seeing.

HI @keyth72,
nice project!

Regarding this:

The way scheduling works with Xenomai, you can’t have non-RT threads running concurrently with RT threads. However, you can use as many concurrent RT threads as you need if you can split your RT load in that way. Take a look at the Twine library for that:

1 Like

Awesome, thanks for the info. I’m hoping to be able to optimize it enough to not need multi threading, but if it comes to it I’ll look at twine.

When I get it running well on the Pi and finalize the plugin I’ll share it on the forum and on the community repo.

1 Like

Success! I was able to get my plugin optimized with the help of someone alot smarter than me, using a custom library for real time neural nets. It makes use of SIMD operations, and it pushed the sushi process usage down to 16% on the Raspberry Pi. I recorded a quick sample using my plugin and the included mda “delay” and “ambiance” effects: