@HenrikEnquist, it would be nice if the active_config.yml wasn't visible from the files section, right?
If you leave camillagui.yml as-is it will do exactly that.
I always wondered why default_config and active_config did not point to ~/camilladsp/configs in camillagui.yml but that explains it.
There is also no need to create default_config or symlink it to active_config. Just select a configuration that you have stored in ~/camilladsp/configs as active in the GUI and it will use that going forward.
Michael
But how well is it working now!!! It is a pleasure to change settings so easily.
Now only the cosmetic point is missing, to see the VUMETER with the smoothness of movement of the previous version.
Thanks again @HenrikEnquist for your time and for sharing this wonderful piece of software.
Now only the cosmetic point is missing, to see the VUMETER with the smoothness of movement of the previous version.
Thanks again @HenrikEnquist for your time and for sharing this wonderful piece of software.
What is the side chain input of the limiter used for? An estimation of woofer excursion or something like that?
Yes, I thank that's exactly what it is. I'm trying to replicated JBL's DSP for their 708i speakers.
https://www.avsforum.com/threads/jb...ofers-jan-2015.1724906/page-139#post-57945990
-Jim
@HenrikEnquist,
I would like to playback a soundtrack file by a soundcard and to record the soundcard output by a loopback cable (or a DUT = device under test) at the soundcard inputs into another file. Is this possible?
IMO in such a case this would need two playback devices of type file + alsa and two capture devices of type alsa and file.
If it is possible then how would a proper config look like?
I would like to playback a soundtrack file by a soundcard and to record the soundcard output by a loopback cable (or a DUT = device under test) at the soundcard inputs into another file. Is this possible?
IMO in such a case this would need two playback devices of type file + alsa and two capture devices of type alsa and file.
If it is possible then how would a proper config look like?
Is this what you want?
file -> dsp? -> soundcard -> analog loopback -> soundcard -> dsp? -> file
Camilladsp can only use one capture device (and one playback device). But there is nothing preventing running two instances, one for the playback side and one for the capture side. That should work to build the chain above.
If you set both playback and capture to file, it won't run realtime! Instead it will run as fast as possible.You can set the output device to a file ;-)
I think you can actually set the input also to a file, making Camilla a file to file conversion tool.... with some extraordinary processing capability...
Only downside is that it will be done in real time
//
Greetings HenrikEnquist! I installed MPD 0.22.4 on debian 11 64bit (Linux Camilladsp 5.10.0-14-amd64 #1 SMP Debian 5.10.113-1 (2022-04-29) x86_64 GNU/Linux) and it works very well. I have Intel dual-core Intel® Atom D525MW 1.80GHz, Main Memory 2GB, Xonar D1 sound card. Next, I installed the fresh release 1.0.0 CamillaDSP and configured.
Everything works great!
Thank you for providing a great program!
But a problem emerged. When audio is output from MPD (output 0dB) via "" device "hw:Loopback,1" "" the CamillaDSP input signal is overloaded to about 2.0 dB (this can be seen from the reddened Volume and Out and log, for example, one of many (2022 -05-15 18:52:25.647046 WARN [src/conversions.rs:65] Clipping detected, 12 samples clipped, peak +1.96 dB (125.4%)). Having carried out the experiments, it turns out that the 0 dB hw:Loopback,0 digital input is more sensitive than the digital output by about 2 dB, and an overload occurs at the input hw:Loopback,1 Camilladsp.
Playing white noise generated in Adobe Audition at 0dB, 16bit, 96000Hz
If at the same time I make the volume -3 dB in the CamillaDSP, there is no overload.
I don't understand where the problem could be?
Best regards!
Gennadiy
Everything works great!
Thank you for providing a great program!
But a problem emerged. When audio is output from MPD (output 0dB) via "" device "hw:Loopback,1" "" the CamillaDSP input signal is overloaded to about 2.0 dB (this can be seen from the reddened Volume and Out and log, for example, one of many (2022 -05-15 18:52:25.647046 WARN [src/conversions.rs:65] Clipping detected, 12 samples clipped, peak +1.96 dB (125.4%)). Having carried out the experiments, it turns out that the 0 dB hw:Loopback,0 digital input is more sensitive than the digital output by about 2 dB, and an overload occurs at the input hw:Loopback,1 Camilladsp.
Playing white noise generated in Adobe Audition at 0dB, 16bit, 96000Hz
If at the same time I make the volume -3 dB in the CamillaDSP, there is no overload.
I don't understand where the problem could be?
Best regards!
Gennadiy
Last edited:
Thanks for the feedback!
The clipping you see is actually completely normal, but quite counter intuitive! When you apply filtering, the peak amplitude of the signal can go up, even if all your filters have only zero or negative gain. It's mentioned here in the faq: https://github.com/HEnquist/camilladsp/blob/master/FAQ.md#filtering
A short version is that filtering with only negative or zero gain filters will decrease the average power in the signal. But the filtering also shuffles the various frequency components of the signal around, which makes them sum up in a new way. This tends to produce some new peaks up to a few dB above the original signal.
The clipping you see is actually completely normal, but quite counter intuitive! When you apply filtering, the peak amplitude of the signal can go up, even if all your filters have only zero or negative gain. It's mentioned here in the faq: https://github.com/HEnquist/camilladsp/blob/master/FAQ.md#filtering
A short version is that filtering with only negative or zero gain filters will decrease the average power in the signal. But the filtering also shuffles the various frequency components of the signal around, which makes them sum up in a new way. This tends to produce some new peaks up to a few dB above the original signal.