I will add the version of the gui frontend, and for pycamilladsp-plot. The versions displayed are defined in the code of each part. I didn't add any beta tags to avoid a bunch of things that need to be manually updated (and are easily forgotten) for each new beta. With a bit of luck there won't be any need for more betas.
I changed it to only show the GUI version:
And when you hover over that, it shows all of them:
I won't make a new beta just for this, so it will be included in the next release which hopefully is the final 3.0.0. I'll wait a couple of days to see if any more bugs show up.
And when you hover over that, it shows all of them:
I won't make a new beta just for this, so it will be included in the next release which hopefully is the final 3.0.0. I'll wait a couple of days to see if any more bugs show up.
Hi @HenrikEnquist !
FIrst of all, congrats on your work. This is an amazing piece of software!
I am facing an issue with camilladsp-gui. When changing a parameter of a filter (like the gain or frequency), sometimes the screen goes blank and a javascript error is thrown in the console. Any unsaved changes in the config are lost when I hit command-R to reload the page.
I am using what I think are the latest stable releases:
- CamillaDSP: 2.0.3
- pyCamillaDSP: 2.0.2
- Backend: 2.1.1
I am adding my config to this post.
Is this a known issue? Do you mind checking this out? I am more than glad to help if there is something that i can do (30+ years of software development, just not familiar with Rust). I can also open an issue in github if you prefer.
Thanks!
FIrst of all, congrats on your work. This is an amazing piece of software!
I am facing an issue with camilladsp-gui. When changing a parameter of a filter (like the gain or frequency), sometimes the screen goes blank and a javascript error is thrown in the console. Any unsaved changes in the config are lost when I hit command-R to reload the page.
I am using what I think are the latest stable releases:
- CamillaDSP: 2.0.3
- pyCamillaDSP: 2.0.2
- Backend: 2.1.1
I am adding my config to this post.
Is this a known issue? Do you mind checking this out? I am more than glad to help if there is something that i can do (30+ years of software development, just not familiar with Rust). I can also open an issue in github if you prefer.
Thanks!
This is a new issue! But there is a good chance that it's already solved in the upcoming 3.0 release.
There is nothing strange in your config file that should cause trouble. Can you find a way to reliably trigger the issue? A list of steps would be great, like 1) create new blank config, 2) add a filter of type Highpass, 3) Click the + button.... etc etc until crash.
Unfortunatelly I wasn't able to create a step by step procedure to replicate the issue from a blank config. However, the issue is happening in a deterministic way using my config (attached to my previous message). The steps to replicate using my config are:
- Import the config into CDSP
- Restart both services (camilladsp and camillagui) - don't know if it is needed but that's what I did.
- Open camilladsp GUI
- Go to Filters tab
- The second filter in the list is "0,1,2,3,4,5 - Tweeter/MidHigh/MidBass - Delay 2.5ms".
- Go to the "delay" input and press backspace twice. The first backspace will delete the number "5" and the second one will delete the dot.
I debugged a little bit and found out that the error is within undoDiff function in UndoRedo class. When this function calls jsonDiff, it throws the error.
In order to avoid this issue I edited index.tsx and removed the call to undoDiff function. Of course this is not a solution, but at least the error isn't happening anymore.
Please let me know if you were able to reproduce the error. If not, feel free to ask for any help - I can change the code, adding a few debug messages, so we can understand exactly what is triggering the error.
Henrik, I guess I just found the error:
Look at how the filter name gets to this method. This "~1" is actually a "/" (slash) in my config. Apparently there is some sort of encoding that is messing up with the filter's name.
I renamed the filter to use dashes instead of slashes and the error is not hapenning anymore.
Look at how the filter name gets to this method. This "~1" is actually a "/" (slash) in my config. Apparently there is some sort of encoding that is messing up with the filter's name.
I renamed the filter to use dashes instead of slashes and the error is not hapenning anymore.
Last edited:
Got it! Thanks for investigating! The json diff library returns the path with / and ~ escaped as ~1 and ~0 and I did not handle that. I have fixed it for the 3.0 release now.
I tested the new beta (CamillaDSP, pycamilladsp(/plot), CamillaGui) but I now get buffer underruns and
My setup is pretty standard - Motu M4 driving a sub and left/right mains, alsa loopback device capture. The hardware is quite limited (Radxa ROCK Pi S) but has been plenty enough until now and with the proper settings (SCHED_RR / Prio 45), CamillaDSP v2.0.3 never triggered x-runs with other resource-hungry tasks running in the background.
The v3 beta seems to use 10-20% more CPU than v2.03, but it shouldn't matter at those levels (eg. camilladsp v3 beta uses 40% of the CPU, and the board's total CPU usage is 50%). DSP load shown in CamillaGui is ~ 6% and the buffer level is stable when there are x-runs or errors.
I spent a couple hours trying various things; some tweaks improved the frequency at which x-runs happened, some not, but I'd still get x-run once in a while in the best case; eg:
Minor issue: I get an exception when trying to set the volume with pycamilladsp; The API must have changed but I couldn't find an updated doc (and I didn't have time to look at what the beta version of CamillaGui uses).
https://github.com/HEnquist/pycamilladsp/blob/next30/examples/set_volume/set_volume.py
I'm attaching a debug output of v3 beta with the gui running and the configuration I use. Happy to do further tests if needed. Worst case, I'll stick to v2.0.3 for this embedded system (and as always, thanks for your work!).
device is in an unexpected state errors, whereas v2.0.3 worked perfectly (same configuration obviously - the only change when migrating to v3 was to replace channel: 1 by channels: [1] (or a yaml list) in the pipeline section).My setup is pretty standard - Motu M4 driving a sub and left/right mains, alsa loopback device capture. The hardware is quite limited (Radxa ROCK Pi S) but has been plenty enough until now and with the proper settings (SCHED_RR / Prio 45), CamillaDSP v2.0.3 never triggered x-runs with other resource-hungry tasks running in the background.
The v3 beta seems to use 10-20% more CPU than v2.03, but it shouldn't matter at those levels (eg. camilladsp v3 beta uses 40% of the CPU, and the board's total CPU usage is 50%). DSP load shown in CamillaGui is ~ 6% and the buffer level is stable when there are x-runs or errors.
I spent a couple hours trying various things; some tweaks improved the frequency at which x-runs happened, some not, but I'd still get x-run once in a while in the best case; eg:
- increase chunksize from 8192 to 16384: this definitely decreased x-run frequency. Larger chunksize values introduce too much lag so I haven't tested long enough with eg. 32768 to tell if x-runs were gone.
- enable multithreading / no change
- change the resampling method from Synchronous to AsyncSync and AsyncPoly with various profiles : from no change to very bad (the higher degrees interpolation profiles of AsyncPoly peaked the CPU, resulting in a lot of x-runs).
- stopping CamillaGui lowered the frequency at which x-runs happened; I also didn't get
unexpected stateerrors anymore with the gui stopped but maybe that's because I haven't tested it long enough. Maybe something has changed in how the socketserver handles requests, eg. making it a lot more resource intensive for very short amounts of time, which don't show in the gui or looking at`top`'s output? - pinning camilladsp to a given cpu core / no change
Minor issue: I get an exception when trying to set the volume with pycamilladsp; The API must have changed but I couldn't find an updated doc (and I didn't have time to look at what the beta version of CamillaGui uses).
https://github.com/HEnquist/pycamilladsp/blob/next30/examples/set_volume/set_volume.py
I'm attaching a debug output of v3 beta with the gui running and the configuration I use. Happy to do further tests if needed. Worst case, I'll stick to v2.0.3 for this embedded system (and as always, thanks for your work!).
Last edited:
@t-gh-ctrl: I did not find any standard xrun in the log, only one which is likely when the stream starts up (the log is cluttered with the API logs).
Troubleshooting would require debug logs (maybe trace logs, but later on) around several xruns (or preferrably the whole zipped debug log).
Async resampler is more CPU intensive and not needed when using rate adjust for the loopback device.
Troubleshooting would require debug logs (maybe trace logs, but later on) around several xruns (or preferrably the whole zipped debug log).
No, the xrun happened in the middle of a song.
I wondered whether to edit the log or keep it as is - I'll filter the socket server lines out next time.
I know, I tested those only to see if they would make a difference...
I ran out of time today to do further tests; sometimes there aren't any xruns for 10 minutes, sometimes there are a dozen within a minute, without any visible cause (eg. no correlation with cron jobs, systemd timers, other tasks, etc.). FWIW I ran a few
cat /dev/urandom > /dev/null tasks in parallel to max out the CPUs at the same time camilladsp was running but it didn't trigger any xrun (so SCHED_RR with the right prio works well), but then I got a few xruns a couple minutes after I had stopped those tasks and the board was mostly idle.By the way I found how volume and mute functions have changed in camillagui's views.py and I fixed my python programs accordingly.
Thanks!
There are no changes in 3.0 that should affect performance of the DSP. But the GUI has quite some changes, for examplke in the parts that update the VU meters etc. I would think the extra load is cause by that. How does the load look if you close the gui?
BTW have you tried locking the CPU frequency? It may be that there are issues when the frequency changes. Some people had trouble with that some time ago. I haven't heard anything about that for some time so maybe some kernel or firmware update fixed that. Don't remember what platform it was unfortunately.
I have played quite a bit with Pi S. The CPU is low-performance. Just like Henrik said I would certainly recommend to switch to performance cpufreq profile. Switching CPU freqs can cause large cpu latencies which can lead to xruns. Also every Hz counts on that CPU.
You can also try to run CDSP recompiled to use float32 instead of float64 (--features 32bit ) as RK3308 Neon accelleration is quite weak for f64. IME it allows me to run at twice the resampling rate on Pi-S. But the software needs to be compiled on another computer as the 512MB RAM on the Pi-S is not enough for the rust compilation, IME. Either native compilation on arm64 RPi or cross-compilation on x86.
You can also try to run CDSP recompiled to use float32 instead of float64 (--features 32bit ) as RK3308 Neon accelleration is quite weak for f64. IME it allows me to run at twice the resampling rate on Pi-S. But the software needs to be compiled on another computer as the 512MB RAM on the Pi-S is not enough for the rust compilation, IME. Either native compilation on arm64 RPi or cross-compilation on x86.
I still get xruns without the gui running; ditto with the performance cpu scheduler set (/ cpu running at max freq)
It's interesting that you mention compiling, I also thought about that before reading your post. Indeed, I'll have to set up a cross-compile environment, as usual as on those tiny boards. Kinda lazy now to do that though 🙂
Henrik mentioned that there were no changes that should affect performance, so it could also be that the public beta binaries are built differently than v2.0.3 (eg. if there was a compiler update, optimizations may have changed since v2.0.3 binaries were built a few months ago).
I understand - but v2.0.3 has been rock solid on that board and I couldn't find any correlation between xruns with v3 beta and CPU load (because running other resource-hungry tasks in parallel didn't increase the frequency of xruns); so it seems there's enough "leeway" in term of available CPU cycles (I understand that the faster the better though, to decrease the probability of xruns when camilladsp gets preempted and whatnot).
The only workaround I found was to increase chunksize from 8192 to 32768 (-> no xruns for 3+ hours). But this comes at the price of quite a bit of latency when stopping/starting audio streams. The following warning is also displayed every second or so, which doesn't happen with smaller chunksize values, eg. 16384. For info the source (squeezelite) is playing at a fixed 44100Hz rate.
Note- I'm posting all that stuff hoping it helps finding regressions/issues in the beta; I'm not "bent" on having v3 work on my device, I don't want to waste your time!
Last edited:
Here is my setup on linux. It's similar on Windows 7
6ch is for normal 2-6 ch use. dolbysurround is self explicit for 2 ch use. quad is also self explicit. They all use the main speakers on the front wall.
The 90deg variations are used when the main channels are on the left wall, using RL and FL as main speakers and RR and FR as surround speakers.
The D1 variations are using new IR filters created for that new sound card.
6ch is for normal 2-6 ch use. dolbysurround is self explicit for 2 ch use. quad is also self explicit. They all use the main speakers on the front wall.
The 90deg variations are used when the main channels are on the left wall, using RL and FL as main speakers and RR and FR as surround speakers.
The D1 variations are using new IR filters created for that new sound card.
Attachments
Sorry to interrupt very specific conversation, what are the very most differences of Equalizer APO and CamillaDSP? What one can do what other can't? Can anyone simply point out to some comparison page on the internet, as cannot find that?
I am running Windows and using Equalizer APO, but it is not a problem to get some Linux box, so the OS requirements are clear
I am running Windows and using Equalizer APO, but it is not a problem to get some Linux box, so the OS requirements are clear
I guess nobody will be motivated to compile a near complete comparison between these two programs. Because it makes no sense: CamillaDSP is way more universal, versatile and elaborated in any terms. Therefore, you better may read the CamillaDSP user manual to compare by yourself. And I strongly would like to encourage you to compare and then to make your choice.
Last edited:
I will do that, thank you.
BTW, if I would like to use CamillaDSP only as electronic crossover on stereo 2-way, that is 4 drivers total - isn't it an overkill?
No, no overkill at all. CamillaDSP is perfectly fitting your needs instead. CamillaDSP is no CPU resources hog, in contrary. It runs very economically.
Try it out! You will be delighted then to discover all the possibilities to further linearize the drivers and tweak the whole system's response and and and ... Begin with a simple, but functional config, and then you can work through endless refinements if you like.
Learn by doing. But do.
Last edited:
Yes, but I kinda like to do it in a web interface way and automatic installers way, at this exact moment I haven't found couple clicks installation routine described. EQ APO has both.