Pi4 + CamillaDSP + Audio Interface (Motu M4) = Phenomal DSP streamer

[dorirod]

Very interesting thread, thank you!

I am interested in doing DSP correction on my 2.1 sustem currently feeding through various options but output from TV to optical out to DAC. Basically wondering if an alternative to minidsp's OpenDRC-DI could be built with Pi4 + CamillaDSP. Would need to feed it spdif and get optical/usb out (no need for volume control as I would use the DAC for that). I was looking at hifiberry to see if they already had something like that. Any ideas as to how this can most easily be accomplished?

Thank you for any insight!

 

[simbloke]

Very interesting thread, thank you!

I am interested in doing DSP correction on my 2.1 sustem currently feeding through various options but output from TV to optical out to DAC. Basically wondering if an alternative to minidsp's OpenDRC-DI could be built with Pi4 + CamillaDSP. Would need to feed it spdif and get optical/usb out (no need for volume control as I would use the DAC for that). I was looking at hifiberry to see if they already had something like that. Any ideas as to how this can most easily be accomplished?

Thank you for any insight!

That's the kind of thing I want to do. I have a mini PC for playing music that does DSP, the problem is the TV goes straight to the DAC and I have no optical input on the PC.

Doing some reading on CamillaDSP it seem like it should be possible by switching the config and getting it to read data from a real audio interface, rather than the loopback interface that MPD would be using.

No idea if any of the pre-packaged music player distro's have considered this use case though.

 

[dorirod]

@simbloke it appears that https://www.hifiberry.com/docs/data-sheets/datasheet-dac-dsp/ might be something that works for this. I'm trying to get more details from Hifiberry. If anyone has used this I'd be interested to know how well it works.

 

[simbloke]

It's interesting, but since the Pi or a PC can do DSP I wonder what they're aiming at.

 

[mdsimon2]

As noted above HifiBerry has some interesting digital input / output HATs that should work well with CamillaDSP, especially when coupled with a multichannel USB DAC. The DIGI+ I/O should work well for applications where the input sample rate is fixed (imagine out of a TV this is fixed at 48 kHz). The DAC+ DSP gives the flexibility of being able to ASRC the input to the CamillaDSP sample rate.

I haven't used the HifiBerry HATs myself but I have used a few other devices that have TOSLINK inputs (SHD Studio, 2X4HD / DDRC-24, MOTU Ultralite Mk5) and they all work well with CamillaDSP so I imagine HifiBerry HATs should as well.

I also ran across the project linked below on diyaudio that provides somewhat similar functionality to the HifiBerry HATs.

https://www.diyaudio.com/forums/pc-...berry-pi-hat-spdif-i2s-communication-dsp.html

In terms of processing power a RPi4 + CamillaDSP will blow away an OpenDRC-DI. For example I was easily able to run 16384 x 8 = 131072 taps at 96 kHz using a RPi4 + CamillaDSP.

Michael

 

[dorirod]

It's interesting, but since the Pi or a PC can do DSP I wonder what they're aiming at.

It just makes it easier, basically if you want something that more or less works "out of the box" (still a more complicated box than OpenDRC-DI and not as flexible as CamillaDAP I would imagine). I'm still not sure how much fiddling you'd have to do even with you went with the Hifiberry products.

 

[mdsimon2]

Just bought a HifiBerry DIGI+ I/O and a DAC+ DSP to play around with. I’ll let you know how it goes and if there are any major issues.

Michael

 

[mdsimon2]

I pushed the code:

https://github.com/daverz/camilla-remote-control

No documentation yet, and as you can see I'm not big on commenting my code. But one thing to explain: I wanted everything in one file, so all the Camilla configs needed are built as Python objects when the script is started. So there are no YAML files.

Note that if you don't have the FLIRC USB infrared receiver, you can just hook up a keyboard to the Pi.

Also, I started on a balance control, but there's no display for that yet, and I bound left and right balance directly to the Left and Right keys. The intent is to eventually have this in a menu.

How quick is your volume control with FLIRC IR receiver and remote?

I had been playing with minidsp-rs and already had a 4x20 LCD connected to the Pi so I figured I would try it out with CamillaDSP. It works OK but I really miss a more adaptive volume control (i.e. long presses result in larger increase/decrease, faster presses result in faster increase/decrease).

I am very new to python and I am using events get_key() in a while loop to recognize button presses which I assume is not the fastest or most elegant way.

Michael

 

[Daverz]

How quick is your volume control with FLIRC IR receiver and remote?

I had been playing with minidsp-rs and already had a 4x20 LCD connected to the Pi so I figured I would try it out with CamillaDSP. It works OK but I really miss a more adaptive volume control (i.e. long presses result in larger increase/decrease, faster presses result in faster increase/decrease).

I am very new to python and I am using events get_key() in a while loop to recognize button presses which I assume is not the fastest or most elegant way.

I'm using the Gtk "key-press-event". This event is connected to a Python callback. This does give the "faster on hold" behavior, and it's quite responsive:

"The signal emission will reoccur at the key-repeat rate when the key is kept pressed."

https://lazka.github.io/pgi-docs/Gtk-3.0/classes/Widget.html#Gtk.Widget.signals.key_press_event

I think most GUI toolkits will provide a similar event, along with an event loop to handle it.

One path I didn't take was modifying the existing CamillaGUI to create my own layout:

https://github.com/HEnquist/camillagui

You could then run this on the Pi in a browser in kiosk mode. A google search brings up pages like this:

https://die-antwort.eu/techblog/2017-12-setup-raspberry-pi-for-kiosk-mode/

BTW, thanks for the reference to minidsp-rs:

https://github.com/mrene/minidsp-rs

Might be useful if I use my nanoDigi for another project.

 

[mdsimon2]

I'm using the Gtk "key-press-event". This event is connected to a Python callback. This does give the "faster on hold" behavior, and it's quite responsive:

"The signal emission will reoccur at the key-repeat rate when the key is kept pressed."

https://lazka.github.io/pgi-docs/Gtk-3.0/classes/Widget.html#Gtk.Widget.signals.key_press_event

I think most GUI toolkits will provide a similar event, along with an event loop to handle it.

One path I didn't take was modifying the existing CamillaGUI to create my own layout:

https://github.com/HEnquist/camillagui

You could then run this on the Pi in a browser in kiosk mode. A google search brings up pages like this:

https://die-antwort.eu/techblog/2017-12-setup-raspberry-pi-for-kiosk-mode/

BTW, thanks for the reference to minidsp-rs:

https://github.com/mrene/minidsp-rs

Might be useful if I use my nanoDigi for another project.

Thanks for the info again. I ended up switching to the method described in this thread below.

http://moodeaudio.org/forum/printthread.php?tid=1529

Have a few more options to check out but this works well, response time is fast and well behaved.

minidsp-rs seems to be really nice and it is very easy to integrate a display with it which was one of my biggest pet peeves regarding the non-SHD miniDSP products.

Michael

 

[mdsimon2]

OK, now have this working pretty nicely. Pretty darn easy to add a display and volume indication with CamillaDSP. See below for video.

https://drive.google.com/file/d/1o5tFqQW67TCIX2KzQuQtjtPgCRyuMRRi/view?usp=sharing

And a quick photo

Michael

 

[mdsimon2]

Just bought a HifiBerry DIGI+ I/O and a DAC+ DSP to play around with. I’ll let you know how it goes and if there are any major issues.

Michael

Got a few minutes to play with these this weekend and it was mostly as expected but there were a few quirks.

The DIGI+ I/O worked exactly as expected, as long as your CamillaDSP capture rate is set to the rate of the source this works fine. So things with fixed rates like AppleTVs, many TVs or anything with an ASRC (OpenDRC-DI, nanoDIGI, etc) work well with this and it is a cheap way to add a SPDIF/TOSLINK input to something like a MOTU M4 if using CamillaDSP on a RPi.

The DAC+ DSP is a lot more capable but does have some quirks. It does nothing out of the box unless you load a DSP profile to it. This requires you to install HifiBerry's dsptoolkit which unfortunately does not work on Ubuntu Server 21.04 as it uses RPi.GPIO which was eliminated as of the 5.11 kernel. That being said I do have a RPi3 running Raspberry Pi OS and it worked fine once I installed dsptoolkit and followed the instructions in the link below.

https://www.hifiberry.com/docs/software/using-the-dac-dsp-to-record-audio-from-s-pdif/

I was able to use a variety of devices with different input sample rates without issue (also no pops or clicks when changing sample rates). With this HAT you are certainly in an interesting situation as it also DSP capability but to be honest HifiBerry documentation is pretty bad and this will have much less power than a RPi 3/4 running CamillaDSP so I would personally only use this for ASRC and use CamillaDSP for everything else.

I also found the thread below useful when setting it up.

https://support.hifiberry.com/hc/en-us/community/posts/360008515418-DAC-DSP-Toslink-input-to-RPI

Michael

 

[dorirod]

FYI for anyone like me that might have to end up searching for it, ASRC is Asynchronous Sample Rate Converter.

 

[dorirod]

Got a few minutes to play with these this weekend and it was mostly as expected but there were a few quirks.

The DIGI+ I/O worked exactly as expected, as long as your CamillaDSP capture rate is set to the rate of the source this works fine. So things with fixed rates like AppleTVs, many TVs or anything with an ASRC (OpenDRC-DI, nanoDIGI, etc) work well with this and it is a cheap way to add a SPDIF/TOSLINK input to something like a MOTU M4 if using CamillaDSP on a RPi.

The DAC+ DSP is a lot more capable but does have some quirks. It does nothing out of the box unless you load a DSP profile to it. This requires you to install HifiBerry's dsptoolkit which unfortunately does not work on Ubuntu Server 21.04 as it uses RPi.GPIO which was eliminated as of the 5.11 kernel. That being said I do have a RPi3 running Raspberry Pi OS and it worked fine once I installed dsptoolkit and followed the instructions in the link below.

https://www.hifiberry.com/docs/software/using-the-dac-dsp-to-record-audio-from-s-pdif/

I was able to use a variety of devices with different input sample rates without issue (also no pops or clicks when changing sample rates). With this HAT you are certainly in an interesting situation as it also DSP capability but to be honest HifiBerry documentation is pretty bad and this will have much less power than a RPi 3/4 running CamillaDSP so I would personally only use this for ASRC and use CamillaDSP for everything else.

I also found the thread below useful when setting it up.

https://support.hifiberry.com/hc/en-us/community/posts/360008515418-DAC-DSP-Toslink-input-to-RPI

Michael

Hello Michael, could you please share the CamillaDSP configs you are using for the DIGI+ I/O and DAC+ DSP? I'm still unclear on how things get specified (not familiar with any of these components, so just playing around with them for now).

Thank you,
Dori

 

[Honken]

Thanks for creating this thread, it's what finally pushed me to check out Camilla.

I recently started toying with using rePhase for taming the phase of my filters but I wasn't satisfied with the sound my old DSP solution produced when applying the resulting convolution filters. It ringed like I was hitting my speakers with a tuning fork, and after testing various settings to no avail I realized that it was probably the dsp engine itself that produced the ringing. This ringing wasn't there with my old IIR filters.

So after reading about Camilla here I decided to try it out. The set up was quick and painless, I had a lift 'n shift going in a few minutes. I personally don't like the YAML format but the configuration here was clear, nice.

With Camilla the ringing seems to be gone. Unfortunately, I'll have to admit that I can't really hear any difference compared to my old IIR set up. Oh well, no point in going back now, using rePhase to create the filters is quite nice and intuitive so I'll just keep using this setup.

What I haven't done yet is to use the hwparams hook in ALSA to respond to frequency changes but that looks fairly straight forward to do, just a bit of a hassle.

@HenrikEnquist Nice job with the software. Do you have any future plans to extend it so that it can listen on multiple capture devices? I have multiple programs that I'd like to apply DSP to, but they are unfortunately bad at releasing the device once they are done playing. Having multiple inputs in Camilla and choosing which one to play from via the web socket (or perhaps automatically based on silence detection) would fix that issue rather nicely I think.

 

[mdsimon2]

Hello Michael, could you please share the CamillaDSP configs you are using for the DIGI+ I/O and DAC+ DSP? I'm still unclear on how things get specified (not familiar with any of these components, so just playing around with them for now).

Thank you,
Dori

Sure, see below for a simple configuration with the MOTU M4. The device name "sndrpihifiberry" is the same for the DIGI+ I/O and the DAC+ DSP but the dtoverlay is different. For the DIGI+ you want to add "dtoverlay=hifiberry-digi" to /boot/config.txt (/boot/firmware/config.txt if you are using Ubuntu Server) and for the DAC+ DSP you want to add "dtoverlay=hifiberry-dacplusdsp".

I currently have resampling enabled in CamillaDSP but it does seem to work without it as well but I am not sure if you will run in to issues over long listening periods without it.

---
devices:
  samplerate: 96000
  chunksize: 2048     
#  enable_rate_adjust: true
  enable_resampling: true
  resampler_type: BalancedAsync
#  silence_threshold: -80
#  silence_timeout: 5
  capture:
    type: Alsa
    channels: 2
    device: "hw:sndrpihifiberry"
    format: S24LE
  playback:
    type: Alsa
    channels: 4
    device: "hw:M4"
    format: S32LE

mixers:
  mixer:
    channels:
      in: 2
      out: 4
    mapping:
      - dest: 0
        sources:
          - channel: 0
            gain: 0
            inverted: false
      - dest: 1
        sources:
          - channel: 1
            gain: 0
            inverted: false
      - dest: 2
        sources:
          - channel: 0
            gain: 0
            inverted: false
      - dest: 3
        sources:
          - channel: 1
            gain: 0
            inverted: false

filters:
  volume:
    type: Volume
    parameters:
      ramp_time: 200

pipeline:
  - type: Mixer
    name: mixer
  - type: Filter
    channel: 0
    names:
      - volume
  - type: Filter
    channel: 1
    names:
      - volume
  - type: Filter
    channel: 2
    names:
      - volume
  - type: Filter
    channel: 3
    names:
      - volume

Just as a FYI you can see what sample rates are available by running aplay -v -D hw:device /dev/zero --dump-hw-params, so aplay -v -D hw:sndrpihifiberry /dev/zero --dump-hw-params gives:

aplay -v -D hw:sndrpihifiberry /dev/zero --dump-hw-params
Playing raw data '/dev/zero' : Unsigned 8 bit, Rate 8000 Hz, Mono
HW Params of device "hw:sndrpihifiberry":
--------------------
ACCESS:  MMAP_INTERLEAVED RW_INTERLEAVED
FORMAT:  S16_LE S24_LE
SUBFORMAT:  STD
SAMPLE_BITS: [16 32]
FRAME_BITS: [32 64]
CHANNELS: 2
RATE: [32000 192000]
PERIOD_TIME: (166 2048000]
PERIOD_SIZE: [32 65536]
PERIOD_BYTES: [256 524288]
PERIODS: [2 4096]
BUFFER_TIME: (333 4096000]
BUFFER_SIZE: [64 131072]
BUFFER_BYTES: [256 524288]
TICK_TIME: ALL
--------------------
aplay: set_params:1339: Sample format non available
Available formats:
- S16_LE
- S24_LE

And aplay -v -D hw:M4 /dev/zero --dump-hw-params gives:

aplay -v -D hw:M4 /dev/zero --dump-hw-params
Playing raw data '/dev/zero' : Unsigned 8 bit, Rate 8000 Hz, Mono
HW Params of device "hw:M4":
--------------------
ACCESS:  MMAP_INTERLEAVED RW_INTERLEAVED
FORMAT:  S32_LE
SUBFORMAT:  STD
SAMPLE_BITS: 32
FRAME_BITS: 128
CHANNELS: 4
RATE: [44100 192000]
PERIOD_TIME: [125 743039)
PERIOD_SIZE: [6 32768]
PERIOD_BYTES: [96 524288]
PERIODS: [2 1024]
BUFFER_TIME: (62 1486078)
BUFFER_SIZE: [12 65536]
BUFFER_BYTES: [192 1048576]
TICK_TIME: ALL
--------------------
aplay: set_params:1339: Sample format non available
Available formats:
- S32_LE

Michael

 

[dorirod]

Sure, see below for a simple configuration with the MOTU M4. The device name "sndrpihifiberry" is the same for the DIGI+ I/O and the DAC+ DSP but the dtoverlay is different. For the DIGI+ you want to add "dtoverlay=hifiberry-digi" to /boot/config.txt (/boot/firmware/config.txt if you are using Ubuntu Server) and for the DAC+ DSP you want to add "dtoverlay=hifiberry-dacplusdsp".

I currently have resampling enabled in CamillaDSP but it does seem to work without it as well but I am not sure if you will run in to issues over long listening periods without it.

---
devices:
  samplerate: 96000
  chunksize: 2048    
#  enable_rate_adjust: true
  enable_resampling: true
  resampler_type: BalancedAsync
#  silence_threshold: -80
#  silence_timeout: 5
  capture:
    type: Alsa
    channels: 2
    device: "hw:sndrpihifiberry"
    format: S24LE
  playback:
    type: Alsa
    channels: 4
    device: "hw:M4"
    format: S32LE

mixers:
  mixer:
    channels:
      in: 2
      out: 4
    mapping:
      - dest: 0
        sources:
          - channel: 0
            gain: 0
            inverted: false
      - dest: 1
        sources:
          - channel: 1
            gain: 0
            inverted: false
      - dest: 2
        sources:
          - channel: 0
            gain: 0
            inverted: false
      - dest: 3
        sources:
          - channel: 1
            gain: 0
            inverted: false

filters:
  volume:
    type: Volume
    parameters:
      ramp_time: 200

pipeline:
  - type: Mixer
    name: mixer
  - type: Filter
    channel: 0
    names:
      - volume
  - type: Filter
    channel: 1
    names:
      - volume
  - type: Filter
    channel: 2
    names:
      - volume
  - type: Filter
    channel: 3
    names:
      - volume

Just as a FYI you can see what sample rates are available by running aplay -v -D hw:device /dev/zero --dump-hw-params, so aplay -v -D hw:sndrpihifiberry /dev/zero --dump-hw-params gives:

aplay -v -D hw:sndrpihifiberry /dev/zero --dump-hw-params
Playing raw data '/dev/zero' : Unsigned 8 bit, Rate 8000 Hz, Mono
HW Params of device "hw:sndrpihifiberry":
--------------------
ACCESS:  MMAP_INTERLEAVED RW_INTERLEAVED
FORMAT:  S16_LE S24_LE
SUBFORMAT:  STD
SAMPLE_BITS: [16 32]
FRAME_BITS: [32 64]
CHANNELS: 2
RATE: [32000 192000]
PERIOD_TIME: (166 2048000]
PERIOD_SIZE: [32 65536]
PERIOD_BYTES: [256 524288]
PERIODS: [2 4096]
BUFFER_TIME: (333 4096000]
BUFFER_SIZE: [64 131072]
BUFFER_BYTES: [256 524288]
TICK_TIME: ALL
--------------------
aplay: set_params:1339: Sample format non available
Available formats:
- S16_LE
- S24_LE

And aplay -v -D hw:M4 /dev/zero --dump-hw-params gives:

aplay -v -D hw:M4 /dev/zero --dump-hw-params
Playing raw data '/dev/zero' : Unsigned 8 bit, Rate 8000 Hz, Mono
HW Params of device "hw:M4":
--------------------
ACCESS:  MMAP_INTERLEAVED RW_INTERLEAVED
FORMAT:  S32_LE
SUBFORMAT:  STD
SAMPLE_BITS: 32
FRAME_BITS: 128
CHANNELS: 4
RATE: [44100 192000]
PERIOD_TIME: [125 743039)
PERIOD_SIZE: [6 32768]
PERIOD_BYTES: [96 524288]
PERIODS: [2 1024]
BUFFER_TIME: (62 1486078)
BUFFER_SIZE: [12 65536]
BUFFER_BYTES: [192 1048576]
TICK_TIME: ALL
--------------------
aplay: set_params:1339: Sample format non available
Available formats:
- S32_LE

Michael

Awesome thanks for the help!

 

[HenrikEnquist]

@HenrikEnquist Nice job with the software. Do you have any future plans to extend it so that it can listen on multiple capture devices? I have multiple programs that I'd like to apply DSP to, but they are unfortunately bad at releasing the device once they are done playing. Having multiple inputs in Camilla and choosing which one to play from via the web socket (or perhaps automatically based on silence detection) would fix that issue rather nicely I think.

Thanks! I haven't considered multiple capture devices. A very quick estimate is that it would be quite problematic to add. Soo many potential problems with slight sample rate differences and what not. But you could likely make something usable by using several different Loopbacks, one for each program (the Loopback creates 8 subdevices as default). Then you make separate config files, one per program, and use websocket commands for switching between them. You could use the Paused state of CamillaDSP to know that the signal is silent so that it's time to switch. But then you need some other way of figuring out which config to switch to.

 

[dorirod]

Thanks! I haven't considered multiple capture devices. A very quick estimate is that it would be quite problematic to add. Soo many potential problems with slight sample rate differences and what not. But you could likely make something usable by using several different Loopbacks, one for each program (the Loopback creates 8 subdevices as default). Then you make separate config files, one per program, and use websocket commands for switching between them. You could use the Paused state of CamillaDSP to know that the signal is silent so that it's time to switch. But then you need some other way of figuring out which config to switch to.

@HenrikEnquist big thanks from me as well, and especially for being on the forums and providing support too

Is it possible to run different instances of CamillaDSP for different inputs/outputs (assuming they don't conflict)? Not quite the same use case scenario that @Honken mentions, but I'm thinking I might need to have something like that. I wonder what the limiting resources would be CPU, RAM?

 

[HenrikEnquist]

Is it possible to run different instances of CamillaDSP for different inputs/outputs (assuming they don't conflict)? Not quite the same use case scenario that [USER=13997]@Honken mentions, but I'm thinking I might need to have something like that. I wonder what the limiting resources would be CPU, RAM?

That should work just fine! As long as the processes don't compete for exclusive access to either the capture or playback device, they won't affect each other. Just give each one its own websocket port number (if you use that). The CPU will determine the limit, it doesn't use much RAM.