Ignoring for the moment that you lose a lot of convenience and functionality when you go directly via Raspa for audio output. If you don’t care about losing midi / plugin compatibility etc. is there any other appreciable disadvantage to generating all of your audio outside of ElkOS and using Raspa directly?
To clarify a bit further, I am aware of the contents of this thread : Direct Raspa interfacing - intermittent crashes
Hi scratt and welcome to the forums. Raspa is part of Elk Audio OS, so technically you’re still using it even if you’re using it to get an audio callback directly and not using sushi 
As you already mentioned, you’ll lose the convenience of developing your audio code in the form of a plugin, which you could develop and test on a normal desktop/laptop computer. Sushi also gives you a realtime safe communication channel between the audio dsp and non-realtime parts. As well as ways of controlling the plugin directly both from another process or remotely via Midi, OSC, gRPC, etc.
There’s nothing inherently unique about that though, you could have the same functionality and performance without using sushi, though there would be more work on your part. You would need to set up some calls in twine to be able to use twine outside of a plugin, you can look at the sushi code for how to do that.
Thanks for the clarification / confirmation @Gustav.
We’ve been using both Sushi / VST and “pure” Raspa approaches as we build out our concept. But we’re at the point now where we’re either going to need to heavily modify Sushi or create our own “thing”.
Thanks for the points about twine.
Which reminds me… sensei doesn’t support I2C right?
It’s not obvious to me that it does right now. And for our purposes were using ioctl currently. But I did wonder if we were missing anything there? From the docs it seems like it might be possible to try and define the I2C pins using sensei’s config parameters?
Ehum, sensei is really kind of deprecated. The version we put in the ElkPi release is only supported on the ElkPi development board, which we have no plans to produce more of. The next version of Elk Audio OS will likely not include sensei at all.
I would rather recommend building something with python and ElkPy that talks to sushi over gRPC.
Good to know.
We have a bunch of custom stuff that we are talking to so we’ll likely just handle this ourselves in this case.
Very likely all of the I/O will actually be offloaded onto a dedicated board that streams processed updates to the main board.
So it’s helpful to be able to discount it at this stage as a component in the stack.
We are 100% C / C++, and whilst the grpc protocol is super exciting (even as an inter-process bus - which we experimented with), we really need the entire DAW, including UI to run on the main motherboard and be as tightly coupled as possible.
Sounds exciting. When you have something cool to show we’d love to hear about it.
Something that might be of interest to you is that the next release of sushi will have support for using it as a library, so it’s perfectly possible to wrap it into a gui app. The api is practically the same as for gRPC, but its a native c++ api than can be linked statically. You can test it out from the development branch here GitHub - elk-audio/sushi at develop
Oh! That is great news! Using sushi as a library would, I think, be pretty close to a perfect scenario for us. It was something we wondered about for a while.
We still want lower level access for some things, so I wonder how access to raspa is if it’s also being driven via sushi… but I am sure we can figure that out. That was part of the debate we had when trying to figure out where to insert ourselves into the stack.
We are very close to having something to show actually. And my intention is to try and do some short posts about it here once we have some images of the prototype that we feel are of interest to others. Currently both the UI and the actual device are a little bit of a Frankenstein’s Monster!
If you are interested in testing bleeding edge stuff, I have just updated the develop branch of sushi and all its related libraries with the current state of development. This is pretty close to what will be released as 1.2 before the end of the year.
Will definitely take a look. Thanks.
Will this work against the current released image of Elk OS, or would we need to build a fresh image for this?
Should work afaik, no important api changes.
In the end we needed to build a fresh image. Not just for Sushi; but for some config / partition size changes we need.
I think we’ve done this correctly. In order to get Sushi 1.2 to build with kirkstone we pointed the hash to the latest commit in the develop branch and only had to remove one license file check for spdlog (which doesn’t seem to be used anymore), and modify the branch for lv2 to main (it was set to master).
However, once the image is almost complete we see this error…
ERROR: libcheck-0.15.2-r0 do_package_qa: QA Issue: /usr/bin/checkmk contained in package checkmk requires /home/yoctouser/elk-audio-kas-configs/build/tmp/hosttools/gawk, but no providers found in RDEPENDS:checkmk? [file-rdeps]
I am guessing, but I wonder if this is a dependency that Sushi 1.2 needs that is not obvious to us in the config? In which case I am unsure if this needs to be added to the sushi_git.bb or higher up in the build tree.
Don’t know about that one. Though we are in the final stages of completing the 1.1 release of Elk Audio OS (which will include sushi 1.2). Though that is based on scarthgap rather than kirkstone.
EDIT : Posting for anyone else who comes here : Upping the meta-poky layer tag slightly fixed that. But tbh I have no idea how sane of a fix that is.
Thanks for coming back to me. That’s exciting! Is that likely to happen before year end? I would also be willing to volunteer as a crash test dummy if you have a dev branch for that?
In the meantime we’ll try to figure this out. Learning the build process is still of value even if it’s slightly confusing at times. 