RPi + CamillaDSP Tutorial

[AncientMariner]

Do you have a USB microphone? You might want to measure your system using REW (it is free to download and use, though they do take donations). If you do not already have a microphone, a miniDSP UMIK-1 is sufficient for running frequency response measurements. It costs around $100 if I remember correctly.

I have a Umik-1. Not sure how to measure through the Pi as streamer? I suppose I could do it via Airplay, but I don't have the best experience with that in the past due to the lag. How does everyone else go about that?

What I did instead to get past any psychological influence was to compare it with my previous solution (a Qudelix 5k straight into the amp). I couldn't hear anyt difference between that and the Pi/Scarlett (Bluetooth connection to the Qudelix vs. Spotify connect). So the good news is that I got everything working to my satisfaction (thank for all the help here).

Regarding the Focusrite Scarlett, despite my initial grievances, it does the job, so I think I will keep in anyway. For sure there was something wrong with the internal mixes that caused distortion, like a gain turned up too high. Regarding that the volume only controlling output 1+2, I though about it, and it's not a big issue for me. I was never planning to actually use the volume knob for actually controlling volume. I just want it to be able limit the output to the Fosi Monoblocks when I get those (blown speakers prevention). For that 1+2 is sufficient, and the subwoofer has it's own volume control.

Also, I got better with the Pi and got Spotify connect installed, as mentioned above. And I learned to get better understanding the config files. I don't know how important is is if e.g. sample format is the same in the streamer application and in CamillaDSP? Anyway, I am now able to understand those files beyond just following a guide, and try to make sure everything matches up.

It's been a great adventure leaning how a Pi works (zero Linux experience!), but to anyone in a similar situation as myself, prepare to sink in several days of work.

What I'm missing now is some fine tuning. I get a lot of

[src/alsadevice.rs:138] PB: Prepare playback after buffer underrun

Increasing chunksize only seems to help so much, but did aliviate it somewhat. It doesn't affect the audio quality too much. Sometimes I get a click, other times I can only see it in the logs. Running resampling to 96kHz seems to make it a little worse. At 44.1kHz without resampling it's less frequent.

Maybe the streamer app can't deliver fast enough? Looking more at the config files for the streamer apps would be my next step.

Besides optimization, I would like to see if I can get Tidal connect. And then I wan't to sink my teeth into actually using CamillaDSP. So far I just imported the PEQ room correction I had running on the Qudelix. Want to learn Rephase and see what that does too. I'm not in a big rush with that though.

My config and error log to illustrate how frequent the error occurs. Also, unrelated, I got a new IEM today, that I ordered 2 weeks ago from China, so I spent most of the day playing around with that.

 

[terryforsythe]

I have a Umik-1. Not sure how to measure through the Pi as streamer?

Here is my listening setup:

WiiM --> miniDSP MCHStreamer kit --> Raspberry Pi/CamillaDSP --> miniDSP MCHStreamer kit --> LS60 speakers (active)

To run frequency response sweeps, I run REW on my windows laptop, and connect my Umik to the laptop. I output audio from my laptop to my Steinberg UR22 mkII audio interface via USB. I connect the analog output of the Steinberg to the RCA input on my WiiM.

You might be able to output digital audio from a Windows PC to your Raspberry Pi via USB. I have not tried this, but I don't see why this wouldn't work. It may require doing some configuration for ALSA to detect the digital audio over USB. Others here may already of done that, and hopefully will chime in.

What I'm missing now is some fine tuning.

I didn't do any tuning in ALSA other than initially adjusting input and output levels. Other than that, I do all of the tuning in CamillaDSP.

 

[terryforsythe]

You might be able to output digital audio from a Windows PC to your Raspberry Pi via USB. I have not tried this, but I don't see why this wouldn't work. It may require doing some configuration for ALSA to detect the digital audio over USB. Others here may already of done that, and hopefully will chime in.

Another option is to install a desktop environment on your Raspberry Pi and Run REW in that.

 

[AncientMariner]

Here is my listening setup:

WiiM --> miniDSP MCHStreamer kit --> Raspberry Pi/CamillaDSP --> miniDSP MCHStreamer kit --> LS60 speakers (active)

To run frequency response sweeps, I run REW on my windows laptop, and connect my Umik to the laptop. I output audio from my laptop to my Steinberg UR22 mkII audio interface via USB. I connect the analog output of the Steinberg to the RCA input on my WiiM.

You might be able to output digital audio from a Windows PC to your Raspberry Pi via USB. I have not tried this, but I don't see why this wouldn't work. It may require doing some configuration for ALSA to detect the digital audio over USB. Others here may already of done that, and hopefully will chime in.


I didn't do any tuning in ALSA other than initially adjusting input and output levels. Other than that, I do all of the tuning in CamillaDSP.

Thanks again. I will do some research on a direct USB connection. That sounds like an interesting and clean solution.

Getting REW to run directly on the Pi, I suppose I need to have a screen and mouse/keyboard connected? Or can the desktop be accessed in a browser?

 

[Rafaille]

Thanks again. I will do some research on a direct USB connection. That sounds like an interesting and clean solution.

Getting REW to run directly on the Pi, I suppose I need to have a screen and mouse/keyboard connected? Or can the desktop be accessed in a browser?

Usb connection, or usb gadget mode, is documented in Michael's tutorial.
Very easy to set up, you just need either a decently powered usb port on your laptop (usb 3.0 should be >0.9A, at least in theory) to run and feed the Pi, or a usb power/data 'splitter' to hook up both laptop usb data and external power supply.

 

[AncientMariner]

Usb connection, or usb gadget mode, is documented in Michael's tutorial.
Very easy to set up, you just need either a decently powered usb port on your laptop (usb 3.0 should be >0.9A, at least in theory) to run and feed the Pi, or a usb power/data 'splitter' to hook up both laptop usb data and external power supply.

Thanks for the heads up. I skipped that part of the tutorial as it never occured to me I would run it as a gadget.

I will experiment if I can get enough power out of my M1 Mac. Or just get the splitter, seems practical that you can disconnect without the Pi shutting down.

 

[terryforsythe]

Thanks again. I will do some research on a direct USB connection. That sounds like an interesting and clean solution.

Getting REW to run directly on the Pi, I suppose I need to have a screen and mouse/keyboard connected? Or can the desktop be accessed in a browser?

You could remote into the the desktop. However, the last time I tried to do a remote desktop session on Linux, which was probably about 7 years ago, it was very slow. So, it may not work too well unless it has improved significantly since the last time I used it.

 

[phofman]

What I'm missing now is some fine tuning. I get a lot of

[src/alsadevice.rs:138] PB: Prepare playback after buffer underrun

Increasing chunksize only seems to help so much, but did aliviate it somewhat.

Every xrun is bad. They cannot be eliminated for 100% (that would require a hard-realtime OS) but getting xruns so often at this tiny CPU load is not usual. IIUC your chunksize is 1024 and target level 2047. I do not know what CDSP version you have, but likely the one with buffer size set to 2 chunksizes (= 2048). That means you ask your feedback loop to keep the playback buffer on average completely full which is not technically possible and likely skews the feedback value. The debug logs will tell you what the buffer size is. IMO keeping the target level around 75% of your buffer would be better.

 

[phofman]

Just had to figure a bit around which of the many devices (like 5 for that card) to choose. Any drawback on the plughw version of it? Getting errors for the others.

Getting errors means your capture/playback params are incompatible with your hw device. You can learn the real values with aplay/arecord --dump-hw-params -D hw:XXX .

Your config screenshot shows async resampler, even though your I/O devices are identical and you have rate adjust disabled (which is correct). Is there a specific reason for that?

 

[OCA]

Thank you for the information!


The tutorial video I originally followed indicated that there was an issue with FFT in REW doing it that way. But, the video is more than a year old and there have been quite a few REW updates since then, so perhaps that issue has been fixed.


Due to my room and where the speakers are positioned, the frequency responses of the speakers at the listening position are not the same due to non-symmetrical room reflections. This adversely impacts their imaging performance. By equalizing them to the same target curve at the listening position throughout the frequency range, the imaging improved quite a bit. So, for my setup, I want room correction to extend well beyond 225 Hz. That is what I did, and it worked well for my room/speakers.

That video was probably mine but REW has been massively updated since that old video

 

[AncientMariner]

Every xrun is bad. They cannot be eliminated for 100% (that would require a hard-realtime OS) but getting xruns so often at this tiny CPU load is not usual. IIUC your chunksize is 1024 and target level 2047. I do not know what CDSP version you have, but likely the one with buffer size set to 2 chunksizes (= 2048). That means you ask your feedback loop to keep the playback buffer on average completely full which is not technically possible and likely skews the feedback value. The debug logs will tell you what the buffer size is. IMO keeping the target level around 75% of your buffer would be better.

Thank you very much for the explanation.

I realised I had another error. I accidentially set silence timeout to 1 sec. It seemed to cause underrun everytime there was a silent part of a track?

Anyway, with 75% target it has been running now for 15 mins so far without underun.

Thanks for your help.

 

[phofman]

Hm, that rate adjust at 1.0000 is weird. A correctly working rate adjust would hardly end up at that exact figure. The same figure was on your previous screenshot. Does the number change when running for a while?

 

[terryforsythe]

That video was probably mine but REW has been massively updated since that old video

I think it was. OCA = Obsessive Compulsive Audio

 

[AncientMariner]

Hm, that rate adjust at 1.0000 is weird. A correctly working rate adjust would hardly end up at that exact figure. The same figure was on your previous screenshot. Does the number change when running for a while?

Yes, it does change. It's at 1.0001 now after 20 mins of playing. Is that good?

I had 3 underrun is those 20 mins, but I'm not sure if I was doing something that could have caused it. I switched sources a couple of times.

Edit:
And now 5 mins later back to 1.0000.
Also I wonder why the buffer was so low on the first screenshot.

 

[phofman]

Yes, it does change. It's at 1.0001 now after 20 mins of playing. Is that good?

OK, good that it changes. The actual steady value is not that important, every clock runs at a different pace. Just interested - what is the playback device hw:USB?

I switched sources a couple of times.

Switched sources playing to the Loopback device? I do not know if that could cause any effect on the other Loopback side, more unlikely.

Also I wonder why the buffer was so low on the first screenshot.

It takes a while for the buffer to get to the target level, plus every xrun changes that a lot, there is some minor issue with the target-level handling at xrun recovery.

 

[AncientMariner]

OK, good that it changes. The actual steady value is not that important, every clock runs at a different pace. Just interested - what is the playback device hw:USB?

It's a Focusrite Scarlett 4i4 Gen2. It's just named "USB" when looking up with aplay -l. I was wondering why it didn't have a name when I looked at first until I realised Forcusrite just called it USB.

Switched sources playing to the Loopback device? I do not know if that could cause any effect on the other Loopback side, more unlikely.

On the Mac I'm streaming from. It goes like this: Spotify or Tidal player -> Soundsource with redirect to VB-cable -> Airfoil then uses VB-cable as input, and streams with Airplay to the Pi. On the Pi it follows this guide and uses shairport-sync as streamer.

The reason for this convoluted setup is that I used Soundsource to apply an AUNBandEQ for room correction (and still use it on some other speakers). And I can separate audio to the speakers from the system audio on my Mac (e.g. for background music, I can still watch a youtube video on the Mac without the sound going to the speakers).

When I say I changed sources, it meant changing if either Spotify or Tidal is redirected to VB-cable in Soundsource. If I change the source it may mean that Airfoil is steaming silence to the Pi. I still can figure out if silence beyond the silence_timeout treshold will cause an underrun?

It takes a while for the buffer to get to the target level, plus every xrun changes that a lot, there is some minor issue with the target-level handling at xrun recovery.

Thank you for all your explanations. It really helped a lot. Underrun it now a lot less frequent, sometimes it's half an hour between underruns, and I hear no clicking whatsoever. So it seems it handles the underruns that do occur much better.

 

[terryforsythe]

When I say I changed sources, it meant changing if either Spotify or Tidal is redirected to VB-cable in Soundsource. If I change the source it may mean that Airfoil is steaming silence to the Pi. I still can figure out if silence beyond the silence_timeout treshold will cause an underrun?

I experienced an issue where Tidal was changing the streaming bit-rate for different songs, depending on how they were recorded. When the bitrate changed, CamillaDSP did not detect the change and went silent. I overcame this issue by setting my WiiM to always stream at 44.1 kHz/24 bit.

There is another package, camilla-setrate, that will automatically detect a change in bit-rate and, on the fly, reconfigure CamillaDSP for that bitrate. It does not work with my MCHStreamer, but it may work with the shairport-sync.

GitHub - marcoevang/camilladsp-setrate: Automatic sample rate switcher for CamillaDSP

Automatic sample rate switcher for CamillaDSP. Contribute to marcoevang/camilladsp-setrate development by creating an account on GitHub.

github.com

Sample rate switcher for CamillaDSP

I have developed an automatic sample rate switcher for CamillaDSP. Unlike gaudio_ctl, this tool is dedicated to updating the CamillaDSP configuration, so there is no need for external programs. It also automatically reloads a valid configuration after the USB playback device has been unavailabe...

www.diyaudio.com

 

[Cathul]

Shairport-Sync always gets 44.1kHz only as this is the specification for AirPlay Audio.
48kHz is the spec for AirPlay video.

 

[mdsimon2]

Hmm...I don't recall any pop on my Mk5 when I restart the RPi, although I never power off the Mk5. I usually have my amps on a trigger based on the optical output, but I've also used it without the trigger and don't remember any pop.

I'm out of town this week but I'll play with it a bit next week and report back.

Michael

Following up on this, my Mk5 has almost no audible noise when powering on, powering off or unplugging from the wall. This is a with a Hypex NC252MP amplifier from Audiophonics and TRS to XLR cables. There is very subtle "pff" noise when powering off, certainly not a scary pop or click.

In comparison my Okto sometimes has a much louder click when powering down, but this may be due to shutdown of the amplifiers (I use a triggered 12 V power strip) rather than the Okto.

I've been thinking about how to quantify turn on / off pop and the best I can come up with is a peak FFT while measuring the connected amplifier output through a voltage divider. I'll see if I can make some measurements this week and see if they correlate with my perception of the noise.

Michael

 

[mdsimon2]

Thank you for all your explanations. It really helped a lot. Underrun it now a lot less frequent, sometimes it's half an hour between underruns, and I hear no clicking whatsoever. So it seems it handles the underruns that do occur much better.

One thing that I've noticed for all DACs other than the Okto dac8 PRO is that CamillaDSP will report a buffer underrun when coming out of paused state.

I'd set silence threshold and timeout to default and see if you still are seeing underruns with CamillaDSP always in the running state. Given the underruns do not seem audible I would question if they are actually occurring in normal playback.

Michael