RPi4 + CamillaDSP Tutorial

[dehati_paul]

@mdsimon2
Maybe this has been asked already - but does CamillaDSP resample everything to 96khz internally for applying DSP? I think earlier you referred to an analysis, which suggested the benefit of resampling to 96khz over 48khz. But is there an automated option to keep the entire flow at the input sample rate (which is followed by RME, if I am not mistaken)? I understand the need to change the bit depth to float 64 for DSP purpose, but does/can the output get/be automatically scaled down to input bit depth as well?

Thanks,

Dehati

 

[somebodyelse]

As configured here it'll resample everything. The automated option to change configs you're thinking of is probably https://github.com/scripple/alsa_cdsp. Why would you want to reduce the output bit depth further than necessary?

 

[dehati_paul]

As configured here it'll resample everything. The automated option to change configs you're thinking of is probably https://github.com/scripple/alsa_cdsp. Why would you want to reduce the output bit depth further than necessary?

I am okay with the bitdepth upsampling (and I understand the requirements). My main question was related to sample rate upsampling. Is that needed, can be avoided?

 

[mdsimon2]

Not all the configs resample but they do run at a constant sample rate. For example the Okto AES input config has no resampling but expects a 96 kHz input.

All of the streamer configs expect a 44.1 kHz input and resample to a playback rate of 96 kHz.

You can run at native sample rates but as @somebodyelse mentioned you need to implement automated configuration changing because you need to change the configuration every time the sample rate changes.

Honestly my biggest wish for CamillaDSP is the ability to accept a wide range of input sample rates and resample to a constant sample rate using one configuration. As it stands now to deal with multiple input rates you either need to resample upstream (say in your software player for a streamer configuration or with an ASRC like the OpenDRC-DI for physical digital inputs) or you need to implement configuration switching.

Michael

 

[dehati_paul]

Not all the configs resample but they do run at a constant sample rate. For example the Okto AES input config has no resampling but expects a 96 kHz input.

All of the streamer configs expect a 44.1 kHz input and resample to a playback rate of 96 kHz.

You can run at native sample rates but as @somebodyelse mentioned you need to implement automated configuration changing because you need to change the configuration every time the sample rate changes.

Honestly my biggest wish for CamillaDSP is the ability to accept a wide range of input sample rates and resample to a constant sample rate using one configuration. As it stands now to do deal with multiple input rates you either need to resample upstream (say in your software player for a streamer configuration or with an ASRC like the OpenDRC-DI for physical digital inputs) or you need to implement configuration switching.

Michael

Thanks for the clarification!

 

[dc655321]

my biggest wish for CamillaDSP is the ability to accept a wide range of input sample rates and resample to a constant sample rate using one configuration.

By chance, do you know why this is not the case? Seems like the right thing to do imo.

 

[mdsimon2]

By chance, do you know why this is not the case? Seems like the right thing to do imo.

I do not know the specifics of why but Henrik has indicated that if the resampling ratio changes by more than a few percent a reload is needed to adjust buffers and change the interpolation filters -> #1,621.

Michael

 

[Daverz]

Not all the configs resample but they do run at a constant sample rate. For example the Okto AES input config has no resampling but expects a 96 kHz input.

All of the streamer configs expect a 44.1 kHz input and resample to a playback rate of 96 kHz.

You can run at native sample rates but as @somebodyelse mentioned you need to implement automated configuration changing because you need to change the configuration every time the sample rate changes.

Honestly my biggest wish for CamillaDSP is the ability to accept a wide range of input sample rates and resample to a constant sample rate using one configuration. As it stands now to deal with multiple input rates you either need to resample upstream (say in your software player for a streamer configuration or with an ASRC like the OpenDRC-DI for physical digital inputs) or you need to implement configuration switching.

Michael

I eventually settled on resampling everything to 48 kHz in LMS using sox by using a custom /etc/squeezebox/convert.conf with the entry for flac transcoding:

flc flc transcode * # IFT:{START=--skip=%t}U:{END=--until=%v}D:{RESAMPLE=vol -1dB rate -v -L -s %d}E:{NOSTART=I} [flac] -dcs $START$ $END$ --force-raw-format --sign=signed --endian=little -- $FILE$ | [sox] -q -t raw --encoding signed-integer -b $SAMPLESIZE$ -r $SAMPLERATE$ -c $CHANNELS$ -L - -t flac -C 0 - $RESAMPLE$

Then setting my squeezelite commandline args on my RPi4 in /etc/defaults/squeezelite to

SB_EXTRA_ARGS="-a 120:4:32:1 -r 48000,"

Together these ensure that everything that's not originally sampled at 48kHz gets resampled to 48kHz on the server using the best sox settings. This does lower headroom by 1 dB to avoid clipping.

I did consider using 96 kHz, but that seems kind of pointless when all my filters only go out to 24 kHz.

 

[dc655321]

I do not know the specifics of why but Henrik has indicated that if the resampling ratio changes by more than a few percent a reload is needed to adjust buffers and change the interpolation filters -> #1,621.

Michael

Interesting. Thanks.

When I was building my convolution engine, I also encountered The Resampling Question. I convinced myself that it’s a rational thing to resample the input signals to a semi-static, user-selectable baseline rather than shift configuration around or interpolate filters.

I took a hard look at libsoxr and it seemed to provide what’s needed (arbitrary sized input block sizes and rates, reasonably fast, clean api). I also started building my own, just so I understood what it’s all about.

 

[phofman]

Honestly my biggest wish for CamillaDSP is the ability to accept a wide range of input sample rates and resample to a constant sample rate using one configuration.

The task is not as simple as it may sound. But specific implementation options for the loopback and USB gadget are being discussed https://github.com/HEnquist/camilladsp/issues/202

 

[mdsimon2]

The task is not as simple as it may sound. But specific implementation options for the loopback and USB gadget are being discussed https://github.com/HEnquist/camilladsp/issues/202

Thank you for sharing, definitely much more complicated than I initially imagined. After skimming that I’m not sure it is worth the complication. On all of my CamillaDSP systems I have implemented upstream resampling (either in software or hardware) in order to run CamillaDSP at a constant sample rate and it works great.

Michael

 

[dc655321]

The task is not as simple as it may sound. But specific implementation options for the loopback and USB gadget are being discussed https://github.com/HEnquist/camilladsp/issues/202

Looks like complications are a function of the loopback design of CamillaDSP and OS audio stack API short-comings.
Is that a reasonable assessment?

I had in mind the simpler scenario, as you said in your GH Issue comment (at least I assume that was you?!), "In configurations with resampling to one fixed playback rate for any capture rate no config reload would be needed...". It seems the loopback design omits that possibility (without a better accounting API available)?

IIRC, ASR member Cosmik (no longer here) built a convolution engine with a similar use of alsa loopback and resampling.
I haven't worked on my own conv. engine for a looong time, but I have a semi-finished alsa extplug version and the beginnings of a ioplug integration.
I would be interested to know what factors lead to the adoption of the loopback (on alsa) architecture, if you're aware.

 

[phofman]

Honestly, I do not understand your question. snd-aloop is a low-level kernel driver which "just" forwards samples from playback alsa device to capture alsa device. CDSP is a purpose-built user-space software. How is user-space resampling on capture side related to the loopback kernel device?

IMO the design is correct. Do you have an example of a comparable loopback device with comparable configuration features in other OS audio stacks?

 

[dc655321]

Honestly, I do not understand your question.

Fair enough.

IMO the design is correct.

Fundamentally, I was trying to understand why the loop-back architecture was chosen (on Linux). Seems unnecessary to me.
Happy to be shown otherwise.

However, I feel like I'm polluting Michael's thread with this line of inquiry and expressly do not want to do that.
If you would like, we could continue the conversation privately. Up to you.

 

[Elfsberg]

Hey guys,

I can't for the life of me find the command to list audio devices. It's supposed to be part of a guide, maybe on the official GitHub.

Anyone?

Thanks

 

[somebodyelse]

Hey guys,

I can't for the life of me find the command to list audio devices. It's supposed to be part of a guide, maybe on the official GitHub.

Anyone?

Thanks

I'm not sure if I'm misunderstanding the question. You mean something like this?

aplay -L

 

[Elfsberg]

I'm not sure if I'm misunderstanding the question. You mean something like this?

aplay -L

Exactly. Thanks

the HDMI output is not displayed, must it be installed separately? How?

 

[somebodyelse]

the HDMI output is not displayed, must it be installed separately? How?

I haven't used ubuntu on the Pi, but unless they're doing something odd you shouldn't need to install anything separately. Missing audio on HDMI has been reported when the HDMI device sends incorrect/malformed EDID information, as in this placeholder bug report which has a couple of suggested workarounds. This thread has a few more suggestions.

 

[Elfsberg]

Switched the HDMI port to what appears to be #1 and it showed up. Thanks!

Edit:

new config running, 4 channels to 9 chan receiver.

Been waiting +10 years for stuff like this.

 

[HenrikEnquist]

Fundamentally, I was trying to understand why the loop-back architecture was chosen (on Linux). Seems unnecessary to me.
Happy to be shown otherwise.

Did you mean why CamillaDSP uses the loopback approach and not the Alsa IO plugin api?