Do you mean the view of the pipeline as a block diagram? It would be possible to add some interactivity to that, but that would be a very large amount of work.
One thing that was suggested some time back is to change the Filter tab. Instead of having a button to manually open a plot in a popup, it could always show an up-to-date plot on the side. I think this is a good idea that could make modifying filters faster and easier.
There is also a plan to add an optional immediate mode, where parameter changes are applied to the dsp immediately.
I mean the graph showing all of the filters in a step. The order of steps wouldn't change but you could drag a filter up and down to change gain; left and right to change frequency; scrollwheel up and down to change Q.
Steps are usually mono but if you use the same filter in both steps then you could look at channel 0 and change the filter but you'd hear the result in both channels.
Ok, then the answer is basically the same as for the block diagram. Technically definitely possible, but a large amount of work to implement. Also these drag and scroll actions would have to affect different parameters for different filter types, could get confusing.
I looked into making installers a while ago. Apple are forcing developers to jump through a lot of hoops. To start with I would need to join the apple developer program and pay 99 dollars per year. Then there is a long procedure to follow to prepare each new release. I don't have the time and patience for this stuff..On an other note...Can we hope for an OSX style installer for the Mac version? I think this would open up the audience base considerably.
//
On
My old macbook and the ancient firewire 400 card can live a second life as an active crossover and music client. It took me awhile to understand all that stuff, but now it works beautifully. Together with Squeezelite and Soundflower, it is such an elegant and slender solution and, if successfully installed, very easy to maintain. Thank you Henrik.
By the way, I get an error message after upgrading to CamillaDSP 1.0.0-rc3 from 0.6.3, but everything is still working as expected. The same
config file shows no error in 0.63.
On the other Hand, being a total noob with Terminal stuff, I had a lot of fun learning the basics of installing and maintaining those files.I can fully understand that. We just have to hope for something comparable easy for the user
//
My old macbook and the ancient firewire 400 card can live a second life as an active crossover and music client. It took me awhile to understand all that stuff, but now it works beautifully. Together with Squeezelite and Soundflower, it is such an elegant and slender solution and, if successfully installed, very easy to maintain. Thank you Henrik.
By the way, I get an error message after upgrading to CamillaDSP 1.0.0-rc3 from 0.6.3, but everything is still working as expected. The same
config file shows no error in 0.63.
Sorry, that was stupid, I got an error message after trying in 0.6.3 too. Now I simply deleted those lines in the config file and all is ok. No idea how they got there...
edit time ran out, so.... well those lines seem to be produced by camilladsp 1.0.0-rc3. saving the GUI to the config files puts them there. older versions don't do that.
Those two lines are new in camilladsp 1.0. Once that is released I'll update the GUI too.
@HenrikEnquist
Hi, I have another question if that's ok.
I'm trying to get my head around resampling. I've read the section of the docs several times now but I'm just not sure what applies to my case. I'm just playing flac files and mp3s (mostly flacs) from a pi running moOde (so no streaming from other devices - I understand that this is simply a capture device of 'file' reading S32LE format). I think all the flac files and mp3s are 44.1kHz although potentially there might be a small number which are a different samplerate.
I'm only using CamillaDSP to have 2 channels of about 10 biquad filters to apply PEQ and this is working fine, but I've read that resampling to 96000 hz will make this PEQ potentially better. My output device (Topping E30 DAC via USB) can handle this rate. I played around in the Devices part of CamillaDAP within moOde and it is outputting 96000 hz to the DAC but I got - very occasionally - dropouts. I'd like to fix this as I never had dropouts on the same system with either moode's PEQ, or with CamillaDSP and this set of filters but without resampling.
Given what I've read I'm assuming I can not bother with enable_rate_adjust because most input files are 44.1 khz, but what about the ones which aren't? They seem to play ok so how's that working - is there a sound quality hit here?
the docs suggest a Synchronous resampler_type should be ok but in that case what should the capture_samplerate be? What happens if I set it to 44.1 but I then play a different rate? It seems to work with a capture_samplerate of 0 but does that mean it's figuring it out itself, like with enable_rate_adjust?
Giving the resampler a fixed rate of 44100 and using a samplerate of 96000 and using capture rate monitoring to stop on rate change - in the hope that I can simply stop playback of non-44100 music (so I can go and convert the file to 44100 myself) doesn't seem to stop playback when the file isn't 44100 so I'm guessing this is maybe for streams not files?
I guess my two issues are: 1) I don't mind trial and error to figure this stuff out but I'd like to be confident that I'm doing this the best possible way in terms of sound quality given the hardware, and 2) I'd like to do away with the little pops I rarely but occasionally hear. Depending on settings I'm rarely over 20% of cpu on 1 of the 4 cores; I have most of the 2gb ram available; I see nothing obvious in logs etc.
Or is this all a waste of time and there's actually no sound quality difference if I just leave all the settings on the Devices page alone and just have CamillaDSP do the PEQ at whatever bitrate the music currently is?
Hi, I have another question if that's ok.
I'm trying to get my head around resampling. I've read the section of the docs several times now but I'm just not sure what applies to my case. I'm just playing flac files and mp3s (mostly flacs) from a pi running moOde (so no streaming from other devices - I understand that this is simply a capture device of 'file' reading S32LE format). I think all the flac files and mp3s are 44.1kHz although potentially there might be a small number which are a different samplerate.
I'm only using CamillaDSP to have 2 channels of about 10 biquad filters to apply PEQ and this is working fine, but I've read that resampling to 96000 hz will make this PEQ potentially better. My output device (Topping E30 DAC via USB) can handle this rate. I played around in the Devices part of CamillaDAP within moOde and it is outputting 96000 hz to the DAC but I got - very occasionally - dropouts. I'd like to fix this as I never had dropouts on the same system with either moode's PEQ, or with CamillaDSP and this set of filters but without resampling.
Given what I've read I'm assuming I can not bother with enable_rate_adjust because most input files are 44.1 khz, but what about the ones which aren't? They seem to play ok so how's that working - is there a sound quality hit here?
the docs suggest a Synchronous resampler_type should be ok but in that case what should the capture_samplerate be? What happens if I set it to 44.1 but I then play a different rate? It seems to work with a capture_samplerate of 0 but does that mean it's figuring it out itself, like with enable_rate_adjust?
Giving the resampler a fixed rate of 44100 and using a samplerate of 96000 and using capture rate monitoring to stop on rate change - in the hope that I can simply stop playback of non-44100 music (so I can go and convert the file to 44100 myself) doesn't seem to stop playback when the file isn't 44100 so I'm guessing this is maybe for streams not files?
I guess my two issues are: 1) I don't mind trial and error to figure this stuff out but I'd like to be confident that I'm doing this the best possible way in terms of sound quality given the hardware, and 2) I'd like to do away with the little pops I rarely but occasionally hear. Depending on settings I'm rarely over 20% of cpu on 1 of the 4 cores; I have most of the 2gb ram available; I see nothing obvious in logs etc.
Or is this all a waste of time and there's actually no sound quality difference if I just leave all the settings on the Devices page alone and just have CamillaDSP do the PEQ at whatever bitrate the music currently is?
@sehnsucht The camilladsp implementation in moOde uses an alsa pcm plugin, that feeds the samples to camilladsp on stdin. In practice this means that you don't need to worry about the rate_adjust. This is used to sync the sample clocks of different devices, which isn't needed since the plugin will just follow the output device. So you can leave enable_rate_adjust at false and use a synchronous resampler.
Using the plugin means that the capture_samplerate setting in the config gets overridden by whatever value the plugin is opened at. Here I think moOde can be configured in different ways, to either open the device at the sample rate of the current file, or to resample. When it changes sample rate, then the camilladsp process is restarted. You don't need stop_in_rate_change.
Dropouts can usually be fixed by increasing the chunksize. Try doubling the value. If you still get some, try doubling again.
There shouldn't be any quality difference between running the biquads at 44.1 or 96 kHz. The way biquads work "better" at higher rates is that you avoid the so called frequency warping. This means that the response of biquads don't quite follow the response of the corresponding analog filter for high frequencies (when you start getting close to half the sample rate). It doesn't cause distortion or noise. It is only a problem if you want to use the same filter definitions at several sample rates. But if you do room correction, you probably do most corrections at considerably lower frequencies, and then you don't need to think about this.
Using the plugin means that the capture_samplerate setting in the config gets overridden by whatever value the plugin is opened at. Here I think moOde can be configured in different ways, to either open the device at the sample rate of the current file, or to resample. When it changes sample rate, then the camilladsp process is restarted. You don't need stop_in_rate_change.
Dropouts can usually be fixed by increasing the chunksize. Try doubling the value. If you still get some, try doubling again.
There shouldn't be any quality difference between running the biquads at 44.1 or 96 kHz. The way biquads work "better" at higher rates is that you avoid the so called frequency warping. This means that the response of biquads don't quite follow the response of the corresponding analog filter for high frequencies (when you start getting close to half the sample rate). It doesn't cause distortion or noise. It is only a problem if you want to use the same filter definitions at several sample rates. But if you do room correction, you probably do most corrections at considerably lower frequencies, and then you don't need to think about this.
Many thanks for this explanation. It all makes sense. I shall try and find out more about what moOde is doing with CamillaDSP outside of the web page used for manipulating the pipeline. I've created a simple pipeline (96kHz, no enable_rate_adjust/stop_in_rate_change) and will give that a go listening out for buffer underruns. I'm sticking with 96kHz for now as I have the CPU (current config sees a maximum of 10% CPU on a single core). I'm just doing headphone EQ with the highest filter being a highshelf at 10kHz so not getting anywhere the problematic frequencies.
Just a thought - is detecting buffer-underruns easy? It would be handy if they were logged or displayed somewhere. It would then be possible to alter a config and leave it playing a large playlist overnight and see if it was stable. I did see some underruns in the log but they seemed to coincide with starting a song, and were not present when I actually had a pop in the sound.
I just installed the latest updates for my raspberrypi 4b on Raspberrypi OS bullseye 64 bit using the updater plugin. Was pleasantly surprised to see an update to kernel 5.15.30. This is good news, dont need to manually update the kernel anymore to avoid issues with my usb DAC and rc3 version of camilladsp.
You could use archlinuxarm... the kernel at the present time is "5.17.1-1-aarch64-ARCH"....
I am considering a new CamillaDSP setup that uses two USB 4-channel audio interfaces to obtain 8 total output channels. Two input channels need to be processed. Each channel will undergo the exact same DSP steps (left and right channels of a loudspeaker crossover). The audio interfaces are asynchronous, so each will have its own clock. I'm wondering what is the best way to use CamillaDSP under this scenario.
Should I run two separate and independent CamillaDSP processes, with each overseeing one of the interfaces and routing one input channel to the 4 output channels on only that interface? This would allow the software to govern the difference between capture and playback rate of each interface independently. On paper this seems like a good approach, if it is possible to run more than one Camilla process simultaneously. The two processes would not be synchronized, and I wonder if that might eventually cause problems. The inputs are live, so maybe not.
Alternately, could one Camilla process be configured to get input from one or both of the interfaces and write to both interfaces, all in the same process while independently adjusting the rates for the two interfaces?
I am not sure which approach is best/possible. Looking for input. Thanks.
Edit: if I needed a mono (left+right) channel, would that be possible or would that muck up the rate adjustment?
Should I run two separate and independent CamillaDSP processes, with each overseeing one of the interfaces and routing one input channel to the 4 output channels on only that interface? This would allow the software to govern the difference between capture and playback rate of each interface independently. On paper this seems like a good approach, if it is possible to run more than one Camilla process simultaneously. The two processes would not be synchronized, and I wonder if that might eventually cause problems. The inputs are live, so maybe not.
Alternately, could one Camilla process be configured to get input from one or both of the interfaces and write to both interfaces, all in the same process while independently adjusting the rates for the two interfaces?
I am not sure which approach is best/possible. Looking for input. Thanks.
Edit: if I needed a mono (left+right) channel, would that be possible or would that muck up the rate adjustment?
Last edited:
You will have timing problems trying to split and write an interleaved 8-channel stream to multiple 4-channel USB playback devices. The left channel's timing will be different from the right (virtical quad-amping) or each speaker will be different from itself (horizontal quad-amping).
CamillaDSP would also have to manage the connections to 2 different devices.
I think you may have misunderstood what I am after:
This is for a multiway stereo crossover that gets its input from the ADC. In total processing needs to be carried out on two input channels (left, right) not eight. There are two interfaces. Each has four inputs and four outputs. So the processing for the left or right could be operated completely within its own interface, with one input channel and four output channels. There would then be two such streams needed for stereo, but they are essentially independent as long as you do not need to combine between the two, e.g. mix to mono.
My question is more whether two instances of CamillaDSP could be running simultaneously, not interacting with each other, on the same machine in order to do that. Each instance would manage a single interface. I could do it using two computers but that seems a bit wasteful on the hardware side.
The last comment in my post was whether all of that could or should be combined under one CamillaDSP process, but I think the answer is no.
Last edited:
If I understand correctly, you would still have the timing issues mentioned in my response.
You have L1 and R1 coming in and L[1-4] and R[1-4] going out (vertical case). LN outputs will still not be synced with RN outputs because they are 2 different Async USB devices, 2 different clocks and 2 unsynced streams.
Last I checked, simultaenous versions of AlsaCDSP will not play nice.
If each copy of CamillaDSP is started with its own config file (like what AlsaCDSP does), simultaneous copies may run if they don't share any temp files or mmap areas.