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)
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.
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.
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.
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.
You’ve got it @Stefano - that’s absolutely correct. In fact, I let it run (sushi w/ 512 buffer and a fairly cpu and memory intensive program running on it) for several hours today, not a single issue. However after using pkill to stop sushi it will not start again until a system reboot. If that helps.
I installed grpc using vpkg. Protobuf was missing at the moment of building sushi. So I did:
sudo apt-get install protobuf-compiler
The missing protobuf message is gone. But now I am stuck at:
[ 32%] Linking CXX shared library libtwine.so
[ 32%] Built target twine
make[2]: *** No rule to make target 'GRPC_CPP_PLUGIN-NOTFOUND', needed by 'rpc_interface/proto-src/sushi_rpc.grpc.pb.cc'. Stop.
make[1]: *** [CMakeFiles/Makefile2:219: rpc_interface/CMakeFiles/sushi_rpc.dir/all] Error 2
make: *** [Makefile:130: all] Error 2
The output of ./vcpkg install grpc is:
Computing installation plan...
The following packages are already installed:
grpc[core]:x64-linux
Package grpc:x64-linux is already installed
Total elapsed time: 7.577 us
The package grpc:x64-linux provides CMake targets:
find_package(gRPC CONFIG REQUIRED)
# Note: 8 target(s) were omitted.
target_link_libraries(main PRIVATE gRPC::gpr gRPC::grpc gRPC::grpc++ gRPC::grpc++_alts)
find_package(modules CONFIG REQUIRED)
target_link_libraries(main PRIVATE c-ares::cares)
grpc is not recognized, nor is grpc_cpp_plugin:
$ grpc
Command 'grpc' not found, did you mean:
command 'grpck' from deb passwd (1:4.5-1.1ubuntu4)
command 'grpn' from deb grpn (1.4.1-1)
command 'gdpc' from deb gdpc (2.2.5-9ubuntu1)
command 'gmpc' from deb gmpc (11.8.16-15)
command 'grcc' from deb gnuradio (3.7.13.4-4build2)
command 'grc' from deb grc (1.11.3-1)
command 'trpc' from deb moonshot-trust-router (3.5.0+1)
Try: sudo apt install <deb name>
$ which grpc_cpp_plugin
$
@toani - do you need GRPC installed for your purpose? If not, all of those errors will go away by building with a flag that tells it to not use grpc. See the sushi github for that specific compiler flag.
Thanks so much for the hints. My system is an Ubuntu VM.
The grpc issue was indeed gone with the flag -DWITH_RPC_INTERFACE=off. Nonetheless, it was also gone after installing libyangrpc-dev. I also installed a few more dependencies that were missing to have the sushi build command run:
