I like to tinker and experiment a bit, and I thought I’d try my hand at making a streamer, one made from some prebuilt parts from Ian Canada’s shop. Specifically, I’m looking at the following modules:
I thought I’d stick these on a RPi 4, but it has several RAM configurations. I know from reading the docs RoPieee wants at least 1GB RAM, but is that sufficient to comfortably run Roon but also NAA (HQPlayer’s end point)? Would it make more sense to go 4GB? Would 8GB be overkill? Would a RPi5 make sense? (seems overkill)
The FiFo module above will allow for DSD1024 and PCM 768. Will RoPieee allow me to use the hardware at its max spec?
In other threads (and in the docs) there’s a mention of the RoPieee kernel needing to have specific knowledge of the target DAC in order to send native DSD. Is that only via USB, or does that include I2S as well? My initial targets would be a PSAudio Stellar Strata MkII, a Holo Audio Cyan 2, and a Holo Audio May. None of which seem to be listed, but other items from those manufacturers are, so I am wondering about compatibility.
My ultimate goal is to have this streamer be able to send native DSD (but also PCM, but I really want to avoid DoP) to the target DAC via I2S at the highest rate the target DAC will allow.
Thanks! (and if I screwed up and this isn’t appropriate for the topic, I apologise)
I would go for 2gb. More than enough for Roon and NAA. A Pi5 is indeed overhead.
In general: yes. However, there are many variables in play here and I never went furter then dsd256 myself.
The remark in the docs is about native dsd over USB. It requires the DAC to ‘behave well’, and sometimes a patch in the kernel. It’s impossible to predict if a specific device will work. The compatibility is a gamble: we’re talking about the usb interface specifically, and a manufacturer doesn’t need to use the same implementation in different devices.
Followup question though… You mentioned the ‘many variables in play’… could you elaborate on that a bit? I would think that if you could guarantee bandwidth to the streamer for these higher res files, and the hardware/firmware is spec’d for outputting that bandwidth, it should be good unless there’s a software bottleneck in the processing of all that data within the streamer itself (at least at the moment it leaves the I2S output… cable and target DAC notwithstanding), eh?
I don’t think I own a Pi board with less than 4. It takes a little more power the more RAM you have but I also use my Pis for things beyond streamers so the extra few bucks means I can grab any of them and repurpose without finding the ones with more RAM. Just something to think about. Otherwise, yeah, as streamer 2GB works.
First, I thought I’d respond from my experience from using Pis for both Roon and HQPlayer for a number of years. I don’t intend to take anything away from the very excellent Mr. @spockfish and the very excellent RoPieee software. It’s excellent and I have a Pi or two running it. But here’s some things to think about from my experience….
On native DSD…
This is related to ALSA and specifically if ALSA recognizes your DAC as supporting native DSD. “behave well” is an excellent way to put it but that’s after ALSA knows if your DAC does DSD. This file contains the list of USB IDs supporting DSD linux/sound/usb/quirks.c at master · torvalds/linux · GitHub
Some DACs require a driver, if not using UAC2, and that would require either a kernel patch or module for it to work properly. Sometimes this is provided for Linux or there is a community supported option. Both would require the ability to “patch” that driver onto the system which means….. You can’t use RoPieee (but you can ask for support to be included) and you can’t use NAA image (more on this below).
You asked about DSD on I2S HATs and that is it’s own complication as each HAT will handle this differently and therefore probably needs its own adjustments of either config or driver or both to make it work. I don’t have any experience with this so I’ll leave it at that.
As far as speeds and feeds. I comfortably run DSD1024 over USB on a 4GB Pi4. Pi4 has worked great for darn near anything I throw at it. Pi5 might be overkill but if you’re doing a lot of experimentation and loading of software the overall speed boost is nice but once booted and sitting there you won’t notice a difference between the 4 and 5.
And, again, not taking anything away from RoPieee because it really is good…. I want to mention that if you plan to spend any time with using HQPlayer and NAA then also look at the NAA image directly from Signalyst. It’s similar to RoPieee in you just boot it and it’s ready to go but there is zero configuration involved as all config is pushed from HQPlayer. I believe in a “less is more” approach in using a Pi as streamer and so once using HQPlayer, in my set-up, I stripped away everything else and use the NAA image. I use a second Pi on a different input of my DAC running RoPieee for Roon (currently, this changes from time to time). I’m not a fan of letting Roon do the PCM to DSD conversion so its less important to support DSD on this second Pi.
My only other comment is that, other than the overhead, there isn’t really a reason to “avoid DoP”. It’s nice to run native if you can make it work but in some setups it simply won’t be possible. The DSD encapsulated in the DoP is the same once its unpacked in the DAC. What I2S HAT do you plan on using?
You literally described all variables in play
And those are complex. But let me be a little bit clearer: I would expect it to work, but I can’t guarantee it.
RoPieee uses it’s own kernel tree, with more native DSD patches then upstream (or downstream for that matter), so if possible I’m more than willing to do so. But I need feedback from a live running system to be able to do that. And yes, this is only in the case of USB.
That depends. If you’re running NAA only, you could argue that RoPieee doesn’t make that much sense. Technically there’s not much of a difference: both the NAA image as RoPieee run the same piece of software.
