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

Jump to Latest
T

torgeirs

Member
Joined 2011
HenrikEnquist said:
I started looking a little at polyphase filters when I started on the resampler. I actually use a simple form in the asynchronous resampler. But doing more general filtering seems a bit tricky and I would need to do a lot of reading, so I didn't continue along that path. It's interesting though and I would like to dig into it. If I only had more time...
Click to expand...

Yes, that time squeeze:(
Polyphase is part of the multirate litteratur. Fun to see that the same problems that is disqussed in this thread, was also discussed 37 years ago:
Multirate Digital Signal Processing Crochiere-Rabiner - Free Download PDF
No mention of Rust, linux or rpi though:cheerful:
But IIR, FIR, resampling and filtering in detail
 
lykkedk

lykkedk

Member
Joined 2002
@Henrik...

The new plotting without numpy is working on my pCP.
My testrig is an RPI3B and it's loaded pretty hard....

The higher the samplerate, the higher load, and i use two filter pr. channel as seen in the plotting... Perfect! :D

Code: 
CPU: 26.1% usr  0.9% sys  0.0% nic 72.6% idle  0.0% io  0.0% irq  0.2% sirq
Load average: 1.08 0.63 0.46 3/139 8280
  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
 8162     1 root     S    41160  4.1   3 23.2 /usr/local/bin/camilladsp -p 1234 /home/tc/camilladsp/44100.yml
 8142     1 tc       S     129m 13.2   1  2.0 /usr/local/bin/python3 /home/tc/webface/Backend-0.5.0/main.py
 8161     1 root     S    39788  3.9   2  1.8 /usr/local/bin/squeezelite -n Stinout -o - -a 80:4::1: -b 10000 20000 -r 44100 192000 2500 -s 192.168.1.29 -U -U -d output
 8278  8179 tc       R     3208  0.3   3  0.0 top
    9     2 root     SW       0  0.0   0  0.0 [ksoftirqd/0]
 8276     2 root     IW       0  0.0   2  0.0 [kworker/2:1-eve]
 8271     2 root     IW       0  0.0   1  0.0 [kworker/1:2-eve]
 8277     2 root     IW       0  0.0   0  0.0 [kworker/0:2-eve]
 8160     1 root     S    16056  1.6   0  0.0 /usr/local/bin/python3 /usr/local/bin/samplerate-daemon.py
 8178  8175 tc       S     5076  0.5   0  0.0 sshd: tc@pts/0
 8175  1407 root     S     5076  0.5   1  0.0 sshd: tc [priv]
 1407     1 root     S     5076  0.5   3  0.0 /usr/local/sbin/sshd
    1     0 root     S     3208  0.3   0  0.0 init
  819     1 tc       S     3208  0.3   0  0.0 -sh

Within the nearest future i will try it on my RPI4B, i think it would be much better.

Most important, it's working!

Jesper.
 

Attachments

  • Shot_1.png
    Shot_1.png
    72.1 KB · Views: 179
  • Shot_2.png
    Shot_2.png
    191.5 KB · Views: 177
  • Shot_3.png
    Shot_3.png
    120.1 KB · Views: 177
lykkedk

lykkedk

Member
Joined 2002
Hey guy's...

I can't remember detail's about my filters; i created them months ago :)

My workflow was.
Taking 4 measurements, around center + center of listning posistion.
AVG them and create EQ with REW (EQ are samplerate independt at this point)
This is the Pre-Filter.

With Pre-filter in convolver (camilladsp), i took 4 more measuremnt's and AVG'ed them.
Those measurement's are then samplerate converted and after that i created new filter's with DRC-fir or DRC-Designer. (As i remember :confused::):confused::))

Therefore i have a chain like this. -The -9dB gain is to avoid clipping.

Jesper.
 
P

pi r

Member
Joined 2014
@ Henrik:
I just found a silly little remark on the help screen from camilladsp 0.4.0-beta-5 (and previous I supose):
The "usage" line suggests that the "configfile" is mandatory "< >", when it is optional "[ ]" - isn't it..? :eek:

Code: 
USAGE:
    camilladsp [FLAGS] [OPTIONS] [COLOR=darkred]<[/COLOR]configfile[COLOR=DarkRed]>[/COLOR]
should be:
Code: 
USAGE:
     camilladsp [FLAGS] [OPTIONS] [COLOR=darkred][[/COLOR]configfile[COLOR=DarkRed]][/COLOR]
Beta-5 is working great though... :)
 
HenrikEnquist

HenrikEnquist

Member
Joined 2016
pi r said:
@ Henrik:
I just found a silly little remark on the help screen from camilladsp 0.4.0-beta-5 (and previous I supose):
The "usage" line suggests that the "configfile" is mandatory "< >", when it is optional "[ ]" - isn't it..? :eek:

Code: 
USAGE:
    camilladsp [FLAGS] [OPTIONS] [COLOR=darkred]<[/COLOR]configfile[COLOR=DarkRed]>[/COLOR]
should be:
Code: 
USAGE:
      camilladsp [FLAGS] [OPTIONS] [COLOR=darkred][[/COLOR]configfile[COLOR=DarkRed]][/COLOR]
Beta-5 is working great though... :)
Click to expand...
The config file is mandatory by default, but can be made optional with the -w flag. I think it's better to keep it the way it is, since it reflects the default.
Btw the help screen is autogenerated by the really neat "clap" library which handles parsing of the command line options.
 
TNT

TNT

Member
Joined 2003
Paid Member
But -9? Does that make sense - in a digital channel containing processing, either a stage clip or not (digitally) - once it time for D/A conversion, it might be a good idea to see that no digital level exceeds -3,2 dB rel all bits being 1's.

Or?

There is no summation in the path where one in the end need to do like 3 (stages) x -3 dB??

I think :)

//

lykkedk said:
Hey guy's...

I can't remember detail's about my filters; i created them months ago :)

My workflow was.
Taking 4 measurements, around center + center of listning posistion.
AVG them and create EQ with REW (EQ are samplerate independt at this point)
This is the Pre-Filter.

With Pre-filter in convolver (camilladsp), i took 4 more measuremnt's and AVG'ed them.
Those measurement's are then samplerate converted and after that i created new filter's with DRC-fir or DRC-Designer. (As i remember :confused::):confused::))

Therefore i have a chain like this. -The -9dB gain is to avoid clipping.

Jesper.
Click to expand...
 
P

pi r

Member
Joined 2014
HenrikEnquist said:
His filter has a peak gain of just over +8dB! Check the blue curve in the plot from the gui. Considering that, I don't think -9 is unreasonable :)
Click to expand...
But I am still lost here... I thought that the -9dB clip gain had to be done before the filters. Or else the clipping has already been done..? Is there "unlimited" amplitude margin as a result of float calculations?
 
F

fluid

Member
Joined 2009
In some DSP's it does need to be done before because they have hard limits and will clip if you don't. In software it is much easier to leverage the dynamic range of the bit rate and avoid that, if the processing is done at 64 bits then there is 384dB of range which makes inter process clipping almost impossible. But if you don't bring it down afterwards the result will be the same :)

In Jesper's case he might actually need -12dB to avoid any oversample peaks.
 
W

wineds

Member
Joined 2006
Untitled.png
HenrikEnquist said:
I found a few bugs, most important one is that the amplitude axis of the impulse response plot was missing. I also added axis labels.
And I optimized the fft used to plot FIR filters, it's about 4x faster now!


New versions:
Backend:Release v0.5.1 * HEnquist/camillagui-backend * GitHub
pycamilladsp-plot: Release v0.4.2 * HEnquist/pycamilladsp-plot * GitHub
Click to expand...

Excellent! All good now Henrik. Thanks. plotting takes less than seconds now. Filters are 65536 taps I think .dbl format generated by rephase.
 
Last edited:
lykkedk

lykkedk

Member
Joined 2002
fluid said:
In some DSP's it does need to be done before because they have hard limits and will clip if you don't. In software it is much easier to leverage the dynamic range of the bit rate and avoid that, if the processing is done at 64 bits then there is 384dB of range which makes inter process clipping almost impossible. But if you don't bring it down afterwards the result will be the same :)

In Jesper's case he might actually need -12dB to avoid any oversample peaks.
Click to expand...

So, i shoulden't care moving my -dB gain in the pipeline, to be at front instead of last ?

Thank's fluid!

Jesper.
 
You must log in or register to reply here.
Top Bottom