CamillaDSP for Room Correction

[hkphantomgtr]

Would you please advise or share your experience more about installing and running CamillaDSP in SO?  Much appreciated.

Please have a look at post #9 in this thread. It contains all my notes from my original install.

Alright, Thanks a lot, Snoopy8!

Did you manage to get CamillaDSP working?

My NUC failed and I had to build a new box using Ubuntu 22.04. I followed the instructions on post #9 and it worked. Also, no need to install Pulse Audio. However, I have the advantage that I had a working config file doing convolution.

I'm sorry that I didn't try.  Now I'm testing another OS with build in convolution dsp filter.

[Snoopy8]

Recommend rebooting after enabling or disabling CPUsets within SnakeOil. Just realised that the maximum latency goes crazy after the change.

[Snoopy8]

Notes for AK for 1.3.1 implementation of CamillaDSP.

Been using this webpage to routinely reinstall CamillaDSP for 1.3 testing.  Have not done the web gui.
https://github.com/HEnquist/camilladsp-config

There is a good long tutorial on ASR to install CamillaDSP ​on a Pi. Has links to other web resources as well.
https://www.audiosciencereview.com/forum...ial.29656/

Some things that require attention:

• config.yaml is the critical configuration file.  Suggest providing several standard ones like what Moode does.  Users can, of course create their own config files but put warning that debugging can be painful.  
  
• While config file has rate and format settings, need to ensure that asound.conf has matching settings
  
• Set priority of CamillaDSP.service to less than 50.  Otherwise, it could interfere with IRQ of USB, causing huge latency problems.
  
• Suggest setting aside a CPU for DSP using cpuset. And a separate CPU for player.  LMS has a much higher max latency than Mpd 
  

Happy to assist with getting CamillaDSP into SnakeOil. AK, please let me know what you need.

[agent_kith]

Happy to assist with getting CamillaDSP into SnakeOil. AK, please let me know what you need.

Need help testing everything is working is a good start, more importantly not break as an on-going concern. As I'm unlikely going to use DSP in my home rig. 

But before that, just aiming to get the 1.3.0 out this weekend, and focus on 1.3.1 immediately after.

[Snoopy8]

Need help testing everything is working is a good start, more importantly not break as an on-going concern.

Have both my NUC and Mercury (CM4) running CamillaDSP as system service. The use of loopback to capture and process the signal may throw users off.  And it did interfere with the 1.3 firmware upgrade, with the Music Player stuck until I stopped CamillaDSP.  

Having CamillaDSP in the chain can also cause latency problems.  Add in CPUsets and it can be a headache.  I have gone back to using standard SO CPUsets and minimum change in process priority to reduce the number of variables to manage. As an aside, my latency problems were caused by using too large a convolution filter (lesson learnt: don't be greedy!)

The biggest danger is users being too ambitious with the custom use of DSP and we may end up spending too much time solving these. Note that my use is limited to convolution.  Any other use case will be new for me.
​​​​​​
Having said all that, the documentation is much better than I first started. And I have both X86 and Pi versions running which will make testing easier.
 

As I'm unlikely going to use DSP in my home rig. 

You should give convolution room correction a go. I see it as having more of an impact than real time kernels.

[agent_kith]

Have both my NUC and Mercury (CM4) running CamillaDSP as system service. The use of loopback to capture and process the signal may throw users off.  And it did interfere with the 1.3 firmware upgrade, with the Music Player stuck until I stopped CamillaDSP.  

Having CamillaDSP in the chain can also cause latency problems.  Add in CPUsets and it can be a headache.  I have gone back to using standard SO CPUsets and minimum change in process priority to reduce the number of variables to manage. As an aside, my latency problems were caused by using too large a convolution filter (lesson learnt: don't be greedy!)

The biggest danger is users being too ambitious with the custom use of DSP and we may end up spending too much time solving these. Note that my use is limited to convolution.  Any other use case will be new for me.
​​​​​​
Having said all that, the documentation is much better than I first started. And I have both X86 and Pi versions running which will make testing easier.

Thanks for that. I am/was a bit too ambitious thinking I can release 1.3.1 in 10 days time with Convo added to the WebApp. Unfortunately in 10 days I only managed to add the page, and not actually populate the contents.

Ten days sound like a long time, but it's gone just like that.

Did get a lot of things done though, just don't feel like it's enough. Maybe it's because I'm getting older, things just can't get finished quickly.

You should give convolution room correction a go. I see it as having more of an impact than real time kernels.

My worry is my computer are so low powered I'm not confident any advantage it brings will be offset by the additional power it consumes.

[Snoopy8]

CamillaDSP has come a long way since I first started using it.  For Pi users, there is now a good installation guide which has a GUI to make things a lot simpler to use.
https://github.com/mdsimon2/RPi-CamillaDSP