Awesome! Could someone check whether the aarch64 camilladsp binary works? I downloaded on RPi4 and when trying to run, I get
Code:
gordoste@raspberrypi:~/camilladsp2 $ ./camilladsp -p1234 -w -s statefile.yml
bash: ./camilladsp: No such file or directory
Code:
gordoste@raspberrypi:~/camilladsp2 $ uname -a
Linux raspberrypi 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64 GNU/LinuxUpdate - You need to use armv7 on RPi. I think this means the setup script will be broken because uname -m returns aarch64
Last edited:
I'd read the documentation, there are some pretty significant changes depending on how you were previously using CamillaDSP. Biggest changes off the top of my head are:
1) No longer uses active_config.yml symlink and now uses a statefile when using GUI specified configurations. When running CamillaDSP I now use the -s flag to specify a statefile and also -w to wait for a configuration from websocket. If you are directly applying a configuration this change won't impact you.
2) Volume control is now applied to all channels by default. As a result, if you had volume filters in your old configuration you need to delete your old volume filters in the filters and pipeline sections. If you don't delete the old volume filters the configuration will give an error.
3) The way resampling is specified has changed. Specifically, the "enable_resampling" and "resampler_type" fields no longer exist and you need to delete them, otherwise you will get an error.
4) pycamilladsp nomenclature has changed quite a bit and if you have scripts developed based on the old nomenclature they will no longer work.
Michael
Last edited:
Are there any new dependencies or will this still do?
sudo apt install git python3-pip python3-aiohttp python3-jsonschema python3-numpy python3-matplotlib -y
sudo apt install git python3-pip python3-aiohttp python3-jsonschema python3-numpy python3-matplotlib -y
there are some changes in the precise output of GetConfigJson, e.g. previously keys with null values were suppressed but now they are included. I didn't see such changes menioned so I guess it's an unIntentional change?
Are you running that weird version of RPi OS that has a 32-bit userland on top of a 64-bit kernel? That combo might be tricky to detect correctly, any ideas are welcome.
The library dependencies are unchanged, but it now needs python 3.8 or newer.
This is intentional! The old way forced you to leave things out to use the default, and that made some things difficult. Now you can either leave them out or set them to null.
Could you try modifying the script to add double brackets where there are only singles?
For example:
if [ "$SYSTEM" == "Linux" ]
to:
if [[ "$SYSTEM" == "Linux" ]]
Yes, it's the official RPi recommended image. Let me investigate and I will submit a PR to allow the install script to handle this.
Sure, this is what I get.
Rich (BB code):
michael3@raspberrypi3:~/camilladsp-setupscripts-master$ ./install_venv.sh
./install_venv.sh: 8: [[: not found
./install_venv.sh: 20: [[: not found
This script must run on Linux or MacOS!Not a huge priority for me to be honest, so don't want to waste too much of your time troubleshooting.
Thanks!
Michael
This really looks like no file in that directory of that name. Different architecture is typically reported differently, IIRC.
@phofman I was waiting for someone to say that. I can definitely tell you that is not the issue as I checked it many times and used autocomplete.
Code:
gordoste@raspberrypi:~/tmp $ ls
camilladsp-linux-aarch64.tar.gz
gordoste@raspberrypi:~/tmp $ tar zxf camilladsp-linux-aarch64.tar.gz
gordoste@raspberrypi:~/tmp $ ls
camilladsp camilladsp-linux-aarch64.tar.gz
gordoste@raspberrypi:~/tmp $ ./camilladsp
bash: ./camilladsp: No such file or directory
gordoste@raspberrypi:~/tmp $ ls camilladsp
camilladsp
gordoste@raspberrypi:~/tmp $ objdump -f camilladsp
objdump: camilladsp: file format not recognized
gordoste@raspberrypi:~/tmp $ cd ../camilladsp2
gordoste@raspberrypi:~/camilladsp2 $ objdump -f camilladsp
camilladsp: file format elf32-littlearm
architecture: armv7, flags 0x00000150:
HAS_SYMS, DYNAMIC, D_PAGED
start address 0x0003b5a1Try changing the very first line of the script to
Code:
#!/bin/bashThis fixed it for me on RPi.
Submitted a PR to make the scripts work on Raspbian (specifying bash and using "getconf LONG_BIT" to detect 32-bit userland).
@gordoste: Ok, arm tools report differently than x86:
Now that makes much better sense 🙂
As of the bash shebang - IMO for a multiplatform installer (both linux and macos) it may perhaps be better to stick to POSIX /bin/sh and use the single = string comparison instead https://stackoverflow.com/questions/1089813/bash-dash-and-string-comparison
Interesting discussion regarding macos shells https://stackoverflow.com/questions/58492412/does-macos-prefer-bin-sh-or-bin-bash
Multiplaform support is always a fight...
Code:
~/tmp$ ./camilladsp
/lib/ld-linux-aarch64.so.1: No such file or directoryAs of the bash shebang - IMO for a multiplatform installer (both linux and macos) it may perhaps be better to stick to POSIX /bin/sh and use the single = string comparison instead https://stackoverflow.com/questions/1089813/bash-dash-and-string-comparison
Interesting discussion regarding macos shells https://stackoverflow.com/questions/58492412/does-macos-prefer-bin-sh-or-bin-bash
Multiplaform support is always a fight...
Yes, using single = is another option.
Personally I avoid putting /bin/sh in the shebang because there is quite a lot of variation between OSs/distros on what will end up running your code. At least with /bin/bash, you know that the syntax is the same everywhere. Newer versions have some fancy features but it's easy to avoid those.
P.S. have seen these confusing "file not found" errors before when dynamic link resolution fails 🙂 Hence my original suspicion.
Personally I avoid putting /bin/sh in the shebang because there is quite a lot of variation between OSs/distros on what will end up running your code. At least with /bin/bash, you know that the syntax is the same everywhere. Newer versions have some fancy features but it's easy to avoid those.
P.S. have seen these confusing "file not found" errors before when dynamic link resolution fails 🙂 Hence my original suspicion.
What behavior is expect from Default bypass in the pipeline?
BTW I've updatet my script to those whom like to install Squeezelite & CamillaDSP 2 with a woking configuration for RPi-OS Lite 64-bit. https://github.com/StillNotWorking/LMS-helper-script/tree/main/camilladsp#readme
From the main page on that repository you also find script to toggle Squeezelite output to different DAC/Loopback. And how to make menus in Material Skin to run this script and other aspects of the LMS system including open CamillaDSP GUI from Material Skin.
BTW I've updatet my script to those whom like to install Squeezelite & CamillaDSP 2 with a woking configuration for RPi-OS Lite 64-bit. https://github.com/StillNotWorking/LMS-helper-script/tree/main/camilladsp#readme
From the main page on that repository you also find script to toggle Squeezelite output to different DAC/Loopback. And how to make menus in Material Skin to run this script and other aspects of the LMS system including open CamillaDSP GUI from Material Skin.
Picking "default" sets it to null, meaning not bypassed. I think I'll get rid of that "default" option in the dropdown in the next version.
Thanks for the PR, I prefer to use /bin/sh, but the LONG_BIT method should work for that too. I combined these things here:
https://github.com/HEnquist/camilladsp-setupscripts/pull/9
This version adds the missing options for armv6&7. I also realized that "unzip" isn't always installed, so now it also tries to use "unar".
Can somebody try it?
Not the one recommended by me 😀
The full 64-bit OS runs fine, and using software compiled for aarch64 gives better performance.
Henrik, in the camillagui/README.md you wrote
"If you want to be able to view the log file in the GUI, configure CamillaDSP to log to
Would you explain a bit more for me, please. Do I add to the start command?
camilladsp -p 1234 -w -s /path/to/statefile.yml -o /path/to/log_file.log
I have the CamillaDSP and the GUI running but the log file is blank when viewed from the GUI.
"If you want to be able to view the log file in the GUI, configure CamillaDSP to log to
log_file"Would you explain a bit more for me, please. Do I add to the start command?
camilladsp -p 1234 -w -s /path/to/statefile.yml -o /path/to/log_file.log
I have the CamillaDSP and the GUI running but the log file is blank when viewed from the GUI.
Looking into it further, I will probably switch over when I get a chance. I figured there must be a good reason for their recommendation - silly me! I closed the PR so it doesn't hang around.