Sushi as library, reactive mode, on Bela Gem Multi

Elk Audio OS Sushi
1

Hi folks,

I am currently doing some preliminary analysis with the goal of having Sushi running in a relatively simple Bela wrapper.

I was considering using Sushi as a library in Reactive mode, and I saw in the docs that it currently only supports a stereo use case and a single MIDI device.

I would need at least 8, and ideally 10, audio inputs and outputs (Bela Gem Multi provides 10in, 10out), so I wanted to ask whether you know of any challenges I might face if I tried to fork Sushi and make it compatible with such a setup.

My understanding is that Reactive is already the right integration model for Bela, i.e. Bela would own the RT audio callback and forward audio/MIDI to Sushi from there.

The main question for me is therefore whether extending Reactive from stereo to 8/10 channels is mostly a frontend/configuration patch, or whether deeper assumptions would get in the way.

FWIW, I think I would need to:

  • make Reactive audio I/O counts configurable instead of hardcoded to stereo
  • plumb those counts through the Reactive config/factory path
  • possibly lift any frontend channel count limits

My main questions are:

  • Is Reactive’s stereo limitation mostly superficial, or is stereo assumed deeper in the engine?
  • Are there any known obstacles to running Sushi this way with 8–10 ins/outs?
  • Would you recommend extending Reactive, or writing a dedicated Bela frontend instead?

I’m fine with the single MIDI device limitation, as I will only need one.

Thank you so much!

Leo

2

Hi Leo. Sounds like a fun project. Without knowing much about how the Bela audio api looks like, but if you have direct access to the audio api, my best bet would be on writing a new audio frontend for Bela. Iirc Bela is also xenomai based, so you could probably start from the XenomaiRaspaFrontend.

The reactive frontend was originally made for embedding sushi in a plugin and running inside another Daw on a desktop/laptop. Hence we did it with a limited scope (only stereo, one midi port, etc) but sushi supports any number of channels so it shouldn’t be a lot of work overcoming those limitations. If Belas api is closer to that of an audio plugin then the ReactiveFrontend might be a better choice.

Another aspect to keep in mind is twine, which encapsulates some low level threading details. It might work more or less out of the box, but it might also need some work to in order to work properly on Bela.

Good luck.

1 Like
3

Okay thank you very much @Gustav !

So far to me it looks like I could make the Reactive mode work in a small Bela project, which actually looks pretty much like a plugin/host, so pretty close to what is intended for Reactive mode. Haven’t tried anything yet, I am still researching and waiting for the shipping of my Bela Gem Multi to arrive.

It would be so awesome if it works out of the box, it would save me SO MUCH work to redo and I really loved the Sushi/Plugins dev workflow, it suits my project so well.

I’ll keep you updated.
Thanks again !

1 Like
4

Hi @Gustav and everyone interested.

As I’ve mentioned here in further details, Sushi does work as-a-library using the reactive frontend.

I will open-source my project and custom tooling (docker crossbuild image, bela handy scripts) as soon as I like it enough to make it public, which should happen soon (™)

Cheers !

5

Sounds incredibly cool. From your description it sounds like you squeezed every bit of juice possible from the Bela board :slight_smile: .
Please share what you’ve done when you feel it’s in a nice state. Would be really fun to see.

1 Like
6

Very fun indeed ! :smiley:

Here is the PR for multichannel support on the Reactive Frontend, fully tested and validated working today : feat(reactive): multichannel I/O, CV/Gate routing and timing correctness by LeoFabre · Pull Request #13 · elk-audio/sushi · GitHub

Please keep in mind that I used Claude Code to help with a great part of it, but FWIW all of it looks decent.

I am working on separating the docker tooling from my own preamp project repo so that anyone can use it without having my specific stuff in it and I will use it as a submodule and give you the link :wink:

7

Okay here it goes !

Enjoy !

1 Like
8

Just to follow up on this :

After a week of extensive testing, I can confirm that this works really well if you have a small enough config and/or big enough latency budget (I’m talking about running Sushi with the reactive frontend in a bela project, didn’t try running Sushi natively).

I wanted to run a big config with a small dozen of tracks with several internal and VST3 plugins with the absolute smallest latency possible and 0 underruns.

I had success with 0 underruns when increasing buffer size and/or sample rate, but I wanted to target 48KHz and a maximum of 32 samples of bufsize. Before optimizing, with JUCE plugins, I had 350 underruns per minute and OOM kills.
Using DPF to lower memory footprint and optimizing DSP code (NEON SIMD vectorization, feature enabling only when necessary, using fast math and other optimization flags) lowered it down to approx. 70 underruns per minute, (HUGE improvement) but keep in mind my config is pretty big.

FWIW (but I’m still not 100% sure), the only underruns I had left were due to processors waiting on memory. With ten plugins on one worker that makes ten DRAM round trips, and this looked like what was my bottleneck.
The CPU on the Bela seems to have periodic memory-bus stall episodes (~100 ms bursts where memory latency spikes ~3–4×).
Looks like hardware, not contention: same underrun rate on 1 RT core vs 3, and going lock-free changed nothing.
It basically underruns when (worst-case per worker) × (stall ~3–4×) > period budget (~667 µs at 48k/-p 32).

I haven’t pinned the exact reason causing the memory bus to stall, so there might still be hope for bigger configs to run fine. With my optimized plugins I was hanging around ~20%CPU maximum on any core so in the end it’s pretty capable if you can survive the ~450mb budget for the whole system (+ sushi eats ~250mb off of this, IIRC).

That’s why I gave up on using Sushi for my project, which I really hoped not to, but I gave myself a week maximum trying to make it work and that’s now over.

I’m currently refactoring my DSP code into a home brew Bela native c++ project so that everything stays in cache and I never have to worry about any back-and-forth with the DRAM.
No underruns at 44.1KHz/bufsize 16 for now !

Cheers and love to the ELK team and to Sushi, I had tons of fun working with it.
Too sad that there is no bigger I/O audio interface for the Pi 4/5 that we could play with. There is a hole in the market ! :slight_smile: