WOW - What a treat..! 
Thank you Henrik..!
...for all the effort, and all the knowledge and skills that you have put into this project. And for giving it all to the public.
For many years I have been thinking that I should set up some lightweight linux system to run a software DSP for my HiFi. All the pieces have been available, and I have seen it been done by others.
But... learning and experimenting with low level configurations of both software setups and DSP filters, would require more time and effort than I were willing to spend.
But yet... quite suddenly am I sitting in my sofa with a BIG smile in my face... and my HiFi "sings" like never before - ever..!
WOW - What a treat..!
CamillaDSP was a true game-changer to me:
Since I already was using a piCorePlayer, it was natural use his implementation and excellent installation guide.
Thank you Henrik..!
...for all the effort, and all the knowledge and skills that you have put into this project. And for giving it all to the public.
For many years I have been thinking that I should set up some lightweight linux system to run a software DSP for my HiFi. All the pieces have been available, and I have seen it been done by others.
But... learning and experimenting with low level configurations of both software setups and DSP filters, would require more time and effort than I were willing to spend.
But yet... quite suddenly am I sitting in my sofa with a BIG smile in my face... and my HiFi "sings" like never before - ever..!
WOW - What a treat..!
CamillaDSP was a true game-changer to me:
- super simple to install with just one single binary file
- easy-to-read yaml config file
- very good documentation
- very good support from the developer
- Where/how do we send our donations to the developer?
- PayPal? Bitcoin? Swish?
Since I already was using a piCorePlayer, it was natural use his implementation and excellent installation guide.
Henrik, please what is the reason you used the num_xxx crates instead of the general num crate in your last commit? Is there some performance reason, future plans or something else? Thanks for explaining, I am spying on your performance fine-tuning to learn the options 🙂
Wow thanks for this, makes me very happy!WOW - What a treat..!
I'm a little curious, what platform and hardware are you running on? And is it for room correction?
I didn't really expect any donations, but I will of course not say no if you want to buy me a coffee 🙂 I think paypal might be the easiest, my email is in my profile on github!
"num" is a collection crate that includes a lot of things: https://crates.io/crates/num
It's very convenient to use num, but I really only used parts of it. This change removes something like ten unused dependencies!
Finally running and Camilla making crossover
. Actually everything was in the GitHub - HEnquist/camilladsp-config: Help for setting up CamillaDSP, example config files etc
For the Ubuntu 18.04 it is enough to compile camilladsp without PA:
RUSTFLAGS='-C target-cpu=native' cargo build --release --no-default-features --features alsa-backend --features websocket
nothing else needs to be changed.
How do I set samplerate of the DAC? Should I set rate in the asound.conf?
Many thanks
Just looked up the libfftw3 Debian package build file for AARCH64/arm64 to see if they enable NEON
It seems they do. That might be a reason why fftw3 is faster than Rustfft.
Code:
ifneq (,$(filter $(ARCHITECTURE), armhf arm64))
archconfflags_single := --enable-neon --with-slow-timer
endifIt seems they do. That might be a reason why fftw3 is faster than Rustfft.
Yep. Same issue as before.
Code:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
711 squeeze+ -41 0 209664 11224 3464 S 100,0 0,6 0:16.60 camilladsp
710 squeeze+ -41 0 111832 22172 1856 S 33,9 1,2 0:05.63 squeezelite
568 root 20 0 13692 7184 6104 S 0,3 0,4 0:00.08 sshd
1 root 20 0 17840 9240 6864 S 0,0 0,5 0:01.45 systemd
2 root 20 0 0 0 0 S 0,0 0,0 0:00.00 kthreadd
Last edited:
@Henrik:
I'm running a Rpi 3, with the latest piCorePlayer (6.1.0) and Jesper's modified squeezelite-custom. I just upgraded camilladsp to 0.4.0-beta3 (from tags), and fixed Jesper's *.py scripts as your instructions.
I'm currently "only" running a basic room EQ generated with REW. With 20 biquads per channel, and playing at 192k, camilladsp consumes about 10% of CPU. Playing at 44.1k it's only 2-3% CPU. Not bad for a Rpi 3.
This room correction field is quite new to me. I stumbled in to this thread about a month ago, and that was the trigger to start my DSP-adventure. With a hastily ordered mic, that arrived some 2 weeks ago, I've just got started... So much to learn...
Now for my second question:
I have tryed to start camilladsp with -w option, to wait for a config from Jesper's python scripts, triggered by squeezelite. It doesn't work. camilladsp never loads the config.
Should it work? Does it work for anybody else?
From the log output, I can see that:
- camilladsp starts and waits
- gets a websocket call to "SetConfigName" with a filename
- biquad constants is calculated (type: Peaking, in config)
- gets another call to "Reload"
- and then - no more...
It works fine when started without the -w option and a configfile, but it would be nice and clean to be able start with -w.
I'll append my logfiles for both the start options.
One odd thing I have noticed in the log, is that the websocket calls from Jesper's script, always is repeated (regardless how I start camilladsp):
Not an issue, only visible in the logg.
I can also see a WARN line about "Lost connection" from time to time:
Also not an issue, only visible in the logg.
I'm running a Rpi 3, with the latest piCorePlayer (6.1.0) and Jesper's modified squeezelite-custom. I just upgraded camilladsp to 0.4.0-beta3 (from tags), and fixed Jesper's *.py scripts as your instructions.
I'm currently "only" running a basic room EQ generated with REW. With 20 biquads per channel, and playing at 192k, camilladsp consumes about 10% of CPU. Playing at 44.1k it's only 2-3% CPU. Not bad for a Rpi 3.
This room correction field is quite new to me. I stumbled in to this thread about a month ago, and that was the trigger to start my DSP-adventure. With a hastily ordered mic, that arrived some 2 weeks ago, I've just got started... So much to learn...
Now for my second question:
I have tryed to start camilladsp with -w option, to wait for a config from Jesper's python scripts, triggered by squeezelite. It doesn't work. camilladsp never loads the config.
Should it work? Does it work for anybody else?
From the log output, I can see that:
- camilladsp starts and waits
- gets a websocket call to "SetConfigName" with a filename
- biquad constants is calculated (type: Peaking, in config)
- gets another call to "Reload"
- and then - no more...
It works fine when started without the -w option and a configfile, but it would be nice and clean to be able start with -w.
I'll append my logfiles for both the start options.
One odd thing I have noticed in the log, is that the websocket calls from Jesper's script, always is repeated (regardless how I start camilladsp):
Code:
... SetConfigName ... Reload ... SetConfigName ... Reload ...I can also see a WARN line about "Lost connection" from time to time:
Code:
[2020-10-08T15:15:48Z WARN camillalib::socketserver] Lost connection: IO error: Connection reset by peer (os error 104)Oh... I forgot that I also run camilladsp on my old laptop with Ubuntu 20.04 and REW. So that I can measure and verify my filters with REW through camilladsp. I tried at first with Ubuntu 18.04, but camilladsp (binary download) complained about a dependency: gcclibxxx-something(?) being to old. So I upgraded...
Is a dependency to gcc really necessary for a binary?
Is a dependency to gcc really necessary for a binary?
Hey 🙂 in post #896, 897, 898, the errors are explained by Yoda himself aka' Henrik 😀
Jesper.
Great! You should not need to do anything to set the samplerate of the dac. It should switch to the rate you select in CamillaDSP.Finally running and Camilla making crossover
Actually everything was in the GitHub - HEnquist/camilladsp-config: Help for setting up CamillaDSP, example config files etc
For the Ubuntu 18.04 it is enough to compile camilladsp without PA:
RUSTFLAGS='-C target-cpu=native' cargo build --release --no-default-features --features alsa-backend --features websocket
nothing else needs to be changed.
How do I set samplerate of the DAC? Should I set rate in the asound.conf?
Many thanks
Are you sure it wasn't something with PulseAudio? The version in Ubuntu 18.04 is too old, see the post by xorcz above.
I have tried this now, first with a simple python script that feeds values to camilladsp on stdin for a while, then stops for a while, then starts again. This works just fine.
Next up I installed squeezelite, and ran with the same command you did (except I piped the output of camilla to /dev/null). This also works fine. Actually squeezelite always gives me data at 44.1 kHz. I did not try actually playing anything through squeezelite since I don't have anything set up for doing that easily.
Not sure how to continue :/
Henrik.
I'am writing a guide on github howto "upgrade" my SuperPlayer, so to have the "no plot" webinterface enabled.
I have succesfully used folowing :
Should i use newer ones now?
Jesper.
I'am writing a guide on github howto "upgrade" my SuperPlayer, so to have the "no plot" webinterface enabled.
I have succesfully used folowing :
- Pycamilladsp-develop version ???
- Camilla GUI v0.4.2
- CamillaDSP 0.4.0
Should i use newer ones now?
Jesper.
Yep. Squeezelite feeds 0s on stop.
I checked brutefir for the same issue, which would have pointed towards squeezelite or the systemd setup as cause. I use exactly the same setup. brutefir works fine. Runs at 2% idle.
I am running the tasks preempted btw. They all run prio 40 and fifo as non-root user.
brutefir is build to work in elevated envs. Camilla too?
I'll setup a pipe manually tomorrow myself. Let see where that leads.
Regarding that CPU load - just 2 cents - the libsamplerate resampling in alsa (plug or rate plugins) is very inefficient, the best quality easily hogging a weaker CPU core. Since the playback chain is a library, all the load gets assigned to the player process. Has it been checked no such issue occurs?
The ones to use right now are:
pycamilladsp:
https://github.com/HEnquist/pycamilladsp/archive/v0.4.0.zip
pycamilladsp-plot (if you want the plotting):
https://github.com/HEnquist/pycamilladsp-plot/archive/v0.3.0.zip
camillagui:
https://github.com/HEnquist/camillagui-backend/releases/download/v0.4.2/camillagui.zip
Sometime in the next few days I will do some cleaning and merge everything to master. Then I will start on making some setup scripts.