-
Welcome to ASR. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!
RPi + CamillaDSP Tutorial
- Thread starter mdsimon2
- Start date
And what you wan't to say to me??? AHK is bad ???? Its an kind off script for Windows like other Scripts used for Linux or what ever.
I want to use it on Linux so anyway and there you also need to use an script so what???
It works lik e it should, thats count's.....
I want to use it on Linux so anyway and there you also need to use an script so what???
It works lik e it should, thats count's.....
Never used it before, was an option i found on internet. Windows defoult jumps +2 Steps for one rotation klick, that was a bit strange.
So on Linux or CamillaDSP it would be a different story.
But wan't to test first on Windows for capabilitys this Device has with orig. Driver, App before i test it on Linux without Driver or App.
So on Linux or CamillaDSP it would be a different story.
But wan't to test first on Windows for capabilitys this Device has with orig. Driver, App before i test it on Linux without Driver or App.
Seems like I have without noticing on my RPi 4. Seems to work fine, but I don't really use mine for anything advanced (WiFi + DAC over USB).
It's supposed to be updated through apt package manager, but mine hasn't. I wonder if I need to use the rpi-update in order to get it.
Hey everyone,
Apologies if this was already posted in the 140 pages of discussion but I just finished wrestling with Rpi5, Dac8x and Hifime HR23 and wanted to share tips with anyone interested. My case is living room active speakers with TV and phones as the sources, connecting via BT:
Apologies if this was already posted in the 140 pages of discussion but I just finished wrestling with Rpi5, Dac8x and Hifime HR23 and wanted to share tips with anyone interested. My case is living room active speakers with TV and phones as the sources, connecting via BT:
- I spent 2 weeks trying to make the Pi accept a bluetooth stream directly, managed to handshake AptxHD but did not resolve buffer/resampling issues. I guess there's a reason bluetooth isn't even mentioned on the tutorial
- The tutorial states that Hifime HR23 does not work with Rpi5. It does if you connect it via hub. This was suggested by the manufacturer and seems to be true so far.
- I use a FIIO BR13 device as a BT receiver. This solved the Unfortunately, it doesn't do true 96khz upsampling, just frequency doubling. So this doesn't solve the resampling problem. And this seems to be impossible to solve in software too - tried all sorts of loopback tricks to make Alsa or PipeWire do the automatic resampling. It works but the problem is HR23 doesn't announce a sample rate change if it happens on the fly, so no way to reliably detect it.
- The tutorial recommends a hardware resampler, but I find using a dedicated DSP box just for this a bit wasteful. So I went with a brute force solution - I had an old DIR9001 SPDIF to I2s capture module. Connected that to the SPDIF OUT of BR13, LRCK to a GPIO pin of the Pi, a simple counter script and voila - hardware sample rate detector.
- Several days of python debugging with Gemini and I have a script that monitors the actual incoming sample rate and reconfigures CamillaDSP's upsampler to accept either 44.1 or 48kHz on the fly.
Blew
Senior Member
Curious to know hy you went to all the trouble of getting the horribly lossy Bluetooth protocol to work when you could easily use lossless Chromecast or Airplay etc?
I don't know about the "horribly lossy" part, I thought LDAC is supposed to be pretty good?
As for casting over wifi, I have no experience with those, a quick google suggested much higher latency and more difficult setup, please inform that's not the case
melomane13
Active Member
if you have iphone use airplay, if not use squeezelite
Blew
Senior Member
Apologies if my tone was a bit curt. All Bluetooth protocols are lossy, but LDAC is higher bandwidth than most. Even AptX Lossless is mostly lossy.
If your use case is streaming music from a phone/tablet/laptop around your home then you're much better off using Chromecast (Google Android, Chromium etc), Airplay (Apple IOS, OSX etc), or Slimproto (Logitech/Lyrion Squeezebox,Squeezelite etc) as they're true lossless that operate over IP (eg wifi, ethernet). The tutorial covers all three. In order of preference I'd recommend using Slimproto (if running a Lyrion server and using Rpi as an endpoint), then Chromecast, then Airplay, in that order, because Airplay doesn't support over 48KHz and neither it nor Chromecast support gapless. Also, Squeezelite uses SoX for resampling, which can produce much better results than Bluetooth or ALSA native resampling. See Archimago's post regarding this.
piCorePlayer is a very simple and easy way to get these working on a Rpi and you can use this script to very easily integrate CamillaDSP with it.
- Thread Starter
- #2,814
Hey everyone,
Apologies if this was already posted in the 140 pages of discussion but I just finished wrestling with Rpi5, Dac8x and Hifime HR23 and wanted to share tips with anyone interested. My case is living room active speakers with TV and phones as the sources, connecting via BT:
Feeling fantastic at the moment, can share details if anyone's interested
- I spent 2 weeks trying to make the Pi accept a bluetooth stream directly, managed to handshake AptxHD but did not resolve buffer/resampling issues. I guess there's a reason bluetooth isn't even mentioned on the tutorial
- The tutorial states that Hifime HR23 does not work with Rpi5. It does if you connect it via hub. This was suggested by the manufacturer and seems to be true so far.
- I use a FIIO BR13 device as a BT receiver. This solved the Unfortunately, it doesn't do true 96khz upsampling, just frequency doubling. So this doesn't solve the resampling problem. And this seems to be impossible to solve in software too - tried all sorts of loopback tricks to make Alsa or PipeWire do the automatic resampling. It works but the problem is HR23 doesn't announce a sample rate change if it happens on the fly, so no way to reliably detect it.
- The tutorial recommends a hardware resampler, but I find using a dedicated DSP box just for this a bit wasteful. So I went with a brute force solution - I had an old DIR9001 SPDIF to I2s capture module. Connected that to the SPDIF OUT of BR13, LRCK to a GPIO pin of the Pi, a simple counter script and voila - hardware sample rate detector.
- Several days of python debugging with Gemini and I have a script that monitors the actual incoming sample rate and reconfigures CamillaDSP's upsampler to accept either 44.1 or 48kHz on the fly.
Thanks for sharing!
The tutorial is meant to be plug and play for those without any technical knowledge, so I've purposely avoided things like I2S interfacing.
To clarify, you are using the UR23 as a capture device and only using the DIR9001 module for rate detection? Are there any audible artifacts during rate changes or is it well behaved?
Michael
This is true. Spotify Connect and Google TV (the smart TV OS) killed my BT usage almost entirely. Instead of setting up BT connectivity, one should first see if he can set up a player that is remote controlled by mobile devices. Only if that's not possible, set up streaming from mobile device to the audio device.
terryforsythe
Major Contributor
Yes, please.
Would it be difficult to modify the script to also accept 96k and 192k samplerates?
I use camilladsp-setrate, but it does not work with the latest version of CamillaDSP. Would you mind if I shared your solution with the developer of camilladsp-setrate?
No worries, thanks for the tips. Given my use-case I'm not as worried about the whole lossy transmission aspect but it's nice knowing there is something to move to later.
Totally understand, but I think the HR23 connected via hub bit would be useful even to beginners
And yes, DIR9001 is there only for the sample rate detection. In principle any SPDIF>i2s receiver would work. I think some spdif chips can be interfaced via i2c to identify the detected frequency directly.As for artifacts, there is some crackling that's present even with no sound coming in, so I think it's to do with CamillaDSP rebuilding buffers and such. Also each short sound byte the TV's UI outputs ends with crackling. I think that's due to BR13 dropping the carrier immediately after end of audio file. Not sure that's solvable but only a minor nuisance.
The script just counts interrupts over a measurement period, so in theory it can accept any samplerate. However my simple Python implementation, it does 96khz but has quite a few misses even on a Pi5. For 192khz I would seriously consider doing this in C or better yet - use a hardware counter.
As for the code, here's the important bit, not sure what method camilladsp-setrate used but probably something similar. As noted in my first post, I was unable to detect a sample rate change in software, might have something to do with HR23:
Python:
with open(CONFIG_PATH, "r") as f:
config = yaml.safe_load(f)
# Dynamic chunksize allocation based on target input sample rate
target_chunksize = 4096 if target_rate in (88200, 96000) else 2048
config["devices"]["capture_samplerate"] = target_rate
config["devices"]["chunksize"] = target_chunksize
# Persist change to file
with open(CONFIG_PATH, "w") as f:
yaml.dump(config, f)
# Issue atomic re-configuration to CamillaDSP engine
ws = websocket.create_connection(CAMILLA_WS_URL, timeout=1.0)
ws.send(json.dumps({"SetConfigJson": json.dumps(config)}))
time.sleep(0.05)
ws.send('"Reload"')
ws.close()
print(f"[DSP] Successfully reloaded CamillaDSP engine (rate: {target_rate} Hz, chunksize: {target_chunksize})", flush=True)Hi all, what's the lowest system resource-consuming driver / interface solution for a small OLED monitor used to display basic camilladsp info using an rpi5?
I tried the SPI. route but it's not a real cpu saver...actually, it's still kind of eating alot, %-wise.
How about a small HDMI monitor?
Thanks!!
Jim
I tried the SPI. route but it's not a real cpu saver...actually, it's still kind of eating alot, %-wise.
How about a small HDMI monitor?
Thanks!!
Jim
Blew
Senior Member
How about official Raspberry Pi touch display?
Keith Flanker
Member
Worth adding to the tutorial: fix CamillaDSP's processing rate to a multiple of the source and enable rate switching, otherwise everything gets resampled and the bit-perfect path is gone. For sub integration keep the FIR taps modest - latency matters more than filter sharpness at 80 Hz - and measure the result instead of trusting the predicted response.