CMake Protobuf error when building Sushi

Hey all, building sushi using the Elk sdk to increase buffer size and I am running into a missing ProtoBuf executable error when attempting to build. I cloned the repo and and all sub modules as documented in the Sushi git readme and am using the latest release of the toolchain.

The command I used:
./generate --cmake-args="-DAUDIO_BUFFER_SIZE=512 -DVST2_SDKPATH=/workdir/VST2_SDK" -b

Error output: CMake Error at /workdir/sysroots/x86_64-pokysdk-linux/usr/share/cmake-3.14/Modules/FindPackageHandleStandardArgs.cmake:137 (message): Could NOT find Protobuf (missing: PROTOBUF_PROTOC_EXECUTABLE) Call Stack (most recent call first): /workdir/sysroots/x86_64-pokysdk-linux/usr/share/cmake-3.14/Modules/FindPackageHandleStandardArgs.cmake:378 (_FPHSA_FAILURE_MESSAGE) rpc_interface/cmake/FindProtobuf.cmake:125 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) rpc_interface/CMakeLists.txt:7 (find_package)

Was able to successfully build Sushi after using apt-get to install Protobuf. Perhaps this should be listed as a missing dependency?

Hi @drnfckdrn,
I’m not 100% sure but I’m pretty confident that protobuf is a dependency of gRPC itself.

Can I ask you how did you install gRPC?

The issue atm is that the version used is usually not packaged in any major distro. We are actually updating these days the gRPC version in SUSHI to match the one used by Debian testing, exactly because if we do that then we can pretty much write a line like

sudo apt-get install package-X package-Y etc.

in the SUSHI dependencies, or even prepare a .deb package or similar more easily.

Thanks for the info, I followed the gRPC build steps as documented - just tried a second build w/o gRPC and you are correct Protobuf not required so very well may be an issue with the gRPC setup I did.

On another note, I built sushi for a buffer size of 512 (I’m correct in this being the max size, right?) - got it running perfectly on the ELK RPI dev kit. However, after initial usage I receive this message and sushi is no longer operable and requires a reboot: kernel[150]: [ 384.447162] Internal error: Oops: 807 [#1] SMP ARM kernel[150]: [ 384.549958] Process sushi_b512 (pid: 281, stack limit = 0xb5cde220)

This issue occurs with both the included plug-ins and my own which would lead me to believe it’s with my new Sushi build as opposed to any of the plug-ins I’ve made. I assume I’ve exceeded the stack limit but beyond that I’m not sure how to rectify? Any ideas, every seen this @Stefano?

Hi Saul,
sorry I thought you were building a native Linux build rather than cross-compiling.

The error on stack limit with 512 might be related to how much memory we allocate on the driver itself, I don’t think we have tested that size on the RPi.

Maybe @Nitin knows more about it.

We haven’t tested 512 buffer size. The highest I have used is 128. The driver allocates enough memory considering 512 size too though.
I need to investigate this, haven’t seen this message before.

1 Like

Thanks for the replies guys - the interesting part of the issue to me is that it runs seamlessly for prolonged periods of time, it is only after stopping the first run of sushi that the issue occurs. If that provides any insight.

Hi @drnfckdrn,
Do you get that crash when you close Sushi with Ctrl+X ?
I think I know what this issues is if that is the case.

Hey @Nitin, I’ve been closing Sushi using pkill sushi

Hey @Nitin & @Stefano - regardless of this issue, can you confirm the largest buffer size sushi can be built with is 512? The github documentation would lead me to believe that but if I can go higher I’d like to

edit: successfully built sushi w/ buffer size of 1024, received RASPA error that memory buffer is too large - took a peek at the raspa repo and saw in src/common_defs.h that other sizes are supported but not optimized. What does this mean exactly? I assume that I could (in theory at least) rebuild raspa with a different max buffer size (i.e. 1024) definition and find out?

Hi @drnfckdrn,
SUSHI itself should not have any real limitations in the buffer size. Maybe it’s just a matter of redefining some constants in the CMake config but really we don’t have any assumptions there regarding the buffer size.

The culprit in your case is mostly the memory allocated by the driver, which is then used by RASPA. You’ll have to rebuild the driver here:

but better to ask @Nitin for details about memory allocation in that context.

We hardly work with those big buffer sizes as mostly people want to use Elk for low-latency stuff but it’s good to make sure it can be used in those contexts as well.

Hi @drnfckdrn,
I just ran into an example where I got your error from RASPA after loading a plugin chain that was using too much RAM.

Which makes me wonder, could it be the RAM usage of your plugin is too big for the Pi 3?
Have you tried to run SUSHI with the offline frontend on the Pi to see if the plugin loads and, if so, what’s the RAM consumption (check using top/htop)?

The current image is not optimized for memory consumption but still it’s not that hungry either. On a side note, we’re at good point with porting Elk to the Pi4 (audio runs already, we’re working on Yocto packaging) and that will be a much better choice if you’re in need of lots of RAM.

Hi @Stefano - sorry for the delay. I’ll recheck the memory when I hit the issue - just to reiterate, the issue seems to occur regardless of memory usage at 512 buffer size. I had previously checked using htop. Basic pass through is fine but issue still occurs. The effect is that sushi will run for a prolonged period of time but once sushi is killed system requires a reboot.

Excited about the pi4 build!

Hi @drnfckdrn,
thanks for the update.

So IIUC, the issue only happens after you kill SUSHI? No crashes at all when SUSHI is running the first time?

If that’s the case, very likely something that goes wrong in the kernel module deinit phase.