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

Hmm that should work, I'll check!
I can't reproduce this on "rawfiles" or "develop". Can you try download again and rebuild?
Just do

Code:
git checkout rawfiles
git pull
After that check that you have the latest version:
Code:
> git log
commit 4b90f9325feff4169690f3f0387d4e22cdeb2337 (HEAD -> rawfiles, origin/rawfiles)
Author: Henrik Enquist <##########>
Date:   Mon Mar 16 21:31:45 2020 +0100

    Add biquad readme
(plus more lines below with older stuff..)
 
Understood.

Still the sound with Repahse generated filter (opposed to your IIR filters) is not the way it should.
What filter in Rephase should work best in Camilladsp ?
Brutefir takes the .bin files and sounds good.

View attachment 825540
The latest "rawfiles" should work with .bin, .dbl and .txt. Just set the format to FLOAT32, FLOAT64 or TEXT.
Could you attach the filter you tried?
 
The latest "rawfiles" should work with .bin, .dbl and .txt. Just set the format to FLOAT32, FLOAT64 or TEXT.
Could you attach the filter you tried?

Works. FLOATt32LE, BIN files.

If I want to pad down tweeterlevel, where in the configfile do you put the gainsetting like below?
Do you put it straight under the highpass section?

highpass_fir:
type: Conv
parameters:
type: File
filename: /home/pi/highpass.bin
format: FLOAT32LE
(here??)

filters:
gainexample:
type: Gain
parameters:
gain: -3.0
inverted: false
 
Works. FLOATt32LE, BIN files.

If I want to pad down tweeterlevel, where in the configfile do you put the gainsetting like below?
Do you put it straight under the highpass section?

highpass_fir:
type: Conv
parameters:
type: File
filename: /home/pi/highpass.bin
format: FLOAT32LE
(here??)

filters:
gainexample:
type: Gain
parameters:
gain: -3.0
inverted: false
You define it as a separate filter:
Code:
filters:
  tweetergain:
    type: Gain
    parameters:
      gain: -7.3
The you add it in the pipeline (before or after the fir filter doesn't matter):
Code:
pipeline:
  - type: Mixer
    name: mono
  - type: Filter
    channel: 1
    names:
      - highpass_fir
      - tweetergain
 
You define it as a separate filter:
Code:
filters:
  tweetergain:
    type: Gain
    parameters:
      gain: -7.3
The you add it in the pipeline (before or after the fir filter doesn't matter):
Code:
pipeline:
  - type: Mixer
    name: mono
  - type: Filter
    channel: 1
    names:
      - highpass_fir
      - tweetergain

Ofcourse, logical.
Define it first, then "attach'' it in the pipeline to the desired channel.
 
"rawfiles" has been updated. There were a few bugs in reading coefficients in float64 and int16 formats.
I also added an option to specify delay in samples.

When i'll be back from job today, i'am gonna build the new RAW with git checkout / git pull, also enabling the 32bit
cargo build --release --features 32bit

I feel i have control over the most basic alsa stuff now, so getting it to work now should be easier for me ;)

Next move is then to create some real filters for room correction.
I will make measurements in REW with my UMIK-1 and load it into RePhase and try to make some adjustments.
I will make two mono files (L+R) at each samplerate i need...

Jesper.
 
Hello... So i finally made it home today :eek:

I build the new rawfiles with 32bit.
Everything seems to work now !

I will report back when i have testes/tried it for a while about glitches, but so far it's looking good regarding this too :xfingers:

pi@SuperBPI:~/camilla_raw/camilladsp $ git log
commit 67f5cbeb6b107342ce175accbf329aa5ce3cfd49 (HEAD -> rawfiles, origin/rawfiles)
Author: Henrik Enquist <henrik.enquist@maxiv.lu.se>
Date: Tue Mar 17 12:18:36 2020 +0100

Jesper...
 

Attachments

  • New_1.png
    New_1.png
    61.3 KB · Views: 246
  • new_2.png
    new_2.png
    286.1 KB · Views: 228
Hi...

So i found this link http://forums.melaudia.net/attachment.php?aid=22240

And took some measurements at my shop/office, and followed the guide (well i think i screewed small parts of it up, but it's my first time:p)

I loaded the filter in the camilladsp config :
---
devices:
samplerate: 44100
buffersize: 1024
target_level: 512
adjust_period: 10

capture:
type: Alsa
channels: 2
device: "camilla_in"
format: S16LE
playback:
type: Alsa
channels: 2
device: "sound_out"
format: S16LE

filters:
test_fir_L:
type: Conv
parameters:
type: File
filename: /home/pi/camilla_raw/camilladsp/target/release/Left.bin
format: FLOAT32LE

test_fir_R:
type: Conv
parameters:
type: File
filename: /home/pi/camilla_raw/camilladsp/target/release/Right.bin
format: FLOAT32LE

pipeline:
- type: Filter
channel: 0
names:
- test_fir_L
- type: Filter
channel: 1
names:
- test_fir_R

Really worked 1. shoot :)
I really have to adjust the rate settings, as i still have some glitches (could be the crappy dac through)

[2020-03-18T12:39:33Z WARN camilladsp::conversions] Clipping detected, 14 samples clipped, peak 104.11042%
[2020-03-18T12:39:34Z WARN camilladsp::conversions] Clipping detected, 2 samples clipped, peak 100.31446%
[2020-03-18T12:39:34Z DEBUG camilladsp::alsadevice] Current buffer level 697, set capture rate to 100.02098%
[2020-03-18T12:39:34Z DEBUG camilladsp] SetSpeed message reveiced
[2020-03-18T12:39:36Z WARN camilladsp::conversions] Clipping detected, 1 samples clipped, peak 100.34209%
[2020-03-18T12:39:36Z WARN camilladsp::conversions] Clipping detected, 3 samples clipped, peak 104.145256%
[2020-03-18T12:39:38Z WARN camilladsp::conversions] Clipping detected, 1 samples clipped, peak 100.73582%
[2020-03-18T12:39:39Z WARN camilladsp::conversions] Clipping detected, 7 samples clipped, peak 104.35543%
[2020-03-18T12:39:40Z WARN camilladsp::conversions] Clipping detected, 2 samples clipped, peak 101.6496%
[2020-03-18T12:39:41Z WARN camilladsp::conversions] Clipping detected, 1 samples clipped, peak 101.32773%
[2020-03-18T12:39:44Z DEBUG camilladsp::alsadevice] Current buffer level 629, set capture rate to 100.01327%
[2020-03-18T12:39:44Z DEBUG camilladsp] SetSpeed message reveiced

I have attached the filters in .bin / .txt & .wav (I missed some "real" files along my way to test, therefore i attach them here for othe newbies to look at)

Jesper.

Btw: PI is loaded ~11% on CPU when build with 32bit, looking good:
1662 pi 20 0 24444 7128 5080 S 10.6 0.2 1:50.40 camilladsp
1657 pi 20 0 140172 130428 86320 S 0.7 3.3 0:05.93 squeezelite
 

Attachments

  • REW_1.png
    REW_1.png
    119.2 KB · Views: 228
  • RePhase_1.png
    RePhase_1.png
    82.1 KB · Views: 230
  • Zipped.zip
    347.6 KB · Views: 52
I really have to adjust the rate settings, as i still have some glitches (could be the crappy dac through)

The glitches/xruns can happen at any device.You are checking the output soundcard buffer, but are all remaining buffers large enough (playback software -> loopback playback, loopback capture -> camilladsp)?

One thing is having the clocks synchronized (you already have that), another thing is getting the data soon enough (buffer sizes).
 
The glitches/xruns can happen at any device.You are checking the output soundcard buffer, but are all remaining buffers large enough (playback software -> loopback playback, loopback capture -> camilladsp)?

One thing is having the clocks synchronized (you already have that), another thing is getting the data soon enough (buffer sizes).

Ofcause your'e right. I can adjust the buffer on the squeezelite, but i think it's good allready as there are no glitches when playing without camilladsp for sure.
So i think playback software (LMS) are good also, so it must be either the loopback or the camilla.

I donno yet howto adjust loopback, so back to reading, thanks phofman ;)

.asoundrc :
# Loopback device 0
pcm.squeeze {
type hw
card "Loopback"
device 0
format S16_LE
channels 2
}

# Loopback device 1
pcm.camilla_in {
type hw
card "Loopback"
device 1
format S16_LE
channels 2
}

pcm.sound_out {
type hw
card 1
device 0
}

ctl.sound_out {
type hw
card 1
}
 
Buffer and period sizes for opened devices are listed in their /proc/asound/card*/pcm*/sub*/hw_params files. I would suggest to check them to see if there are reasonable values (period time at least 10ms, possibly more if latency is no issue). The more, the better.

THIS must be my loopback device 0 (squeeze) - sends stream to squeezelite player
pi@SuperBPI:/proc/asound/card0/pcm0p/sub0 $ cat hw_params
access: MMAP_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 1764
buffer_size: 7056

pi@SuperBPI:/proc/asound/card0/pcm0p/sub0 $ cat sw_params
tstamp_mode: NONE
period_step: 1
avail_min: 1764
start_threshold: 1
stop_threshold: 7056
silence_threshold: 0
silence_size: 0
boundary: 1849688064

THIS must be my loopback device 1 (camilla_in) - Which captures the stream from squeezelite
pi@SuperBPI:/proc/asound/card0/pcm1c/sub0 $ cat hw_params
access: RW_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 128
buffer_size: 2048

pi@SuperBPI:/proc/asound/card0/pcm1c/sub0 $ cat sw_params
tstamp_mode: NONE
period_step: 1
avail_min: 128
start_threshold: 896
stop_threshold: 2048
silence_threshold: 0
silence_size: 0
boundary: 1073741824

Do i set these parameters 'period time etc...' in .asoundrc or do i have to go deeper :)

Jesper.
 
period_size: 128 at 44.1kHz is 2.9ms IRQ period. Why so low?...

The playback side of loopback at 40ms is probably OK.

What are the soundcard buffer/period?

You can either configure your PCM device with custom period/buffer sizes and tell the alsa client to use it, or most alsa clients offer this as configuration. Henrik will know right away...
 
phofman...

Looks the same as one of the loopback devices

What are the soundcard buffer/period?

pi@SuperBPI:/proc/asound/card1/pcm0p/sub0 $ cat hw_params
access: RW_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 128
buffer_size: 2048
pi@SuperBPI:/proc/asound/card1/pcm0p/sub0 $ cat sw_params
tstamp_mode: NONE
period_step: 1
avail_min: 128
start_threshold: 896
stop_threshold: 2048
silence_threshold: 0
silence_size: 0
boundary: 1073741824