CamillaDSP - Cross-platform IIR and FIR engine for crossovers, room correction etc.

[HenrikEnquist]

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.

Ok let me know what you find.

I have not tried running CamillaDSP with any elevated priority, and my view is that it should be made robust enough to not need that. I always run it with standard priority as a normal user.

 

[pi r]

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 didn't save the error message, so I can't tell for sure.But I got the error message right when I tried to start camilladsp, who immediately halted.



Would the default installation of PA complain over a dependency to an too old lib..? And a gcc-lib..? Doesn't make sense to me... That would mean Ubuntu 18.04 was broken out of the box. Right?


I wish I had saved the message...

 

[pi r]

Hey in post #896, 897, 898, the errors are explained by Yoda himself aka' Henrik

Jesper.

Thanks, I'll check that.

 

[lykkedk]

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.

Good... sounds good

My Pi is installing/compiling the mathplotlib for hours and hours now, i will try to see if it will get too heavy to have running, if it success it will be ofcause...

You reached +1000 post in this wonderfull thread Henrik, congrats.... Should i start the car and drive to Sweden with a sixpack of beer now

Jesper.

 

[Fra8123]

@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):

 ... SetConfigName ... Reload ... SetConfigName ... Reload ...

Not an issue, only visible in the logg.

I can also see a WARN line about "Lost connection" from time to time:

[2020-10-08T15:15:48Z WARN  camillalib::socketserver] Lost connection: IO error: Connection reset by peer (os error 104)

Also not an issue, only visible in the logg.

Hi Pi R, I am using piCorePlayer and I am using SuperPlayer based on CamillaDSP v0.3.1. I am completely new in this world of DSP and room correction. Today I found the first room EQ based on REW. I have create the filter file by exporting the txt (I have tested it by using Equalizer APO). Please could you give me some help to start my journey? I am not sure how to apply the filter in SuperPlayer/CamillaDSP.


I take advantage of this post to renew my very thanks to all of you and a special thank you to HenrikEnquist and lykkedk for the amazing job and for sharing it.


Cheers,
Francesco

 

[pi r]

Hey in post #896, 897, 898, the errors are explained by Yoda himself aka' Henrik

Jesper.

Fixed..! No more IO Errors.
Thanks - Henrik & Jesper !


I still get double websocket commands in the log, about 1 second apart. But it must be squeezelite-custom that runs the python script twice. If I run it manually from the prompt, there is only one command in the log.

 

[soundcheck]

Just checked it.

camilla develop-branch

Build:

curl --proto '=https' --tlsv1.2 -sSf [url]https://sh.rustup.rs[/url] | sh
git clone --branch=develop --depth=1 [url=https://github.com/HEnquist/camilladsp.git]GitHub - HEnquist/camilladsp: A flexible linux IIR and FIR engine for crossovers, room correction etc.[/url] /tmp/camilladsp
cd /tmp/camilladsp
source $HOME/.cargo/env
##ARM
RUSTFLAGS='-C target-feature=+neon -C target-cpu=native'
cargo build --release --no-default-features --features FFTW

Run:

squeezelite -n slcdsp -b 20000:20000 -a 32 -o - |\
            camilladsp -v /etc/camilladsp/configs/config.yml |\
            aplay --quiet -D hw:0,0 -r 44100 -f S32_LE -c 2

Log:

[2020-10-09T06:09:45Z DEBUG camilladsp] Read config file Some("/etc/camilladsp/configs/config.yml")
[2020-10-09T06:09:45Z DEBUG camilladsp] Config is valid
[2020-10-09T06:09:45Z DEBUG camilladsp] Wait for config
[2020-10-09T06:09:45Z DEBUG camilladsp] Config ready
[2020-10-09T06:09:45Z DEBUG camillalib::filters] Build new pipeline
[2020-10-09T06:09:45Z DEBUG camillalib::filters] Build from config
[2020-10-09T06:09:45Z DEBUG camilladsp] Capture thread ready to start
[2020-10-09T06:09:45Z DEBUG camilladsp] Playback thread ready to start
[2020-10-09T06:09:45Z DEBUG camillalib::fftconv_fftw] Conv r_fir is using 8 segments
[2020-10-09T06:09:45Z DEBUG camillalib::filters] Build from config
[2020-10-09T06:09:45Z DEBUG camillalib::fftconv_fftw] Conv l_fir is using 8 segments
[2020-10-09T06:09:45Z DEBUG camillalib::processing] build filters, waiting to start processing loop
[2020-10-09T06:09:45Z DEBUG camillalib::filedevice] starting playback loop
[2020-10-09T06:09:45Z DEBUG camillalib::filedevice] starting captureloop
[2020-10-09T06:09:45Z DEBUG camillalib::filedevice] starting captureloop
[2020-10-09T06:09:46Z DEBUG camillalib::countertimer] Pausing processing
[2020-10-09T06:11:08Z DEBUG camillalib::countertimer] Resuming processing
underrun!!! (at least 80060,639 ms long)
[2020-10-09T06:11:33Z DEBUG camillalib::countertimer] Pausing processing

As soon as camilla is pausing the CPU goes up.

Not sure if the underun message explains the distortions I mentioned earlier.

 

[seashell]

Found another bug. Specifying the -w flag causes camilla to keep running after an ALSA error as you said it would which is good, but unfortunately it keeps the loopback capture open after the error and won't release it even after even after a Stop command is issued.

I tried to play a 22kHz file which my DAC doesn't support. mpd opened the loopback at 22kHz and my script told camilla to open its end at 22kHz. Camilla then got the EINVAL error from ALSA because the DAC doesn't support 22kHz, which put it into the state that it wouldn't let go of the loopback so nothing could play from mpd as it just keep seeing a 22kHz capable loopback connection.

 

[HenrikEnquist]

As soon as camilla is pausing the CPU goes up.

This was the missing piece! I was running without pausing. I can reproduce the problem now, which also means I can fix it

Found another bug. Specifying the -w flag causes camilla to keep running after an ALSA error as you said it would which is good, but unfortunately it keeps the loopback capture open after the error and won't release it even after even after a Stop command is issued.

I tried to play a 22kHz file which my DAC doesn't support. mpd opened the loopback at 22kHz and my script told camilla to open its end at 22kHz. Camilla then got the EINVAL error from ALSA because the DAC doesn't support 22kHz, which put it into the state that it wouldn't let go of the loopback so nothing could play from mpd as it just keep seeing a 22kHz capable loopback connection.

Ok I'll take a look!

 

[HenrikEnquist]

@soundcheck: can you try develop now?

 

[soundcheck]

I just did.

U managed.

top shows around 0.3%@idle and 3%@work

Case closed.

Thx a lot. A pleasure working with you.

And on we go.

 

[pi r]

@ Francesco:


Ehrm... I hope you realize that you turn to the guy with the least experience of DSPs in this thread..?

But I'll give it a shot, and hope for the others to step in where I fail.

I guess the first step is to create a basic configuration for camilladsp, without any filter. Just to verify that you can play music with squeezelite-custon through camilladsp. If you followed lykkedk's guide all the way, I guess you should be able to do that.

 

[phofman]

Henrik: if the long method capture_loop camilladsp/filedevice.rs at 700953355bf4ffc362f51d4542d70ba6f6ca8483 * HEnquist/camilladsp * GitHub were refactored into several submethods for each "usecase", would the compiler inline the submethods and avoid a potential performance hit? Thanks.

 

[Fra8123]

@ Francesco:


Ehrm... I hope you realize that you turn to the guy with the least experience of DSPs in this thread..?

But I'll give it a shot, and hope for the others to step in where I fail.

I guess the first step is to create a basic configuration for camilladsp, without any filter. Just to verify that you can play music with squeezelite-custon through camilladsp. If you followed lykkedk's guide all the way, I guess you should be able to do that.

Thank you so much for your reply. You are too humble . However I am staring from 0 and everything could really help me. squeezelite-custum is working fine and without filter as you said (thanks to the help of Lykkedk). N

ow I would like to apply the filter found with REW but I am not sure how to apply it in CamillaDSP. Should I use rephase or something else? Attached the the filter + a preamp of -6.3 dB.


Cheers!!!

 

[HenrikEnquist]

I just did.

U managed.

top shows around 0.3%@idle and 3%@work

Case closed.

Thx a lot. A pleasure working with you.

And on we go.

Nice! This was a tricky one, thanks for helping out.

Henrik: if the long method capture_loop camilladsp/filedevice.rs at 700953355bf4ffc362f51d4542d70ba6f6ca8483 * HEnquist/camilladsp * GitHub were refactored into several submethods for each "usecase", would the compiler inline the submethods and avoid a potential performance hit? Thanks.

I don't think it would inline them by default but you can force it to do it. The function calls would come with a tiny penalty. But considering that this loop runs once per chunk, the total penalty is negligible. I have already split out some parts of it to separate functions, but 160 lines is still way too long so I'm not done.



You often see functions that are several times longer and maybe that makes the code run a tiny bit faster. But it also makes the code much more difficult to work with and I don't think it's worth it. At work I was recently investigating a problem in a 600-line C++ function, took forever!

 

[HenrikEnquist]

Thank you so much for your reply. You are too humble . However I am staring from 0 and everything could really help me. squeezelite-custum is working fine and without filter as you said (thanks to the help of Lykkedk). Now I would like to apply the filter found with REW but I am not sure how to apply it in CamillaDSP. Should I use rephase or something else? Attached the the filter + a preamp of -6.3 dB.


Cheers!!!

That file can be translated to a set of Biquads.
This one:

Filter  1: ON  PK       Fc    2380 Hz  Gain   7.2 dB  Q 1.005

Becomes:

 filters:
    Filter_1:
     type: Biquad 
      parameters:
        freq: 2380.0
        gain: 7.2
        q: 1.005
        type: Peaking

Then just continue adding the rest underneath.

 

[Fra8123]

Hi HenrikEnquist,

Thank you so much, I really appreciate your help.

I imagine I have to add this filter for all the simple rate, don't I?

For the preamp is it correct to add the code below at the end?

type: Gain
gain: -0.0
inverted: false

So the filter should be something like the attached file, if I am not wrong (I used just the first three raw).

It is quite interesting and I can understand by myself that I still have to open the vase of Pandora .

Many many thanks again,
Francesco

 

[torgeirs]

Hello, Henrik
Thank you for your effort to bring stable 64 bit Xover to linux diy community
I am wondering if your resampling can be used for decimation. (Shorter FIR filters in bass applications)

eg:
-LP filter
-downsample
-Firfilter for needed room EQ and xo
-upsample
-LP filter
Ala STM 32 F4 Discovery and Audioweaver, anyone tried?

I'm a windows/visual studio/visual basic guy, so still struggling to understand the linux/rust/pyton lingo to be able to implement CamillaDSP on windows

 

[HenrikEnquist]

Hi HenrikEnquist,

Thank you so much, I really appreciate your help.

I imagine I have to add this filter for all the simple rate, don't I?

For the preamp is it correct to add the code below at the end?

type: Gain
gain: -0.0
inverted: false

So the filter should be something like the attached file, if I am not wrong (I used just the first three raw).

It is quite interesting and I can understand by myself that I still have to open the vase of Pandora .

Many many thanks again,
Francesco

You need to give each filter a name, and then add the properties below. Like this:

filters: 
  Filter_1: 
    type: Biquad  
    parameters: 
      type:Peaking 
      freq: 2380.0 
      gain: 7.2 
      q: 1.005 
  Filter_2: 
    type: Biquad  
    parameters: 
      type: Peaking 
      freq: 1822.0 
      gain: -3.7 
      q: 1.000 
  Filter_3: 
    type: Biquad  
    parameters: 
      type: Peaking 
      freq: 5778.0 
      gain: -5.0 
      q: 1.000 
  Some_gain: 
    type: Gain 
    parameters: 
      gain: -6.3 
      inverted: false

This is YAML so you have to be careful to keep the indentation correct. Put each sublevel 2 spaces more to the right.
You don't need to modify these filter definitions for the different sample rates, they can stay the same and the only difference between the different config files would be the samplerate in the devices section.

Hello, Henrik
Thank you for your effort to bring stable 64 bit Xover to linux diy community
I am wondering if your resampling can be used for decimation. (Shorter FIR filters in bass applications)

eg:
-LP filter
-downsample
-Firfilter for needed room EQ and xo
-upsample
-LP filter
Ala STM 32 F4 Discovery and Audioweaver, anyone tried?

I'm a windows/visual studio/visual basic guy, so still struggling to understand the linux/rust/pyton lingo to be able to implement CamillaDSP on windows

You could probably do that but it would get pretty clunky. CamillaDSP supports only one resampling, on the capture side. And then you have to resample all channels. To upsample again you would need to run two instances, the first downsampling and doing the processing, then feeding the audio via a pipe to second instance that upsamples to the original rate.
I thought decimation was mainly used when doing FIR with direct computation (on embedded systems where FFT may not be available and stuff like that), which gets very heavy for long filters. CamillaDSP does FFT-based convolution which is much much faster for long filters. I'm not sure you would gain anything by downsampling.

 

[pi r]

@ Jesper

I've bee struggling all day to activate Jivelite om my piCorePlayer. But when turned on, squeezelite-custom won't start. While the original squeezelite starts OK.
Turns out that you have compiled a newer version. And possibly from a different branch?

• Squeezelite Original: v1.9.6-1206-pCP
• Squeezelite-custom: v1.9.7-1218

There is an option "-v" in pcp's version, that is missing in your version (from help screen):

-v             Visualiser support

That option gets included in the start command when pCP boots (/usr/local/etc/init.d/squeezelite) and it makes your version halt with an error:

Option error: -v

And so no music...
(with Jivelite)

Is it that pCP has made their own fork of squeezelite, adapted to pCP? And you used some other to compile your squeezelite-custom... Or is it the new version?

(I'm running pCP v6.1.0, and starting squeezelite-custom manually works fine when Jivelite is running.)



/Pierre