No mute/ Loudness in Webinterface with latest Release
Hi Henrik,
- Add `Loudness` volume control filter.
- Add mute options in mixer and Gain filters.
- Add mute function to Volume and Loudness filters, with websocket commands.
is not working for me. I miss the options in the Webinterface.
Additional Infos:
Installed Releases:
CamillaDSP: 0.5.0
pyCamillaDSP: 0.5.0
Backend: 0.6.0
-Rust updated today
-GIT Checkout Branch Master (Release) today
Linux Distribution RASPBIAN
Uname: Linux raspberrypi 5.10.17-v8+ #1403 SMP PREEMPT Mon Feb 22 11:37:54 GMT 2021 aarch64 GNU/Linux
Could you please guide me in the correct direction to troubleshoot?
Thanks a lot.
Hi Henrik,
- Add `Loudness` volume control filter.
- Add mute options in mixer and Gain filters.
- Add mute function to Volume and Loudness filters, with websocket commands.
is not working for me. I miss the options in the Webinterface.
Additional Infos:
Installed Releases:
CamillaDSP: 0.5.0
pyCamillaDSP: 0.5.0
Backend: 0.6.0
-Rust updated today
-GIT Checkout Branch Master (Release) today
Linux Distribution RASPBIAN
Uname: Linux raspberrypi 5.10.17-v8+ #1403 SMP PREEMPT Mon Feb 22 11:37:54 GMT 2021 aarch64 GNU/Linux
Could you please guide me in the correct direction to troubleshoot?
Thanks a lot.
Last edited:
Missing Options in Webinterface
Addition to my previous post,
manually putting
loudnessvol:
type: Loudness
parameters:
ramp_time: 200.0
reference_level: -25.0
high_boost: 7.0
low_boost: 7.0
into my config.yml, results in a new (wrong ?) filter in webinterface (attached)
Addition to my previous post,
manually putting
loudnessvol:
type: Loudness
parameters:
ramp_time: 200.0
reference_level: -25.0
high_boost: 7.0
low_boost: 7.0
into my config.yml, results in a new (wrong ?) filter in webinterface (attached)
Attachments
Last edited:
I made some tests on my RPi4 to see how much filtering it can actually handle.
This was done on a normal RPi4, running the 64-bit Raspbian.
I tested at 192 kHz, with 2 channels in and 8 channels out (capture and playback devices were Alsa loopbacks).
Each output channel was filtered with a FIR filter. I also tried with and without resampling, and with different chunksizes.
Note that the CPU usage numbers are percent of a single core, so an application that fully uses all four cores of the Pi4 will be reported as using 400%.
The heaviest combination I tested that worked was this:
- 8 channels
- chunksize: 16384
- FIR with 262144 taps per channel
- AccurateAsync resampling
- 156% CPU usage
(the resampler and the convolution runs on different cores, so >100% is possible)
The AccurateAsync resampler is very heavy, and the Balanced one is more reasonable. That gives this instead:
- 8 channels
- chunksize: 16384
- FIR with 262144 taps per channel
- BalancedAsync resampling
- 82% CPU usage
Skipping the resampler, and instead playing with chunksize, we get this (still at 192kHz):
- 8 channels
- FIR with 262144 taps per channel
- no resampling
- chunksize: 4096 -> not possible
- chunksize: 8192 -> - 71% CPU usage
- chunksize: 16384 -> 58% CPU usage
- chunksize: 32768 -> 55% CPU usage
So basically, the RPi4 can handle a lot!
Switching to some x86_64 cpu, where RustFFT supports SSE and AVX, things get even better. Any recent Atom cpu should do perhaps 2x better, and an Intel Core or Amd Ryzen cpu probably around 4x.
But I think already the RPi can handle much more than most people will ever need.
I did not test this on a 32-bit Pi OS yet. I expect that to perform quite a bit worse. I'll try when I have some time.
This was done on a normal RPi4, running the 64-bit Raspbian.
I tested at 192 kHz, with 2 channels in and 8 channels out (capture and playback devices were Alsa loopbacks).
Each output channel was filtered with a FIR filter. I also tried with and without resampling, and with different chunksizes.
Note that the CPU usage numbers are percent of a single core, so an application that fully uses all four cores of the Pi4 will be reported as using 400%.
The heaviest combination I tested that worked was this:
- 8 channels
- chunksize: 16384
- FIR with 262144 taps per channel
- AccurateAsync resampling
- 156% CPU usage
(the resampler and the convolution runs on different cores, so >100% is possible)
The AccurateAsync resampler is very heavy, and the Balanced one is more reasonable. That gives this instead:
- 8 channels
- chunksize: 16384
- FIR with 262144 taps per channel
- BalancedAsync resampling
- 82% CPU usage
Skipping the resampler, and instead playing with chunksize, we get this (still at 192kHz):
- 8 channels
- FIR with 262144 taps per channel
- no resampling
- chunksize: 4096 -> not possible
- chunksize: 8192 -> - 71% CPU usage
- chunksize: 16384 -> 58% CPU usage
- chunksize: 32768 -> 55% CPU usage
So basically, the RPi4 can handle a lot!
Switching to some x86_64 cpu, where RustFFT supports SSE and AVX, things get even better. Any recent Atom cpu should do perhaps 2x better, and an Intel Core or Amd Ryzen cpu probably around 4x.
But I think already the RPi can handle much more than most people will ever need.
I did not test this on a 32-bit Pi OS yet. I expect that to perform quite a bit worse. I'll try when I have some time.
Hi,
I have some noob questions, hope it is ok here?
I have made a headphone EQ filter using CamillaDSP for my moOde Player.
It was based on another one from Gtihub, which is where I got the CamillaDSP settings from. I just changed the filters for my headphone. See the YML's below.
It seems to work very well, as I can hear the expected difference to the sound.
I seems to work with audiofiles of all samplerates, but I do not understand why....
I would like to have a better understanding, what is happening, eg. which setting to set and which ones to skip.
Questions:
1) Do I need to set the "samplerate:"?
Could it just be set automatically to the same as the audiofile samplerate?
Is the "samplerate:", the samplerate that CamillaDSP operates on?
So if the audiofile is 44100hz, it is upsampled to 96khz, the filter is applied, then downsampled to 44100hz again?
The typical files I listen to go from 44100 to 192000hz, but mostly just 44100 and 48000.
What would be the optimal "samplerate:" be in that case?
It is running on an Raspberry Pi 3B (1GB RAM), but will use an rpi 4, if that is better...
2) Do I need to set the "silence_*" parameters?
Best regards
Jens
My YML-file (available here: akg_k702_camilladsp_eq/headphone_AKG_K702_EQ_CamillaDSP.yml at main * jensgk/akg_k702_camilladsp_eq * GitHub ) was based on this: CamillaDSP Config example for Beyerdynamics DT 770 Pro * GitHub
I starts like this:
devices:
samplerate: 96000
chunksize: 16384
silence_threshold: -60
silence_timeout: 3.0
capture:
type: Alsa
channels: 2
device: "hw:Loopback,1"
format: S24LE3
playback:
type: Alsa
channels: 2
device: "hw:v15,0"
format: S24LE3
filters:
...some filters all of this type:
AKGK702_crinacle_24042021_band01:
type: Biquad
parameters:
type: Peaking
freq: 27
gain: 6.3
q: 0.27
....
I have some noob questions, hope it is ok here?
I have made a headphone EQ filter using CamillaDSP for my moOde Player.
It was based on another one from Gtihub, which is where I got the CamillaDSP settings from. I just changed the filters for my headphone. See the YML's below.
It seems to work very well, as I can hear the expected difference to the sound.
I seems to work with audiofiles of all samplerates, but I do not understand why....
I would like to have a better understanding, what is happening, eg. which setting to set and which ones to skip.
Questions:
1) Do I need to set the "samplerate:"?
Could it just be set automatically to the same as the audiofile samplerate?
Is the "samplerate:", the samplerate that CamillaDSP operates on?
So if the audiofile is 44100hz, it is upsampled to 96khz, the filter is applied, then downsampled to 44100hz again?
The typical files I listen to go from 44100 to 192000hz, but mostly just 44100 and 48000.
What would be the optimal "samplerate:" be in that case?
It is running on an Raspberry Pi 3B (1GB RAM), but will use an rpi 4, if that is better...
2) Do I need to set the "silence_*" parameters?
Best regards
Jens
My YML-file (available here: akg_k702_camilladsp_eq/headphone_AKG_K702_EQ_CamillaDSP.yml at main * jensgk/akg_k702_camilladsp_eq * GitHub ) was based on this: CamillaDSP Config example for Beyerdynamics DT 770 Pro * GitHub
I starts like this:
devices:
samplerate: 96000
chunksize: 16384
silence_threshold: -60
silence_timeout: 3.0
capture:
type: Alsa
channels: 2
device: "hw:Loopback,1"
format: S24LE3
playback:
type: Alsa
channels: 2
device: "hw:v15,0"
format: S24LE3
filters:
...some filters all of this type:
AKGK702_crinacle_24042021_band01:
type: Biquad
parameters:
type: Peaking
freq: 27
gain: 6.3
q: 0.27
....
I'm not sure if it will perform significantly worse unless literally every calculation is doubled due to the 32-bit limit. However, this is exactly why I made my setup on pages 188-now. There's an amazing amount of potential (with only a few watts) doing everything purely in the digital domain that the current DSP devices from AD etc. can't compete with.
Edit: "top" reports single core usage, so numbers above 100% are possible on multicore systems. For the rpi4, there are 4 cores, so you're not maxed out until 400% (slightly less, realistically) assuming processes can thread entirely.
On that note, what's the threading capability of CamillaDSP? What filter processes can benefit and what can't? Ultimately the whole thing is real-time limited by sample captures, so there's a point where it has to bog.
Last edited:
From what others have measured, I would expect all the filters to run something like 20% slower. But the asynchronous resampler will be worse off, since it can't use NEON on 32-bit.
The process is essentially split in three threads. One for capturing (and resampling if enabled), one for all filters, and one for playback. I have considered adding more threads for the filtering but haven't come up with a good design for it yet.
Looking at the numbers I posted, in the one with AccurateAsync resampling, the resampler runs at close to 100% of one core. Then the filtering takes about 50% of another core. That makes up for almost all of the 156%.
It looks like you are using a loopback to get the audio into camilladsp. Can you post your alsa config file?
The loopback won't change samplerate automatically. If you have a "plug" in the alsa config, that will resample to 96 kHz for you, and the processing will always run at 96 kHz.
Or are you actually using the new moOde camilladsp integration? In that case it's switching samplerate automatically for you.
The BiQuad filters in your config work at any samplerate. Only convolution (FIR) filters, and BiQuads using the "Free" mode are locked to a single rate.
There are many opinions on what the optimal samplerate is, but there are two that are common. The first one is that is't best to avoid resampling altogether. The second is that it's best to upsample everything to the highest rate the playback device can handle, and do processing at the high rate.
You can set that if you want to stop the processing when there isn't anything playing, to save a little bit of power. You don't need to.
Hi Henrik,
Thanks for the reply!
It referred to GitHub - scripple/alsa_cdsp: ALSA plugin for Camilla DSP
Should I just change to this:
devices:
samplerate: $samplerate$
chunksize: 1024
queuelimit: 1
capture:
type: File
channels: $channels$
filename: "/dev/stdin"
format: $format$
playback:
type: ALSA
channels: $channels$
device: "hw:0"
format: S32LE
What would you do?
/Jens
Thanks for the reply!
Yes, I am using the new moOde camilladsp integration
I had a look into the alsa config. It seems to setup CamillaDSP in "/etc/alsa/conf.d/camilladsp.conf" is that the one you want?
It referred to GitHub - scripple/alsa_cdsp: ALSA plugin for Camilla DSP
Should I just change to this:
devices:
samplerate: $samplerate$
chunksize: 1024
queuelimit: 1
capture:
type: File
channels: $channels$
filename: "/dev/stdin"
format: $format$
playback:
type: ALSA
channels: $channels$
device: "hw:0"
format: S32LE
Great, also what I thought, that is why I didn't use the ones with coefficients.
What would you do?
/Jens
You don't need to change anything, it's all good!Yes, I am using the new moOde camilladsp integration
...https://github.com/scripple/alsa_cdsp
Should I just change to this:
devices:
samplerate: $samplerate$
Both are fine! But since you have it working with rate switching now, my suggestion would be to not worry about it and enjoy the musicWhat would you do?
You don't need to change anything, it's all good!
Both are fine! But since you have it working with rate switching now, my suggestion would be to not worry about it and enjoy the music
Thanks a lot, - I will
/Jens
That are impressive results!
One benefit of being able to use high samplerate is to adjust group delay quite fine at the crossoverpoints with just using sample delay and not having to resort to more advanced allpassfilters
If i remember right this example apply: 198 k sampling gives 3.6 degrees phase resolution at 1980 hz
And that 2k soundwave is 17 cm long. So adjustment in distanse between elements ican be as small as 1,7 mm using whole sample delay
One benefit of being able to use high samplerate is to adjust group delay quite fine at the crossoverpoints with just using sample delay and not having to resort to more advanced allpassfilters
If i remember right this example apply: 198 k sampling gives 3.6 degrees phase resolution at 1980 hz
And that 2k soundwave is 17 cm long. So adjustment in distanse between elements ican be as small as 1,7 mm using whole sample delay
And why care:
Say 4k xover freq
44,1 k sampling freq
Resolution mm pr sample:340*1000/44100=8mm
Wavelength 4k: 340*1000/4000=85mm
So 42mm path difference or 5 samles delay of one element means cancellation because they are out of phase
Fun example of phase cancelation
Allpass Filter tricks! - YouTube
Say 4k xover freq
44,1 k sampling freq
Resolution mm pr sample:340*1000/44100=8mm
Wavelength 4k: 340*1000/4000=85mm
So 42mm path difference or 5 samles delay of one element means cancellation because they are out of phase
Fun example of phase cancelation
Allpass Filter tricks! - YouTube
Such an allpass filter is included in the latest version, to (optionally) give the Delay filter subsample precision.
Jack support!
Someone on github asked why I wasn't using CPAL to support JACK. The only reason was that I simply didn't think of doing it. Since all of the code already existed it was a quick job to add that. I haven't tested more than that it seems to run and can send and receive audio from the jack server. If someone wants to give it a go, try the "jack" branch on github!
Someone on github asked why I wasn't using CPAL to support JACK. The only reason was that I simply didn't think of doing it. Since all of the code already existed it was a quick job to add that. I haven't tested more than that it seems to run and can send and receive audio from the jack server. If someone wants to give it a go, try the "jack" branch on github!
From Greg Timbers
«By using FIR filters, amplitude and phase can be manipulated independently so this constraint can be overcome. The hardware in the DEQX is very well implemented indeed, but it is no match for the esoteric discrete analog stuff. Still, the complete amplitude and time correction easily overcomes this handicap and has given me the best of both worlds. I now have all of the detail, dynamics, smoothness and spacial attributes I have been searching for with the ability to do room correction and frequency shaping as I wish. It is a win-win for me«
He has designed these super expensive speakers himself and chose to rip out the analogue xover when he retired.
So FIR and time aligment might be somthing. And now the DSP part can be done with a 50$ prosessor.
«By using FIR filters, amplitude and phase can be manipulated independently so this constraint can be overcome. The hardware in the DEQX is very well implemented indeed, but it is no match for the esoteric discrete analog stuff. Still, the complete amplitude and time correction easily overcomes this handicap and has given me the best of both worlds. I now have all of the detail, dynamics, smoothness and spacial attributes I have been searching for with the ability to do room correction and frequency shaping as I wish. It is a win-win for me«
He has designed these super expensive speakers himself and chose to rip out the analogue xover when he retired.
So FIR and time aligment might be somthing. And now the DSP part can be done with a 50$ prosessor.
Last edited: