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

Jump to Latest
HenrikEnquist

HenrikEnquist

Member
Joined 2016
phofman said:
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...
Click to expand...
I played around with period size some time ago, at the end I left it at buffersize/8. And it requests a buffer of size 2*buffersize from Alsa. The period size didn't seem to make much difference on my laptop but I haven't tested it on other hardware like a pi. It's easy to change in the source code if someone wants to experiment, look in alsadevice.rs. I should probably revisit this!
 
HenrikEnquist

HenrikEnquist

Member
Joined 2016
lykkedk said:
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 :


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



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:
Click to expand...
Your filters are 16k long right? You can go up in buffersize then, try 4096 or 8192 for example.
You also have some clipping, you might want to add a gain filter at -1 or -2 dB to get rid of that.

Is everyone running 32-bit kernels on their pi:s? The later ones can do 64 also but I don't know if there is a good 64-bit distribution to run.
 
lykkedk

lykkedk

Member
Joined 2002
HenrikEnquist said:
Your filters are 16k long right? You can go up in buffersize then, try 4096 or 8192 for example.
You also have some clipping, you might want to add a gain filter at -1 or -2 dB to get rid of that.

Is everyone running 32-bit kernels on their pi:s? The later ones can do 64 also but I don't know if there is a good 64-bit distribution to run.
Click to expand...

Hi hello there :)

I did the filters in 16bit, because i don't think this "TEST" Dac can handle more, so until i decide to drag my superdac upstairs i will test with 16bit :eek:

Well i still don't know howto change/adjust the buffersize, haven't figured that out yet.

Regarding the RPI running 64bit; no distributions are there yet, except for some test ones i guess.
 
HenrikEnquist

HenrikEnquist

Member
Joined 2016
lykkedk said:
Hi hello there :)

I did the filters in 16bit, because i don't think this "TEST" Dac can handle more, so until i decide to drag my superdac upstairs i will test with 16bit :eek:

Well i still don't know howto change/adjust the buffersize, haven't figured that out yet.

Regarding the RPI running 64bit; no distributions are there yet, except for some test ones i guess.
Click to expand...
I mean the "buffersize" setting in the "devices" section of the camilla config.


Some day quite soon I will rename that to "chunksize" to better reflect what it is. Unfortunately that will break all old config files. They are super easy to fix, but still...
 
lykkedk

lykkedk

Member
Joined 2002
HenrikEnquist said:
I mean the "buffersize" setting in the "devices" section of the camilla config.


Some day quite soon I will rename that to "chunksize" to better reflect what it is. Unfortunately that will break all old config files. They are super easy to fix, but still...
Click to expand...

Thank's, i was mixing this up with the ALSA buffer's :rolleyes:

I try a buffer on 16384 right now...
Will report back tomorrow if things are better!

Jesper.
 
lykkedk

lykkedk

Member
Joined 2002
Morning here :eek:

I did some test with the camilladsp "buffersize"/"chunksize", and setting it to 8192 with 44.1Khz@16bit did help, but still some minor glitches did occour.

I then applied a -2dB gain (L+R)
With this applied the music now streams without hickup's and glitches ;)
It look's to me as camilladsp did create a minor glitch/strange crackle when clipping did occour.

I think it's good now... very good Henrik! :up:

---
devices:
samplerate: 44100
buffersize: 8192
target_level: 512
adjust_period: 5

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

clipgain_L:
type: Gain
parameters:
gain: -2.0
inverted: false

clipgain_R:
type: Gain
parameters:
gain: -2.0
inverted: false


pipeline:
- type: Filter
channel: 0
names:
- test_fir_L
- type: Filter
channel: 1
names:
- test_fir_R
- type: Filter
channel: 0
names:
- clipgain_L
- type: Filter
channel: 1
names:
- clipgain_R
Click to expand...

.asoundrc
# Loopback device 0
# hw:0,0 name "squeeze" send stream output (from squeezelite -o squeeze) to loopback device 0
pcm.squeeze {
type hw
card "Loopback"
device 0
format S16_LE
channels 2
}

# Loopback device 1
# hw:0,1 name "camilla_in" captures the stream from "squeeze" (loopback device 0)
# Camilladsp then do her things to the stream
pcm.camilla_in {
type hw
card "Loopback"
device 1
format S16_LE
channels 2
}

# "sound_out" is the "real" hardware card (usbdac, soundcard etc...)
pcm.sound_out {
type hw
card 1
device 0
}

ctl.sound_out {
type hw
card 1
}
Click to expand...

Jesper.
 
HenrikEnquist

HenrikEnquist

Member
Joined 2016
lykkedk said:
Morning here :eek:

I did some test with the camilladsp "buffersize"/"chunksize", and setting it to 8192 with 44.1Khz@16bit did help, but still some minor glitches did occour.

I then applied a -2dB gain (L+R)
With this applied the music now streams without hickup's and glitches ;)
It look's to me as camilladsp did create a minor glitch/strange crackle when clipping did occour.

I think it's good now... very good Henrik! :up:



.asoundrc


Jesper.
Click to expand...
Good!Yes clipping will probably be audible. There is no soft clipping or such, just a hard limit.

Buffer underruns give the "prepare playback" message if you run with the -v flag. If you don't see any of those (or the corresponding "prepare capture" for the capture device) then you don't have any buffer underruns.
 
lykkedk

lykkedk

Member
Joined 2002
HenrikEnquist said:
Good!Yes clipping will probably be audible. There is no soft clipping or such, just a hard limit.

Buffer underruns give the "prepare playback" message if you run with the -v flag. If you don't see any of those (or the corresponding "prepare capture" for the capture device) then you don't have any buffer underruns.
Click to expand...

Yes, very good...

I have an "warn" every ~2-6min. sometimes i can hear a "click" when this occour.
Is it possible to adjust this buffer or do i have to go deep and change some source?

2020-03-19T10:27:24Z WARN camilladsp::alsadevice] Prepare playback
Click to expand...

Jesper.
 
Last edited:
Daihedz

Daihedz

Member
Joined 2010
b_force said:
Really nice effort!
I think it would be very helpful to make some kind of GUI, for easier programming of the filters.
Also, it might be nice to get in touch with this guy; Pulseaudio Crossover Rack - multi-way crossover design & implementation with linux

I think together you can make something that would work very well on a lot of systems!!
Click to expand...

Indeed, this is a very valuable contribution for linux audio, and it's getting better from day to day - what an exciting experience! Already as is, camilladsp gives much to many and starts rivalling brutefir. I expect me to completely switch from brutefir to camilladsp in the near future, if things continue to develop like they did until now. And I have a feeling that the odds are good that this will be the case.

But I am thinking the other way round than you do: I just like things simple, lean, precise and clean, even if it comes at the price of a little bit more effort you have to provide. I like to handle my audio using barebone-alsa pipes. So I like camilladsp because it interfaces with alsa. Pulseaudio and/or Jack are completely banned from my audio systems.


And personally, I don't see a need for a dedicated GUI interface for the configuration of camilladsp, as the configuration itself is very straightforward and easy to understand. I think most people a little bit familiar with linux audio will be able to handle this one as well and as is.
 
HenrikEnquist

HenrikEnquist

Member
Joined 2016
b_force said:
Really nice effort!
I think it would be very helpful to make some kind of GUI, for easier programming of the filters.
Also, it might be nice to get in touch with this guy; Pulseaudio Crossover Rack - multi-way crossover design & implementation with linux

I think together you can make something that would work very well on a lot of systems!!
Click to expand...
We are already in contact! Check a few pages back in this thread. Based on his input I already implemented the config reloading on SIGHUP, and I'm also working on a websocket server so you can pass more commands to the running process.
 
HenrikEnquist

HenrikEnquist

Member
Joined 2016
Daihedz said:
Indeed, this is a very valuable contribution for linux audio, and it's getting better from day to day - what an exciting experience! Already as is, camilladsp gives much to many and starts rivalling brutefir. I expect me to completely switch from brutefir to camilladsp in the near future, if things continue to develop like they did until now. And I have a feeling that the odds are good that this will be the case.

But I am thinking the other way round than you do: I just like things simple, lean, precise and clean, even if it comes at the price of a little bit more effort you have to provide. I like to handle my audio using barebone-alsa pipes. So I like camilladsp because it interfaces with alsa. Pulseaudio and/or Jack are completely banned from my audio systems.


And personally, I don't see a need for a dedicated GUI interface for the configuration of camilladsp, as the configuration itself is very straightforward and easy to understand. I think most people a little bit familiar with linux audio will be able to handle this one as well and as is.
Click to expand...
I have no intention of slowing down!
I also don't need any gui for myself, but I certainly see the use case for one. I think that CamillaDSP should be lean, but still provide a method to change settings etc on the fly, so a gui or other supervising process or whatever can talk to it. I think the websocket server I'm working on is a nice compromise. I have even put it as a compile option so the whole thing can be left out it it's not needed.
 
HenrikEnquist

HenrikEnquist

Member
Joined 2016
cube75 said:
Henrik,
There is always debate on forums about realtime priority, realtimekernel for softwareplayers etc. But what do you think of it? Should it benefit Camilladsp?
Or does Camilladsp run optimal on a standard Raspbian for example, and we can forget about this..
Click to expand...
I have tried to make the internal buffering robust against scheduling issues. But I only have experience from running it on modern PC hardware, and there I would say realtime stuff isn't needed. It runs just fine while playing movies from Netflix in Firefox for example, which is quite heavy since uses with software video decoding. In the same conditions I had lots of dropouts with BruteFIR. On a Pi I have no idea, would be great if someone wants to test a bit :)
 
You must log in or register to reply here.
Top Bottom