RPi4 + CamillaDSP Tutorial

[LandscapeJohn]

Also, are you using Ubuntu? The reason I went with lgpio initially is that I had read that RPi.GPIO was unavailable on kernels newer than 5.11 -> https://ubuntu.com//blog/raspberry-pi-gpio-support-in-ubuntu but maybe this is no longer the case? Actually looking at this further it seems like RPi.GPIO may still be on the way out -> https://waldorf.waveform.org.uk/2022/the-one-where-dave-breaks-stuff.html.

Michael

That's a good point, it does look like RPi.GPIO is on borrowed time. The thing is that using a direct library seems WAY faster than using the lgpio method of accessing the pins. In my benchmark testing the old way is 11+ times faster than the new way. Maybe I'm doing something wrong but here's the result of five test runs using Python, one using lgpio and the other using RPi.GPIO:

john@camilla:~/source/pybench$ python3 t2.py ;python3 t3.py lgpio 84111 toggles per second RPi.GPIO 962372 toggles per second john@camilla:~/source/pybench$ python3 t2.py ;python3 t3.py lgpio 83317 toggles per second RPi.GPIO 979529 toggles per second john@camilla:~/source/pybench$ python3 t2.py ;python3 t3.py lgpio 83688 toggles per second RPi.GPIO 974429 toggles per second john@camilla:~/source/pybench$ python3 t2.py ;python3 t3.py lgpio 84055 toggles per second RPi.GPIO 998126 toggles per second john@camilla:~/source/pybench$ python3 t2.py ;python3 t3.py lgpio 84964 toggles per second RPi.GPIO 1027179 toggles per second

Doing a similar test with C comparing pigpio to lgpio shows an even greater improvement with pigpio being 27+ times faster than lgpio:

john@camilla:~/source/bench$ ./lgpio ;sudo ./pigpio C lgpio: 141463 toggles per second C pigpio: 3900408 toggles per second john@camilla:~/source/bench$ ./lgpio ;sudo ./pigpio C lgpio: 141355 toggles per second C pigpio: 4009276 toggles per second john@camilla:~/source/bench$ ./lgpio ;sudo ./pigpio C lgpio: 139096 toggles per second C pigpio: 3930747 toggles per second john@camilla:~/source/bench$ ./lgpio ;sudo ./pigpio C lgpio: 142311 toggles per second C pigpio: 3885954 toggles per second john@camilla:~/source/bench$ ./lgpio ;sudo ./pigpio C lgpio: 141962 toggles per second C pigpio: 3735742 toggles per second john@camilla:~/source/bench$

For what it's worth I'm using Ubuntu 22.04.1 LTS with kernel 5.15.0-1023-raspi.

Please feel free to share any modifications to oled.py.

Here's my modified version of the OLED Python script.

 

[MCH]

Marcos , is this with the 5 volt relay from this post ?

RPi4 + CamillaDSP Tutorial

Yes - that is what I do. I use SSH button on my android phone. Was free on the google play store last time I looked, without any adware (and I hope no spyware :) Since I control everything from my phone (including volume via MPDroid client to MPD on the Pi) , I saw no reason to use a physical...

www.audiosciencereview.com

I am interested in a brief explanation.

Sure, the very brief version is this if your objective is to shutdown and boot the pi properly to standby mode and power off all the devices you have connected to the USB ports. No need to say that you should do all this at your own risk, I just compiled and tested info that i have found online, but i am far from an expert. Remember that plugging a wrong pin could fry your pi... your decision:

- You need to find a IR remote 5 V relay that has "jog" or "jogging" or "Inching" mode (closes the relay for a brief moment when you press the button).
- Power the relay from the pi gpio 5V and connect the normally open terminals of the relay to gpio3 and ground.
- If you have followed this tutorial, most probably gpio3 is being used by i2c and the shut down command will not work (the boot will work anyways). You can choose to use a different gpio to shutdown, but if you want to use the same gpio3 for both shut down and boot, you need to disable the i2c port, you can do it at the same time you input the shutdown option, like this:

sudo nano /boot/firmware/config.txt

in this document, you need to make two changes:

change the following line to "off". This disables the i2c port:
dtparam=i2c_arm=off

at the end of the document, paste:
dtoverlay=gpio-shutdown,gpio_pin=3

If you want to simultaneously switch off other cards that are not powered by the pi, you can read this (again, at your risk):

Noob playing with MOSFETS! advice welcomed - Not directly audio related

Hi all, I am working on a way to get my minidsp 2x4HD to turn off when the raspberry pi to which it is connected turns off. The minidsp is powered by a 12V DC wallwart and uses 2.5W according to minidsp specs. Because of safety/insurance reasons, i don't want to do anything on the mains level...

www.audiosciencereview.com

All this will work in any raspberry pi 4b except in revision 1.1. If your pi is rev.1.1 it will not power off all the USB ports on shutdown. In this case you need to opt for a second option that instead of putting the rpi in stand by mode, puts it in low power consumption mode. The advantage of this is that now the pi will be almost completely shut down and will use almost no power, but this will also deactivate the gpio pins, so you will need a two channel relay and solder a header pin to the global_en pad of the pi board, but that is the long version....
Good luck!!

 

[LukeD]

Caveat - I've only gotten through the first 14 or so pages of this thread so apologies if I'm repeating old news...

Firstly, @mdsimon2, thanks for a great write-up/tutorial. By using it I've been able to get camilladsp working on a RPi3B+ alongside OSMC. Audio is sent over USB to my 2-ch DAC. The only minor hiccups I had with getting everything to work were:

1. Initially installing the 64bit version. A silly mistake... it took me a while to realise that I actually needed the 32bit version, d'oh.
2. I needed to use hw:loopback,1 not hw:loopback,0 for the capture device. Perhaps a comment could be added to the tutorial to suggest this change if things don't initially work?

In playing around I've noticed that using plughw instead of just hw adds an additional sampling rate conversion that allows for any mis-match between what OSMC is generating and what camilladsp expects for the capture device.

For e.g. setting OSMC to a fixed output of 96kHz and setting the sample rate within camilladsp to be 48 kHz works provided the capture device is plughw and not hw. I assume the additional conversion is happening within alsa but have no idea about its quality (compared with doing it in OSMC / elsewhere). It seems to be a "hack" way to accomodate sample rate changes in the source, something which isn't currently possible within camilladsp.

I've noticed a few drops outs when setting everything to 96kHz (or when upsampling within camilladsp from 48kHz) and some underruns in the log file so have decided to keep both OSMC and camilladsp fixed at 48kHz. I haven't figured out yet what setting needs tweaking.

One question I have is, within camilladsp, why can I set the capture rate to 48kHz and the sample rate to 96kHz but not need to have enable_resampling turned on? Surely resampling must be occuring if the input rate is different to the output rate?

Second question: I'm still a little confused as to whether rate adjustment is needed when the capture device is a loopback device? Can anyone elighten me? I've currently got it enabled.

 

[mdsimon2]

That's a good point, it does look like RPi.GPIO is on borrowed time. The thing is that using a direct library seems WAY faster than using the lgpio method of accessing the pins. In my benchmark testing the old way is 11+ times faster than the new way. Maybe I'm doing something wrong but here's the result of five test runs using Python, one using lgpio and the other using RPi.GPIO:

john@camilla:~/source/pybench$ python3 t2.py ;python3 t3.py lgpio 84111 toggles per second RPi.GPIO 962372 toggles per second john@camilla:~/source/pybench$ python3 t2.py ;python3 t3.py lgpio 83317 toggles per second RPi.GPIO 979529 toggles per second john@camilla:~/source/pybench$ python3 t2.py ;python3 t3.py lgpio 83688 toggles per second RPi.GPIO 974429 toggles per second john@camilla:~/source/pybench$ python3 t2.py ;python3 t3.py lgpio 84055 toggles per second RPi.GPIO 998126 toggles per second john@camilla:~/source/pybench$ python3 t2.py ;python3 t3.py lgpio 84964 toggles per second RPi.GPIO 1027179 toggles per second

Doing a similar test with C comparing pigpio to lgpio shows an even greater improvement with pigpio being 27+ times faster than lgpio:

john@camilla:~/source/bench$ ./lgpio ;sudo ./pigpio C lgpio: 141463 toggles per second C pigpio: 3900408 toggles per second john@camilla:~/source/bench$ ./lgpio ;sudo ./pigpio C lgpio: 141355 toggles per second C pigpio: 4009276 toggles per second john@camilla:~/source/bench$ ./lgpio ;sudo ./pigpio C lgpio: 139096 toggles per second C pigpio: 3930747 toggles per second john@camilla:~/source/bench$ ./lgpio ;sudo ./pigpio C lgpio: 142311 toggles per second C pigpio: 3885954 toggles per second john@camilla:~/source/bench$ ./lgpio ;sudo ./pigpio C lgpio: 141962 toggles per second C pigpio: 3735742 toggles per second john@camilla:~/source/bench$

For what it's worth I'm using Ubuntu 22.04.1 LTS with kernel 5.15.0-1023-raspi.


Here's my modified version of the OLED Python script.

Thanks for sharing.

I really like the idea of using C instead of python for the display code. I don't love the idea of having to port pycamilladsp to C as I am worried it won't stay up to date but do you think if there was a separate C function for the display that was called by the python routine it would maintain the same improved performance? Seems like that might be a good compromise for maintaining the usability of pycamilladsp while also getting a faster display.

I am excited to look at this in more detail when I get back home in March.

Michael

 

[mdsimon2]

For e.g. setting OSMC to a fixed output of 96kHz and setting the sample rate within camilladsp to be 48 kHz works provided the capture device is plughw and not hw. I assume the additional conversion is happening within alsa but have no idea about its quality (compared with doing it in OSMC / elsewhere). It seems to be a "hack" way to accomodate sample rate changes in the source, something which isn't currently possible within camilladsp.

In my experience using plughw will invoke the default ALSA sampler which is rather low performance. I made some measurements of this here -> #34. There are ways to use a higher quality resampler with plughw but it is a bit of resource hog. I made some measurements of that here -> #851.

One question I have is, within camilladsp, why can I set the capture rate to 48kHz and the sample rate to 96kHz but not need to have enable_resampling turned on? Surely resampling must be occuring if the input rate is different to the output rate?

Probably best to share a log to see what is actually occurring. My understanding is that if resampling is not enabling the capture rate defaults to the playback rate.

Second question: I'm still a little confused as to whether rate adjustment is needed when the capture device is a loopback device? Can anyone elighten me? I've currently got it enabled.

You need rate adjustment to prevent buffer under/over runs as the loopback has a different clock from your DAC but you do not need to implement asynchronous resampling as rate adjust can control the loopback clock.

Michael

 

[LandscapeJohn]

Thanks for sharing.

I really like the idea of using C instead of python for the display code. I don't love the idea of having to port pycamilladsp to C as I am worried it won't stay up to date but do you think if there was a separate C function for the display that was called by the python routine it would maintain the same improved performance? Seems like that might be a good compromise for maintaining the usability of pycamilladsp while also getting a faster display.

I am excited to look at this in more detail when I get back home in March.

Michael

I'd actually been thinking about the pyCamillaDSP thing this weekend and how I didn't like incorporating that into my program due to the GPL license. Everything else I'm using is MIT and I wanted to keep that as the license for the entire project. Really the screen is only using a small subset of the commands offered so I decided to just call CamillaDSP directly from the C program for the handful of queries that the display needs in order to know status and levels.

Your idea of calling a C program to update the display from Python is probably sound but I don't know either language well enough to know how to integrate them like that. Perhaps a client/server model? Either way it seems like more trouble than it's worth, IMO. Remember, the pyCamillaDSP addon is just a Python interface to interact with the websocket server in CamillaDSP proper. As long as the underlying websocket interface doesn't deprecate the commands needed (ie, GetVolume, GetState, etc.) then the OLED should still be able to work even after it's updated.

I finally got the C program hopefully usable enough to checkin to Github:

https://github.com/landscapejohn/DSPOLED

 

[Triliza]

Sorry for the noobish question, but I can't seem to be able to figure it out myself, simple as it may actually be. How can I apply the eq filters (for Elac DBR62) that are generated from github/pierreaubert to get a flat anechoic spin? I am using Moode and will use the integrated camillaDSP, the filters are:

EQ for Elac Debut Reference DBR-62 computed from ASR data
Preference Score 5.71 with EQ 6.30
Generated from http://github.com/pierreaubert/spinorama/generate_peqs.py v0.19
Dated: 2023-01-22-13:08:02

Preamp: -3.2 dB

Filter  1: ON PK Fc    33 Hz Gain +3.00 dB Q 1.17
Filter  2: ON PK Fc   177 Hz Gain -2.32 dB Q 1.06
Filter  3: ON PK Fc  1828 Hz Gain +2.98 dB Q 1.76
Filter  4: ON PK Fc   804 Hz Gain -1.59 dB Q 3.00

 

[LandscapeJohn]

Sorry for the noobish question, but I can't seem to be able to figure it out myself, simple as it may actually be. How can I apply the eq filters (for Elac DBR62) that are generated from github/pierreaubert to get a flat anechoic spin? I am using Moode and will use the integrated camillaDSP, the filters are:

EQ for Elac Debut Reference DBR-62 computed from ASR data
Preference Score 5.71 with EQ 6.30
Generated from http://github.com/pierreaubert/spinorama/generate_peqs.py v0.19
Dated: 2023-01-22-13:08:02

Preamp: -3.2 dB

Filter  1: ON PK Fc    33 Hz Gain +3.00 dB Q 1.17
Filter  2: ON PK Fc   177 Hz Gain -2.32 dB Q 1.06
Filter  3: ON PK Fc  1828 Hz Gain +2.98 dB Q 1.76
Filter  4: ON PK Fc   804 Hz Gain -1.59 dB Q 3.00

It looks like those are just standard filters that you could setup manually in app, especially if there is just a handful of them. If you pull up the web interface and go to the filters tab you should be able to create a new filter with type "Biquad" and then enter the frequency, gain, and Q:

 

[Spezialtrick]

m4_2x4hd.yml

This configuration uses a miniDSP 2x4HD as capture device. Rate adjust and asynchronous resampling are enabled to prevent buffer under/over runs as the 2x4HD and M4 have separate clocks and unlike an ALSA Loopback CamillaDSP has no ability to adjust the 2x4HD clock. Capture sample rate is set to 96 kHz to match the miniDSP 2x4HD sample rate. Only a 96 kHz playback sample rate configuration is provided but this can be changed to any sample rate supported by the M4 as the capture and playback devices are separate.

Hello Michael,

thank you very much for your brilliant work! I would like to use CamillaDSP on a Pi4 and my MiniDSP Flex as Capture and Playback Device, but i'm struggling with the config file. Maybe you could help me. This is my config file based on your m4_2x4hd.yml:

devices:
  adjust_period: 10
  capture:
    channels: 2
    device: hw:CARD=Flex
    format: S32LE
    type: Alsa
  capture_samplerate: 96000
  chunksize: 2048
  enable_rate_adjust: true
  enable_resampling: true
  playback:
    channels: 4
    device: hw:CARD=Flex
    format: S32LE
    type: Alsa
  queuelimit: 4
  rate_measure_interval: 1
  resampler_type: BalancedAsync
  samplerate: 96000
  silence_threshold: -100
  silence_timeout: 5
  stop_on_rate_change: false
  target_level: 2048
filters:
  volume:
    parameters:
      ramp_time: 200
    type: Volume
mixers:
  2x4:
    channels:
      in: 2
      out: 4
    mapping:
    - dest: 0
      mute: false
      sources:
      - channel: 0
        gain: 0
        inverted: false
        mute: false
    - dest: 1
      mute: false
      sources:
      - channel: 1
        gain: 0
        inverted: false
        mute: false
    - dest: 2
      mute: false
      sources:
      - channel: 0
        gain: 0
        inverted: false
        mute: false
    - dest: 3
      mute: false
      sources:
      - channel: 1
        gain: 0
        inverted: false
        mute: false
pipeline:
- name: 4x4
  type: Mixer
- channel: 0
  names:
  - volume
  type: Filter
- channel: 1
  names:
  - volume
  type: Filter
- channel: 2
  names:
  - volume
  type: Filter
- channel: 3
  names:
  - volume
  type: Filter

When i try to start CamillaDSP i get a bunch of error, but i don't know to solve them:

camilladsp@CamillaDSP:~$ /home/camilladsp/camilladsp/camilladsp -g-40 -p 1234 /home/camilladsp/camilladsp/configs/minidsp_flex.yml -v
2023-02-06 16:46:56.834351 INFO [src/bin.rs:711] CamillaDSP version 1.0.3
2023-02-06 16:46:56.834502 INFO [src/bin.rs:712] Running on linux, aarch64
2023-02-06 16:46:56.834660 DEBUG [src/bin.rs:754] Read config file Some("/home/camilladsp/camilladsp/configs/minidsp_flex.yml")
2023-02-06 16:46:56.835696 DEBUG [src/bin.rs:773] Config is valid
2023-02-06 16:46:56.835834 DEBUG [src/socketserver.rs:260] Start websocket server on 127.0.0.1:1234
2023-02-06 16:46:56.836133 DEBUG [src/bin.rs:857] Wait for config
2023-02-06 16:46:56.836247 DEBUG [src/bin.rs:890] Config ready
2023-02-06 16:46:56.836684 DEBUG [src/filters.rs:450] Build new pipeline
2023-02-06 16:46:56.836684 DEBUG [src/bin.rs:213] Using channels [true, true]
2023-02-06 16:46:56.836854 DEBUG [src/filters.rs:355] Build from config
2023-02-06 16:46:56.836876 DEBUG [src/alsadevice.rs:917] Buffer frames 4096
2023-02-06 16:46:56.837001 DEBUG [src/filters.rs:355] Build from config
2023-02-06 16:46:56.837128 DEBUG [src/filters.rs:355] Build from config
2023-02-06 16:46:56.837260 DEBUG [src/filters.rs:355] Build from config
2023-02-06 16:46:56.837344 DEBUG [src/alsadevice.rs:932] Creating resampler
2023-02-06 16:46:56.837374 DEBUG [src/processing.rs:19] build filters, waiting to start processing loop
2023-02-06 16:46:56.837458 DEBUG [src/audiodevice.rs:432] Creating asynchronous resampler with parameters: InterpolationParameters { sinc_len: 128, f_cutoff: 0.92591465, oversampling_factor: 1024, interpolation: Linear, window: Blackman2 }
2023-02-06 16:46:56.840342 DEBUG [src/alsadevice.rs:413] Playback: supported channels, min: 2, max: 2, list: [2]
2023-02-06 16:46:56.840483 DEBUG [src/alsadevice.rs:414] Playback: setting channels to 4
2023-02-06 16:46:56.840700 ERROR [src/bin.rs:344] Playback error: ALSA function 'snd_pcm_hw_params_set_channels' failed with error 'EINVAL: Invalid argument'
2023-02-06 16:46:56.840813 DEBUG [src/bin.rs:349] Error while starting, release barrier
2023-02-06 16:46:56.877402 DEBUG [src/alsadevice.rs:413] Capture: supported channels, min: 4, max: 4, list: [4]
2023-02-06 16:46:56.877539 DEBUG [src/alsadevice.rs:414] Capture: setting channels to 2
2023-02-06 16:46:56.877754 DEBUG [src/bin.rs:352] Wait for capture thread to exit..
2023-02-06 16:46:56.877777 DEBUG [src/processing.rs:21] Processing loop starts now!
2023-02-06 16:46:56.878168 DEBUG [src/bin.rs:915] Restarting with new config
2023-02-06 16:46:56.878166 ERROR [src/processing.rs:50] Message channel error: receiving on a closed channel
2023-02-06 16:46:56.878278 DEBUG [src/bin.rs:857] Wait for config
2023-02-06 16:46:56.878301 INFO [src/processing.rs:53] Playback thread has already stopped.
2023-02-06 16:46:56.878372 DEBUG [src/bin.rs:860] No config and not in wait mode, exiting!

 

[mdsimon2]

I'd actually been thinking about the pyCamillaDSP thing this weekend and how I didn't like incorporating that into my program due to the GPL license. Everything else I'm using is MIT and I wanted to keep that as the license for the entire project. Really the screen is only using a small subset of the commands offered so I decided to just call CamillaDSP directly from the C program for the handful of queries that the display needs in order to know status and levels.

Your idea of calling a C program to update the display from Python is probably sound but I don't know either language well enough to know how to integrate them like that. Perhaps a client/server model? Either way it seems like more trouble than it's worth, IMO. Remember, the pyCamillaDSP addon is just a Python interface to interact with the websocket server in CamillaDSP proper. As long as the underlying websocket interface doesn't deprecate the commands needed (ie, GetVolume, GetState, etc.) then the OLED should still be able to work even after it's updated.

I finally got the C program hopefully usable enough to checkin to Github:

https://github.com/landscapejohn/DSPOLED

All great points. Very excited to try your C program when I get home!

Michael

 

[Triliza]

It looks like those are just standard filters that you could setup manually in app, especially if there is just a handful of them. If you pull up the web interface and go to the filters tab you should be able to create a new filter with type "Biquad" and then enter the frequency, gain, and Q:

View attachment 262866

Thanks a lot. So PK means peaking it seems (I'm a noob I know). The only thing I'm not sure about now is the "Preamp: -3.2 dB". Is that the mastergain filter?

 

[LandscapeJohn]

Thanks a lot. So PK means peaking it seems (I'm a noob I know). The only thing I'm not sure about now is the "Preamp: -3.2 dB". Is that the mastergain filter?

View attachment 262890

Exactly. Basically since your filters are adding gain you want to reduce the overall gain so that in the end your peaks aren't exceeding the maximum level and clipping.

 

[Nisse10000]

Hello Michael,

thank you very much for your brilliant work! I would like to use CamillaDSP on a Pi4 and my MiniDSP Flex as Capture and Playback Device, but i'm struggling with the config file. Maybe you could help me. This is my config file based on your m4_2x4hd.yml:

devices:
  adjust_period: 10
  capture:
    channels: 2
    device: hw:CARD=Flex
    format: S32LE
    type: Alsa
  capture_samplerate: 96000
  chunksize: 2048
  enable_rate_adjust: true
  enable_resampling: true
  playback:
    channels: 4
    device: hw:CARD=Flex
    format: S32LE
    type: Alsa
  queuelimit: 4
  rate_measure_interval: 1
  resampler_type: BalancedAsync
  samplerate: 96000
  silence_threshold: -100
  silence_timeout: 5
  stop_on_rate_change: false
  target_level: 2048
filters:
  volume:
    parameters:
      ramp_time: 200
    type: Volume
mixers:
  2x4:
    channels:
      in: 2
      out: 4
    mapping:
    - dest: 0
      mute: false
      sources:
      - channel: 0
        gain: 0
        inverted: false
        mute: false
    - dest: 1
      mute: false
      sources:
      - channel: 1
        gain: 0
        inverted: false
        mute: false
    - dest: 2
      mute: false
      sources:
      - channel: 0
        gain: 0
        inverted: false
        mute: false
    - dest: 3
      mute: false
      sources:
      - channel: 1
        gain: 0
        inverted: false
        mute: false
pipeline:
- name: 4x4
  type: Mixer
- channel: 0
  names:
  - volume
  type: Filter
- channel: 1
  names:
  - volume
  type: Filter
- channel: 2
  names:
  - volume
  type: Filter
- channel: 3
  names:
  - volume
  type: Filter

When i try to start CamillaDSP i get a bunch of error, but i don't know to solve them:

camilladsp@CamillaDSP:~$ /home/camilladsp/camilladsp/camilladsp -g-40 -p 1234 /home/camilladsp/camilladsp/configs/minidsp_flex.yml -v
2023-02-06 16:46:56.834351 INFO [src/bin.rs:711] CamillaDSP version 1.0.3
2023-02-06 16:46:56.834502 INFO [src/bin.rs:712] Running on linux, aarch64
2023-02-06 16:46:56.834660 DEBUG [src/bin.rs:754] Read config file Some("/home/camilladsp/camilladsp/configs/minidsp_flex.yml")
2023-02-06 16:46:56.835696 DEBUG [src/bin.rs:773] Config is valid
2023-02-06 16:46:56.835834 DEBUG [src/socketserver.rs:260] Start websocket server on 127.0.0.1:1234
2023-02-06 16:46:56.836133 DEBUG [src/bin.rs:857] Wait for config
2023-02-06 16:46:56.836247 DEBUG [src/bin.rs:890] Config ready
2023-02-06 16:46:56.836684 DEBUG [src/filters.rs:450] Build new pipeline
2023-02-06 16:46:56.836684 DEBUG [src/bin.rs:213] Using channels [true, true]
2023-02-06 16:46:56.836854 DEBUG [src/filters.rs:355] Build from config
2023-02-06 16:46:56.836876 DEBUG [src/alsadevice.rs:917] Buffer frames 4096
2023-02-06 16:46:56.837001 DEBUG [src/filters.rs:355] Build from config
2023-02-06 16:46:56.837128 DEBUG [src/filters.rs:355] Build from config
2023-02-06 16:46:56.837260 DEBUG [src/filters.rs:355] Build from config
2023-02-06 16:46:56.837344 DEBUG [src/alsadevice.rs:932] Creating resampler
2023-02-06 16:46:56.837374 DEBUG [src/processing.rs:19] build filters, waiting to start processing loop
2023-02-06 16:46:56.837458 DEBUG [src/audiodevice.rs:432] Creating asynchronous resampler with parameters: InterpolationParameters { sinc_len: 128, f_cutoff: 0.92591465, oversampling_factor: 1024, interpolation: Linear, window: Blackman2 }
2023-02-06 16:46:56.840342 DEBUG [src/alsadevice.rs:413] Playback: supported channels, min: 2, max: 2, list: [2]
2023-02-06 16:46:56.840483 DEBUG [src/alsadevice.rs:414] Playback: setting channels to 4
2023-02-06 16:46:56.840700 ERROR [src/bin.rs:344] Playback error: ALSA function 'snd_pcm_hw_params_set_channels' failed with error 'EINVAL: Invalid argument'
2023-02-06 16:46:56.840813 DEBUG [src/bin.rs:349] Error while starting, release barrier
2023-02-06 16:46:56.877402 DEBUG [src/alsadevice.rs:413] Capture: supported channels, min: 4, max: 4, list: [4]
2023-02-06 16:46:56.877539 DEBUG [src/alsadevice.rs:414] Capture: setting channels to 2
2023-02-06 16:46:56.877754 DEBUG [src/bin.rs:352] Wait for capture thread to exit..
2023-02-06 16:46:56.877777 DEBUG [src/processing.rs:21] Processing loop starts now!
2023-02-06 16:46:56.878168 DEBUG [src/bin.rs:915] Restarting with new config
2023-02-06 16:46:56.878166 ERROR [src/processing.rs:50] Message channel error: receiving on a closed channel
2023-02-06 16:46:56.878278 DEBUG [src/bin.rs:857] Wait for config
2023-02-06 16:46:56.878301 INFO [src/processing.rs:53] Playback thread has already stopped.
2023-02-06 16:46:56.878372 DEBUG [src/bin.rs:860] No config and not in wait mode, exiting!

The alsa device your are using seems to be 2 channel only, that’s the error camilladsp is reporting. Check with aplay -l and aplay -r

 

[mdsimon2]

The alsa device your are using seems to be 2 channel only, that’s the error camilladsp is reporting. Check with aplay -l and aplay -r

Yes, exactly.

@Spezialtrick what are you trying to do with the Flex? Using it as both a capture and playback device does not make much sense to me.

The two use cases I can think of for a Flex with CamillaDSP are:

1) Use it as a CamillaDSP capture device so that it acts as a front end ASRC / source selector / volume control and use CamillaDSP to route the output to another 4+ channel DAC

2) Use it as a CamillaDSP playback device with the RPi4 as a source via USB, this would allow you to implement global correction in CamillaDSP (for example linearizing crossover phase with a FIR filter in CamillaDSP) upstream of the Flex

Michael

 

[Spezialtrick]

@Spezialtrick what are you trying to do with the Flex? Using it as both a capture and playback device does not make much sense to me.

The two use cases I can think of for a Flex with CamillaDSP are:

1) Use it as a CamillaDSP capture device so that it acts as a front end ASRC / source selector / volume control and use CamillaDSP to route the output to another 4+ channel DAC

2) Use it as a CamillaDSP playback device with the RPi4 as a source via USB, this would allow you to implement global correction in CamillaDSP (for example linearizing crossover phase with a FIR filter in CamillaDSP) upstream of the Flex

Michael

I’m using the Flex RCA. I connected my turntable to the analog inputs and a stereo poweramp and one active subwoofer to the analog outputs. Pi4 is connected via USB.

Now I like to use CamillaDSP for correction with FIR-Filters of music playing via turntable or via Pi4:

1) Pi4 —> CamillaDSP —> Flex (Analog Out)—> PowerAmp/Sub

2) Turntable—> Flex (Analog In) —> Pi4 —> CamillaDSP—> Flex (Analog Out) —> PowerAmp/Sub

 

[mdsimon2]

I’m using the Flex RCA. I connected my turntable to the analog inputs and a stereo poweramp and one active subwoofer to the analog outputs. Pi4 is connected via USB.

Now I like to use CamillaDSP for correction with FIR-Filters of music playing via turntable or via Pi4:

1) Pi4 —> CamillaDSP —> Flex (Analog Out)—> PowerAmp/Sub

2) Turntable—> Flex (Analog In) —> Pi4 —> CamillaDSP—> Flex (Analog Out) —> PowerAmp/Sub

Hmm...I don't think that will work.

The Flex is a little weird in that it presents itself as a 2 channel playback device and a 4 channel capture device to the USB host. So you can definitely apply FIR filters in the first case but I don't see how it will work in the second. When you use the Flex as a capture device it will already have completed any processing applied in the Flex so I don't see how you can re-route that through CamillaDSP and then back out to the Flex without applying the processing twice.

As a work around you could get a separate USB or HAT ADC and use that to capture the turntable. You could could switch between the ADC as a capture device and an ALSA Loopback as a capture device in CamillaDSP. Alternatively if you run LMS and squeezelite on the RPi4 you could use the Wave Input plugin in LMS to direct the ADC capture to squeezelite, this would avoid the need to change CamillaDSP configurations.

Michael

 

[Spezialtrick]

Hmm...I don't think that will work.

The Flex is a little weird in that it presents itself as a 2 channel playback device and a 4 channel capture device to the USB host. So you can definitely apply FIR filters in the first case but I don't see how it will work in the second. When you use the Flex as a capture device it will already have completed any processing applied in the Flex so I don't see how you can re-route that through CamillaDSP and then back out to the Flex without applying the processing twice.

As a work around you could get a separate USB or HAT ADC and use that to capture the turntable. You could could switch between the ADC as a capture device and an ALSA Loopback as a capture device in CamillaDSP. Alternatively if you run LMS and squeezelite on the RPi4 you could use the Wave Input plugin in LMS to direct the ADC capture to squeezelite, this would avoid the need to change CamillaDSP configurations.

Michael

Michael

Ok let’s forget about the turntable. But can you recommend a USB or HAT ADC?

How do i need to change the config, to use the Flex as DAC and just use the Pi4 Streamer with CamillaDSP?

 

[mdsimon2]

Ok let’s forget about the turntable. But can you recommend a USB or HAT ADC?

How do i need to change the config, to use the Flex as DAC and just use the Pi4 Streamer with CamillaDSP?

You only need the ADC if you are using a turntable . I use a Hifiberry DAC+ ADC Pro HAT for my turntable it works well. I've also used a Cosmos ADC and a MOTU M4. Any pro audio ADC (Focusrite, MOTU, RME, etc) is good enough for a turntable.

If you are just using the Pi as a streamer there is no need to change the CamillaDSP configuration as you will only be using an ALSA Loopback as the CamillaDSP capture device. If you go the LMS / squeezelite route you also will not need to change the CamillaDSP configuration.

Michael

 

[Spezialtrick]

If you are just using the Pi as a streamer there is no need to change the CamillaDSP configuration as you will only be using an ALSA Loopback as the CamillaDSP capture device. If you go the LMS / squeezelite route you also will not need to change the CamillaDSP configuration.

Ok. But which config file shall i use for step 9 and 10 of your tutorial.

Hifiberry DAC+ ADC Pro HAT

I'll give it a try.

 

[Spezialtrick]

If you are just using the Pi as a streamer there is no need to change the CamillaDSP configuration as you will only be using an ALSA Loopback as the CamillaDSP capture device.

Could you post a link to the default CamillaDSP config file?