RPi + CamillaDSP Tutorial

[somebodyelse]

Do you have specific knowledge of the mk4 or are you assuming that claimed UAC2 compliance means everything just works? There have been issues with nominally compliant devices like the 8A in the past, and it's only recently that MOTU have provided any degree of help with driver quirks for their devices.

 

[somebodyelse]

MOTU is "hiding" this information (in order to get us buying the new mk5).

I've never seen MOTU make claims of linux support for the mk5 either (not on their product page at the moment anyway). What we know about the Mk5 and linux has come from people who have bought one and tried it.

 

[Nutul]

Do you have specific knowledge of the mk4 or are you assuming that claimed UAC2 compliance means everything just works? There have been issues with nominally compliant devices like the 8A in the past, and it's only recently that MOTU have provided any degree of help with driver quirks for their devices.

The 2nd you said.

 

[mdsimon2]

Sounds like the Ultralite Mk4 has similar issues to the Ultralite AVB, I wouldn't use it on Linux -> https://linuxmusicians.com/viewtopic.php?t=18136.

Michael

 

[mdsimon2]

Ok, I think I got my config squared away now but just to make sure I do (and before I start taking measurements for HAF):
0: left ch
1: right ch
3: sub - summed from l/r channels

As discussed above, specifying -6 as the gain on each channel of the summed sub channel negates the summing:
View attachment 338126
so the sub channel is now effectively 0dB, just like the left and right channels.


Now, if I want to add some protection against clipping, I would do this:
View attachment 338127
which effectively puts each channels gain at -3dB, correct?

Yes, this looks good. I wouldn't attenuate by an additional 3 dB unless you are seeing clipped samples in CamillaDSP.

Michael

 

[Blew]

@Blew apologize for the late reply, I am currently out of town for the holidays.

Just a guess but I think the issue is that you have double camilladsp folders.

Thanks for replying and apologies for my own lateness! Yes you are correct about the folder names. I did this while upgrading from v1 to v2. I moved my v1 intact to /opt/camilladsp/camilladsp-v1 so I could roll back if necessary. The camilladsp user's home dir is /opt/camilladsp

You could use the stock script if you use only a single camilladsp folder or you could modify the script to add two camilladsp folders

configdir = active.split('camilladsp')[0] + 'camilladsp/' + 'camilladsp/' + 'configs/'

Thanks! I haven't tested this as I'd resolved it by using @melomane13's suggestion here:

configdir = os.path.expanduser( '~' ) + '/camilladsp/' + 'configs/'

EDIT: I could also modify the configdir line to look for 'configs' instead of camilladsp.

Personally, I prefer @melomane13's suggestion above because it references the user's home directory, which means the home dir name doesn't matter.
Either that or make a note in the tutorial to warn against using a username of "camilladsp" if installing camilladsp in a directory named "camilladsp" under the user's home dir.

 

[mdsimon2]

@Blew just uploaded a new version of flirc.py that specifically looks for "/camilladsp/configs/". This should allow maximum flexibility as you can locate your camilladsp folder outside the home directory if needed and will still work if you are using camilladsp as a username and running it from your home folder.

Michael

 

[glc650]

Yes, this looks good. I wouldn't attenuate by an additional 3 dB unless you are seeing clipped samples in CamillaDSP.

What's the downside to attenuating when you don't have clipped samples?

 

[Nutul]

What's the downside to attenuating when you don't have clipped samples?

None. Just overall volume slightly lower; but you can rise it by hand, still avoiding clipping.
The attenuation is introduced because you might emphasize a frequency range that in some tracks is already at high levels; and applying such emphasis to those tracks will cause them to clip.
BUT, if none of your tracks will ever clip with applied EQ, then you are fine (and most probably have a nice collection of music from before the loudness war...)

 

[mskis]

So I finally have Camilladsp up and running thanks to this thread and this script. Amazing how well it’s working. Seems to be switching sample rates ok, but how would I go about automatically applying a different FIR filter to each sample rate as it switches? I’m new/clueless about anything other than basic PEQ.

 

[Daverz]

So I finally have Camilladsp up and running thanks to this thread and this script. Amazing how well it’s working. Seems to be switching sample rates ok, but how would I go about automatically applying a different FIR filter to each sample rate as it switches? I’m new/clueless about anything other than basic PEQ.

Assuming you've already generated the resampled FIR filters, you need to name them according to the sample rate and then use the $samplerate$ token in your config file

"If the filename includes the tokens $samplerate$ or $channels$, these will be replaced by the corresponding values from the config. For example, if samplerate is 44100, the filename /path/to/filter_$samplerate$.raw will be updated to /path/to/filter_44100.raw."

GitHub - HEnquist/camilladsp: A flexible cross-platform IIR and FIR engine for crossovers, room correction etc.

A flexible cross-platform IIR and FIR engine for crossovers, room correction etc. - HEnquist/camilladsp

github.com

 

[mskis]

Assuming you've already generated the resampled FIR filters, you need to name them according to the sample rate and then use the $samplerate$ token in your config file

"If the filename includes the tokens $samplerate$ or $channels$, these will be replaced by the corresponding values from the config. For example, if samplerate is 44100, the filename /path/to/filter_$samplerate$.raw will be updated to /path/to/filter_44100.raw."

GitHub - HEnquist/camilladsp: A flexible cross-platform IIR and FIR engine for crossovers, room correction etc.

A flexible cross-platform IIR and FIR engine for crossovers, room correction etc. - HEnquist/camilladsp

github.com

Thank you! Do I need to create a different config for each sample rate?
Edit: figure it out. Changed the filename to include $samplerate$ in the GUI and it worked! This forum is the best. Thank you for your help.

 

[anadyr]

Hi everybody, new user here! I have a problem with CamillaDSP.
This is my setup: Bluesound Node 2i -> Toslink into Hifiberry DAC+DSP (Radpberry Pi 4) -> USB out into Topping D10s -> RCA into amplifier.

I think I have set up everything properly. The music from the streamer plays, the GUI works, and the volume slider in CamillaDSP works as well:

So my problem is: I have setup 7 filters, but they are not applied. So, the sound doesn't change (I can easily switch because the DAC is connected to the tape loop on the amplifier). At the same time you see (in the screenshot above) DSP load 0.0%. This underlines, I guess, that no digital signal processing is actually taking place... My config Bluesound-topping-d10s-thomann.yml is loaded properly:

This is the config file:
devices: adjust_period: null capture: channels: 2 device: hw:CARD=sndrpihifiberry format: S32LE type: Alsa capture_samplerate: null chunksize: 2048 enable_rate_adjust: false playback: channels: 2 device: hw:CARD=D10s format: S32LE type: Alsa queuelimit: null rate_measure_interval: null samplerate: 44100 silence_threshold: null silence_timeout: null stop_on_rate_change: null target_level: null volume_ramp_time: null filters: Thomann PEQ1: description: Thomann PEQ1 parameters: freq: 27.2 gain: -12 q: 20 type: Peaking type: Biquad Thomann PEQ2: description: Thomann PEQ2 parameters: freq: 57 gain: -5 q: 20 type: Peaking type: Biquad Thomann PEQ3: description: Thomann PEQ3 parameters: freq: 59.7 gain: 5 q: 1 type: Peaking type: Biquad Thomann PEQ4: description: Thomann PEQ4 parameters: freq: 80.6 gain: 0 q: 20 type: Peaking type: Biquad Thomann PEQ5: description: Thomann PEQ5 parameters: freq: 116.6 gain: 5 q: 20 type: Peaking type: Biquad Thomann PEQ6: description: Thomann PEQ6 parameters: freq: 287.2 gain: -2 q: 8 type: Peaking type: Biquad Thomann PEQ7: description: Thomann PEQ7 parameters: freq: 329.9 gain: -8 q: 8 type: Peaking type: Biquad mixers: {} pipeline: null processors: null title: Bluesound-topping-d10s-thomann.yml

I am pretty sure I overlook something but what? Any help would be appreciated

 

[mdsimon2]

@anadyr Your pipeline has nothing it in it. The pipeline is where you specify which filters apply to which channels. You also should create a mixer and apply it in the pipeline to define channel routing. I'm surprised you are getting any output at all without a mixer.

A separate issue is you do not have rate adjust and async resampling even though your capture and playback devices have different clock domains. This will result in buffer over/under runs over time.

Michael

 

[anadyr]

Thx! It works now; the sound is altered and the pipeline is clear:

I followed your suggestion by adding a mixer. It works fine, but in my case it also works fine without. Not sure it it matters but I keep it like this.

I need further googling about the "clock domains" issue. I have bought the Hifiberry DAC+DSP because it supports Asynchronous Sample Rate Converter (ASRC). I read somewhere that the output bitrate form the Bluesound Node 2i is variable. As far as I understand I have enabled it. But I am not sure if this is related to "clock domains"...
Edit: I have found and set the option "enable_rate_adjust".

 

[mdsimon2]

I guess it makes sense that you don't need a mixer when you have the same number of capture and playback channels.

Looking at it further it seems like you only need a mixer if you have a different number of capture and playback channels or you want different routing than just straight through, for example mixing L + R to a single mono channel or routing a 2 channel input to multichannel output.

Michael

 

[anadyr]

Another question: I am not sure what you mean with the async resampling remark. I have found the option "resampler_type", with various options (AsyncSinc, AsyncPoly) and the options Profile and Interpolation. Could you perhaps indicate what you think would be the best setting for my setup?
It is now set to Synchronous, and that plays fine...

 

[mdsimon2]

Another question: I am not sure what you mean with the async resampling remark. I have found the option "resampler_type", with various options (AsyncSinc, AsyncPoly) and the options Profile and Interpolation. Could you perhaps indicate what you think would be the best setting for my setup?
It is now set to Synchronous, and that plays fine...

Please read the github -> https://github.com/HEnquist/camilladsp. I'd use AsyncSinc with the balanced profile.

enable_rate_adjust (optional, defaults to false)

This enables the playback device to control the rate of the capture device, in order to avoid buffer underruns or a slowly increasing latency. This is currently supported when using an Alsa, Wasapi or CoreAudio playback device (and any capture device). Setting the rate can be done in two ways.

• Some capture devices provide a way to adjust the speed of their virtual sample clock (also called pitch adjust). This is available with the Alsa Loopback and USB Audio gadget devices on Linux, as well as the latest (currently unreleased) version or BlackHole on macOS. When capturing from any of these devices, the adjustment can be done by tuning the virtual sample clock of the device. This avoids the need for asynchronous resampling
• If asynchronous resampling is enabled, the adjustment can be done by tuning the resampling ratio. Then resampler must be set to one of the "Async" types. This is supported for all capture devices.

With Alsa capture devices, the first option is used whenever it's available. If not, and when not using an Alsa capture device, then the second option is used.

Rate adjust via resampling

When using the rate adjust feature to match capture and playback devices, one of the "Async" types must be used. These asynchronous resamplers do not rely on a fixed resampling ratio. When rate adjust is enabled the resampling ratio is dynamically adjusted in order to compensate for drifts and mismatches between the input and output sample clocks.

Using the "Synchronous" type with rate adjust enabled will print warnings, and any rate adjust request will be ignored.

Michael

 

[Wirrunna]

I see you've release some new V2.0.1 updates. I noticed the CamillaGUI port changed from 5005 back to 5000, is this going to be a long term change?
Michael

I performed the update (as per instructions in post #3 of this thread which Michael has updated for V2.0.1) and apart from the sinking feeling when the GUI would not re-connect on port 5005 , but does on port 5000, all went well.
Not sure what has changed.

 

[mdsimon2]

It sounds like Henrik is going to switch back to 5005 in an upcoming release. I'll probably revert the tutorial back to V2.0.0 so it all makes sense.

Michael