I wonder if an approach like reverse of the Loudness filter would work. I’m not sure of the studies if any, but I suspect that our perception at loud volume is less sensitive across the frequency domain.
I’ve experienced (listening) what Kii Audio do with their Three model and it’s quite an unobtrusive handling of transient “clipping” (or backing off from distortion) experience. Usually the result is that the user lowers the volume!
There is an example for how to use the compressor to only limit at low frequencies:
https://github.com/HEnquist/camilladsp/blob/compressor/exampleconfigs/lf_compressor.yml
It splits the signal into high/low frequency parts, compresses only the low frequency part, and then combines them back together. That will behave a bit like a reverse loudness, but it only does something when actually needed.
https://github.com/HEnquist/camilladsp/blob/compressor/exampleconfigs/lf_compressor.yml
It splits the signal into high/low frequency parts, compresses only the low frequency part, and then combines them back together. That will behave a bit like a reverse loudness, but it only does something when actually needed.
Gave it a try, thank you. My speaker (pair) currently has 14 channels (I use a 16 ch DAC). There are 8 x LF drivers (4 on each speaker).
The compressor is configured:
processors:
backoff:
type: Compressor
parameters:
channels: 16
attack: 0.1
release: 1.0
threshold: -20
factor: 4.0
makeup_gain: 0
soft_clip: true
clip_limit: -6
monitor_channels: [4, 5, 6, 7, 12, 13, 14, 15]
process_channels: [4, 5, 6, 7, 12, 13, 14, 15]
When I use it, I get:
aris@audio ~ % ~/src/camilladsp/target/release/camilladsp ~/proj/config/v22/keystone-v22.yml --port=1234 --gain=-80
2022-04-12 19:22:21.064667 INFO [src/bin.rs:711] CamillaDSP version 1.0.0-alpha5
2022-04-12 19:22:21.064723 INFO [src/bin.rs:712] Running on macos, aarch64
2022-04-12 19:22:21.424219 WARN [src/coreaudiodevice.rs:370] Playback interrupted, no data available
2022-04-12 19:22:21.477508 WARN [src/coreaudiodevice.rs:718] Samples were dropped, missing 2 buffers
2022-04-12 19:22:21.501532 INFO [src/coreaudiodevice.rs:359] Restarting playback after buffer underrun
2022-04-12 19:22:21.586578 WARN [src/coreaudiodevice.rs:370] Playback interrupted, no data available
2022-04-12 19:22:21.593658 WARN [src/coreaudiodevice.rs:718] Samples were dropped, missing 4 buffers
2022-04-12 19:22:21.600337 INFO [src/coreaudiodevice.rs:359] Restarting playback after buffer underrun
2022-04-12 19:22:21.652981 WARN [src/coreaudiodevice.rs:718] Samples were dropped, missing 5 buffers
2022-04-12 19:22:21.653210 WARN [src/coreaudiodevice.rs:370] Playback interrupted, no data available
2022-04-12 19:22:21.653356 WARN [src/coreaudiodevice.rs:718] Samples were dropped, missing 5 buffers
2022-04-12 19:22:21.661725 INFO [src/coreaudiodevice.rs:359] Restarting playback after buffer underrun
2022-04-12 19:22:21.703881 WARN [src/coreaudiodevice.rs:370] Playback interrupted, no data available
...
I suspect that's its pushing available system resources. The next version of the speaker will have 24 x LF drivers spanning a stereo pair, so resource demand will only get greater!
The compressor is configured:
processors:
backoff:
type: Compressor
parameters:
channels: 16
attack: 0.1
release: 1.0
threshold: -20
factor: 4.0
makeup_gain: 0
soft_clip: true
clip_limit: -6
monitor_channels: [4, 5, 6, 7, 12, 13, 14, 15]
process_channels: [4, 5, 6, 7, 12, 13, 14, 15]
When I use it, I get:
aris@audio ~ % ~/src/camilladsp/target/release/camilladsp ~/proj/config/v22/keystone-v22.yml --port=1234 --gain=-80
2022-04-12 19:22:21.064667 INFO [src/bin.rs:711] CamillaDSP version 1.0.0-alpha5
2022-04-12 19:22:21.064723 INFO [src/bin.rs:712] Running on macos, aarch64
2022-04-12 19:22:21.424219 WARN [src/coreaudiodevice.rs:370] Playback interrupted, no data available
2022-04-12 19:22:21.477508 WARN [src/coreaudiodevice.rs:718] Samples were dropped, missing 2 buffers
2022-04-12 19:22:21.501532 INFO [src/coreaudiodevice.rs:359] Restarting playback after buffer underrun
2022-04-12 19:22:21.586578 WARN [src/coreaudiodevice.rs:370] Playback interrupted, no data available
2022-04-12 19:22:21.593658 WARN [src/coreaudiodevice.rs:718] Samples were dropped, missing 4 buffers
2022-04-12 19:22:21.600337 INFO [src/coreaudiodevice.rs:359] Restarting playback after buffer underrun
2022-04-12 19:22:21.652981 WARN [src/coreaudiodevice.rs:718] Samples were dropped, missing 5 buffers
2022-04-12 19:22:21.653210 WARN [src/coreaudiodevice.rs:370] Playback interrupted, no data available
2022-04-12 19:22:21.653356 WARN [src/coreaudiodevice.rs:718] Samples were dropped, missing 5 buffers
2022-04-12 19:22:21.661725 INFO [src/coreaudiodevice.rs:359] Restarting playback after buffer underrun
2022-04-12 19:22:21.703881 WARN [src/coreaudiodevice.rs:370] Playback interrupted, no data available
...
I suspect that's its pushing available system resources. The next version of the speaker will have 24 x LF drivers spanning a stereo pair, so resource demand will only get greater!
The compressor shouldn't be very cpu-heavy, but it's very new and hasn't gotten any thorough testing yet.
What cpu usage do you get with that config? Does it run ok if disable soft clipping? Or if you let it process only two channels?
What cpu usage do you get with that config? Does it run ok if disable soft clipping? Or if you let it process only two channels?
Ah, interesting. I tried the alpha-5 build (above, from the compressor branch) with a config that works fine/well on rc3, and the buffer overruns occur then, ie, without using the compressor filter.
Hi Henrik. I used to be able to change capture device using the GUI from File to Alsa but I now get errors when applying the change. I am using :
CamillaDSP 1.0.0-rc3
pyCamillaDSP 0.6.0
Backend 0.8.0
I guess this is because you need to update the GUI to match?
Ok, the compressor will be included in camilladsp 1.1.0, so you should be able to use it once I release 1.1.0-rc1.
Yes exactly, the released gui is meant for camilladsp 0.6.3 and there will be a new release for 1.0.0. Very soon I hope, but exactly how soon will depend on available free time.
I locally merged compressor into next11 and am running it for fun. Seems fine, I'll crank it up a bit tomorrow when the family is out of the house.
I’m working on a Roon extension to control CamillaDSP’s volume.
It would be nice if CamillaDSP supported a discovery mechanism such as libp2p - would enable autoconf of the client app quite nicely.
Would also enable Camilla GUI to elegantly control multiple backends.
It would be nice if CamillaDSP supported a discovery mechanism such as libp2p - would enable autoconf of the client app quite nicely.
Would also enable Camilla GUI to elegantly control multiple backends.
It should be easy to add some kind of service announcement, with this crate for example: https://crates.io/crates/libmdns
I'll try it.
I'm curious about the compressor, did you have a chance to play with it properly yet?
Anyone doing RIAA correction via a biquad (free) in CamillaDSP? I'm looking for the appropriate coefficients for 192khz sampling frequency.
Thanks,
Jim,
Thanks,
Jim,
Cool, look forward to hearing how it goes.
Have been using it, demoing the loudspeaker I’m making over a few sessions playing loud and so far so good. Haven’t dug under the hood yet.
I've put together a basic Roon Extension for CamillaDSP. It's working reasonably well for me, so hopefully others may find it of interest and use.
https://github.com/siraaris/roon-extension-cdsp
It provides the ability to control CamillaDSP's volume/mute natively within Roon desktop and mobile apps (that are the basis of most of my listening these days). Just to be clear, this preserves CamillaDSP as the volume/mute mechanism. The extension merely provides the convenience of control from within Roon.
https://github.com/siraaris/roon-extension-cdsp
It provides the ability to control CamillaDSP's volume/mute natively within Roon desktop and mobile apps (that are the basis of most of my listening these days). Just to be clear, this preserves CamillaDSP as the volume/mute mechanism. The extension merely provides the convenience of control from within Roon.
Hello guys, I currently use Uli's AcourateConvolver on windows, I'm testing this fabulous software on a raspi 3b. I need to do this mapping and I can't get it.
My system is a 2.1, generated with acourate, the XO and DRC filters are included in the same convolution.
Hope someone can guide me. Thanks in advance.
My system is a 2.1, generated with acourate, the XO and DRC filters are included in the same convolution.
Hope someone can guide me. Thanks in advance.
Why are the 2 upper destinations split in to two parts?
My intention was to do a basic 2 ch -> 4 ch split (2way active, stereo) USB in, 2 sp/pdif cables out.
I have a RME with 4 split outputs - maybe I shall only use dest 0 and dest 1 and assign ch 0-3 to these 2?
Pipe look ok...
//
My intention was to do a basic 2 ch -> 4 ch split (2way active, stereo) USB in, 2 sp/pdif cables out.
I have a RME with 4 split outputs - maybe I shall only use dest 0 and dest 1 and assign ch 0-3 to these 2?
Pipe look ok...
//
Attachments
Last edited:
I wish the concept of "Dest" under Mixer was used in the Pipeline display... it would sort out things a bit 🙂 (for me)
To make these quite complicated structures comprehensible, one need to use one set of well defined concepts throughout the whole system.
//
To make these quite complicated structures comprehensible, one need to use one set of well defined concepts throughout the whole system.
//
Hi TNT, thanks for your help, in my case this option is not valid I need to send the two input/capture channels L and R convolve, and then send the output of both to the same channel 3.
I attach an image of how it is configured in AcourateConvolver. I need to make this same connection.
I attach an image of how it is configured in AcourateConvolver. I need to make this same connection.