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

[dorirod]

One more thing, my current biggest annoyance with this setup is the delay. It's not a problem if I'm just listening to music, but if I'm watching video the sound is delayed from the video to where it's annoying to watch anything, estimate or feels like 0.2-0.4s delay. I don't know if there is a way to prioritize the camilladsp processing to reduce that. If anyone knows how to fix this please let me know as it's driving me crazy. On the plus side, since I have multiple inputs to the EX5 I can switch to digital input instead of USB and enjoy the synced sound (minus DSP though).

 

[HenrikEnquist]

@dorirod can you post your camilladsp config? And if you use FIR, attach an impulse response as well.

 

[dorirod]

Thank you for the reply @HenrikEnquist !

Most of the time I get 44.1KHz as the source sample rate but sometimes it's 48KHz (always through S/PDIF from the TV), not sure if resampling is doing it. I wish I could avoid it. I am using PEQ from REW, and I could probably remove some of the ones with very high Q as I doubt they're doing much, but this is the filter set that REW spit out for me using MMM.

I am using a Pi4 btw.

Thank you,
Dori

---
devices:
  samplerate: 48000
  chunksize: 2048
  enable_rate_adjust: true
  resampler_type: BalancedAsync
  capture:
    type: Alsa
    channels: 2
    device: "hw:CARD=sndrpihifiberry,DEV=0"
    format: S32LE
  playback:
    type: Alsa
    channels: 2
    device: "hw:CARD=EX5,DEV=0"
    format: S32LE
filters:
  peqgain:
    type: Gain
    parameters:
      gain: -3.0
      inverted: false
  band_01:
    type: Biquad
    parameters:
      type: Peaking
      freq: 52.6
      q: 6.36
      gain: -15.0
  band_02:
    type: Biquad
    parameters:
      type: Peaking
      freq: 70.0
      q: 5.000000
      gain: 2.200000
  band_03:
    type: Biquad
    parameters:
      type: Peaking
      freq: 140
      q: 26.790000
      gain: -3.300000
  band_04:
    type: Biquad
    parameters:
      type: Peaking
      freq: 460
      q: 2.000000
      gain: 5.510000
  band_05:
    type: Biquad
    parameters:
      type: Peaking
      freq: 540
      q: 7.700000
      gain: -7.500000
  band_06:
    type: Biquad
    parameters:
      type: Peaking
      freq: 565
      q: 6.250000
      gain: 3.900000
  band_07:
    type: Biquad
    parameters:
      type: Peaking
      freq: 1771
      q: 5.240000
      gain: -2.600000
  band_08:
    type: Biquad
    parameters:
      type: Peaking
      freq: 7957
      q: 1.160000
      gain: -2.200000
mixers:
  stereo:
    channels:
      in: 2
      out: 2
    mapping:
    - dest: 0
      sources:
      - channel: 0
        gain: 0
        inverted: false
    - dest: 1
      sources:
      - channel: 1
        gain: 0
        inverted: false
pipeline:
- type: Mixer
  name: stereo
- type: Filter
  channel: 0
  names:
  - peqgain
  - band_01
  - band_02
  - band_03
  - band_04
  - band_05
  - band_06
  - band_07
  - band_08
- type: Filter
  channel: 1
  names:
  - peqgain
  - band_01
  - band_02
  - band_03
  - band_04
  - band_05
  - band_06
  - band_07
  - band_08
...

 

[mdsimon2]

One more thing, my current biggest annoyance with this setup is the delay. It's not a problem if I'm just listening to music, but if I'm watching video the sound is delayed from the video to where it's annoying to watch anything, estimate or feels like 0.2-0.4s delay. I don't know if there is a way to prioritize the camilladsp processing to reduce that. If anyone knows how to fix this please let me know as it's driving me crazy. On the plus side, since I have multiple inputs to the EX5 I can switch to digital input instead of USB and enjoy the synced sound (minus DSP though).

Hmm…I did not test audio / video latency with the DAC+DSP. I am away from home for the next week but will measure the latency when I get back.

Michael

 

[HenrikEnquist]

@dorirod that config looks alright already, it shouldn't give a large delay. Can you try with alsaloop instead of camilladsp? http://manpages.ubuntu.com/manpages/bionic/man1/alsaloop.1.html

 

[dorirod]

@dorirod that config looks alright already, it shouldn't give a large delay. Can you try with alsaloop instead of camilladsp? http://manpages.ubuntu.com/manpages/bionic/man1/alsaloop.1.html

@HenrikEnquist I tried with the following:
$ alsaloop -C "hw:CARD=sndrpihifiberry,DEV=0" -P "hw:CARD=EX5,DEV=0" -c 2 -f S32_LE -r 44100

There is still a delay, but it's much less, barely noticeable, maybe 0.1-0.2 s

I'm not sure if I'm estimating correctly, definitely feels a lot less with alsaloop. I tried looking at this video and with alsaloop I would estimate that I hear the sound when the moving line is 1/3 of the way into the colored red bar, whereas with camilladsp I would say it's over 1/2 to 2/3 of the way into the colored bar.

 

[HenrikEnquist]

Ok that's only 100 - 150ms. Let's try to tweak things a bit. Start by using a smaller chunksize, you can try 1024 to start with. Then also set "target_level". It defaults to the same value as chunksize, try setting it to 512 or 256 to begin with.
You can play with reducing both further.

 

[dorirod]

@HenrikEnquist it's certainly helped, thank you! Now I think I need to figure out how much latency the Topping EX5 DAC is adding into the mix.

By the way, at what point do those chunksize and target_level start getting into dangerously low territory, and what will happen? Is it pretty much skips or pops, or could it result in something less audible?

Also, do you know if there is any way to prioritize the camilladsp process in any way? I had tried to renice it earlier but I don't think it made any difference.

 

[HenrikEnquist]

When they are too small you start getting buffer underruns. That gives short gaps, you can't miss them
A very small chunksize also increases cpu usage.

Changing the priority for camilladsp won't make the delay shorter. But it may enable you to run with lower values. So if you reduce the values to a point where you have some glitches, try to renice and see if it helps then.

 

[bigjacko]

Sorry a noob question.... I can't install Camilla DSP onto my windows laptop. I already installed rust and visual studio. After I download the latest release, I tried just click it or use cmd.exe and code shown in build section from the write up, nothing happened. What should I do to install it? Thank you very much for the help.

 

[dorirod]

Sorry a noob question.... I can't install Camilla DSP onto my windows laptop. I already installed rust and visual studio. After I download the latest release, I tried just click it or use cmd.exe and code shown in build section from the write up, nothing happened. What should I do to install it? Thank you very much for the help.

I haven't tried CamillaDSP on windows, but is there a reason why you want to use that instead of Equalizer APO? It's probably a lot friendlier UI https://sourceforge.net/projects/equalizerapo/

 

[Honken]

@bigjacko You don't need to install any build tools to run CamillaDSP on Windows, if you grabbed the latest release from the release page you are good to go in that regard. But as @dorirod says, Equalizer APO is probably an easier solution, and more "native".

To get a grasp of what you have to do to get CamillaDSP running on Windows take a look at the instructions. I'm not going to repeat them here as they seem rather comprehensive, but the TL;DR is that Camilla isn't a system wide EQ out of the box.

 

[mdsimon2]

Hmm…I did not test audio / video latency with the DAC+DSP. I am away from home for the next week but will measure the latency when I get back.

Michael

OK, ran some tests with the DAC+DSP.

I used a SHD Studio to provide two synced SPDIF outputs. As a baseline I ran a frequency response sweep using loopback as timing reference in REW, as expected phase response was flat with no evidence of delay between the DACs. Also checked scope output of a 1 kHz test tone and both DACs showed perfect synchronization. As the DAC+DSP only has TOSLINK input for these baseline test I used a SPDIF to TOSLINK converter for one of the DACs to ensure that it would not add any delay in further testing.

I then tried using a CamillaDSP configuration running at 96 kHz, 32LE, no resampling or rate adjust and 2048 chunk size using TOSLINK input and output of DAC+DSP feeding one DAC and other DAC fed directly from the SHD Studio. In this case a frequency response sweep did show delay, REW estimated the delay at ~46 ms.

I then tried another test using the same CamillaDSP configuration as above but using the TOSLINK input of the DAC+DSP feeding the USB input of the DAC. This setup added some additional latency compared to the first, REW estimated the delay at ~61 ms.

So the DAC+DSP is definitely adding some latency. My understanding is that a chunk size of 2048 in CamillaDSP will add 22 ms of delay, so it looks like the DAC+DSP is adding an additional 24 ms using the TOSLINK output and 37 ms with USB. This isn't a terrible amount of delay but would be interesting to see if HifiBerry has any thoughts on whether reducing latency is possible or if this amount of delay is inherent regardless of configuration.

Michael

 

[dorirod]

So the DAC+DSP is definitely adding some latency. My understanding is that a chunk size of 2048 in CamillaDSP will add 22 ms of delay, so it looks like the DAC+DSP is adding an additional 24 ms using the TOSLINK output and 37 ms with USB. This isn't a terrible amount of delay but would be interesting to see if HifiBerry has any thoughts on whether reducing latency is possible or if this amount of delay is inherent regardless of configuration.

Michael

Thank you for the additional testing Michael! Would you be able to test with resampling? I am curious if that is adding anything. In my case it might be 44.1KHz to 48KHz. You can keep the chunksize of 2048 though I'm down a lot lower. I am not sure if it's CamillaDSP or DAC+DSP that is doing the resampling in this case.

Edit: Just googled this reference so 46ms shouldn't be a big deal, I must be getting a lot more:

g)
that subjective evaluations show that detectability thresholds are about +45 ms to -125 ms and acceptability
thresholds are about +90 ms to -185 ms on the average, a positive value indicates that sound is advanced with respect to
vision,

https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.1359-0-199802-S!!PDF-E.pdf

devices: samplerate: 48000 chunksize: 256 target_level: 128 enable_rate_adjust: true resampler_type: BalancedAsync capture: type: Alsa channels: 2 device: "hw:CARD=sndrpihifiberry,DEV=0" format: S32LE playback: type: Alsa channels: 2 device: "hw:CARD=EX5,DEV=0" format: S32LE

 

[mdsimon2]

Tried some more experiments at 48 kHz and playing around with a few different variables. I used USB input for the DAC using CamillaDSP as that is most similar to your setup.

1024 chunk size, no resampling or rate adjust: 60 ms
1024 chunk size, balanced async resampling, rate adjust: 70 ms

512 chunk size, no resampling or rate adjust: 36 ms
512 chunk size, balanced async resampling, rate adjust: 43 ms

256 chunk size, no resampling or rate adjust: 26 ms
256 chunk size, balanced async resampling, rate adjust: 29 ms

I should note that the delays are higher than my initial testing because the sample rate is lower. The delays also do shift around 1-2 ms, in general the average seems more stable if resampling and rate adjust are enabled but I have not done enough testing to confirm. 25 ms should be pretty benign but it is possible your DAC is adding more delay than my DAC.

In your case both the DAC+DSP and CamillaDSP are resampling.

Michael

 

[dorirod]

Yeah I need to do some more testing to narrow it down on my setup. I still haven't managed to turn off the pass-through of the DAC+DSP. The Hifiberry support wasn't much use. They basically told me to come up with my own profile as it does the pass-through by default. However, since I have that pass-through, I am running both in my DAC, and the toslink out from hifiberry doesn't exhibit the big delay like the USB out (both going to the same DAC and I can switch inputs).

 

[Madjalapeno]

create a loopback device to reroute CamillaDSP to

For anyone like me who could not get the Loopback to be persistent over reboots see this page.

sudo echo 'snd-aloop' >> /etc/modules

 

[Dinesh V]

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

Michael,
I am trying to build an active crossover using Camilla, Pi 4 B and Hifiberry DIGI I/O and Motu Ultralite Mark 5. Can you please help me configure this so that I can get the Toslink input going. Please point me to any documentation. Did not find much on hifiberry site itself, nor did google find much.

aplay -v -D hw:sndrpihifiberry /dev/zero --dump-hw-params
I get:
Invalid value for card
audio open error: No such device

 

[mdsimon2]

Michael,
I am trying to build an active crossover using Camilla, Pi 4 B and Hifiberry DIGI I/O and Motu Ultralite Mark 5. Can you please help me configure this so that I can get the Toslink input going. Please point me to any documentation. Did not find much on hifiberry site itself, nor did google find much.

How familiar are you with CamillaDSP, do you have a working CamillaDSP configuration file with the MOTU?

If you have a MOTU Ultralite Mk5 I do not think the HifiBerry DIGI I/O is needed as the MOTU has a TOSLINK input. Why do you want to use the HifiBerry?

Can you describe the input / outputs you are trying to use?

Michael

 

[mdsimon2]

Michael,
I am trying to build an active crossover using Camilla, Pi 4 B and Hifiberry DIGI I/O and Motu Ultralite Mark 5. Can you please help me configure this so that I can get the Toslink input going. Please point me to any documentation. Did not find much on hifiberry site itself, nor did google find much.

aplay -v -D hw:sndrpihifiberry /dev/zero --dump-hw-params
I get:
Invalid value for card
audio open error: No such device

Have you added dtoverlay = hifiberry-digi to your config.txt? Assuming you are using Ubuntu config.txt is located at /boot/firmware/config.txt.

Michael