Audio dropouts with DSD files

Finally have my Roon/Airplay setup working with a RPi 3B+ and Ropieee. Using an RME ADI-2 DAC via USB from the Pi. It all works beautifully…however…when playing high res DSD rips I notice that I am getting audio dropouts. Using ethernet as the network input for the Pi. I am aware that the Pi shares is data bus between ethernet and USB and I wonder if this is the problem I am having. Would WiFi be any better in this case? I hate to have to abandon this Roon streaming setup as I have the 7 inch touchscreen as well and having album art display is great. But thinking that the Pi just doesn’t have the horsepower for DSD streaming.

Are there any Ropieee settings that might resolve this issue?

I’ve used several different rpi setups one with and one without a display and older 3b and newer 3b+ and all have done native dsd512 no issues with ropieee and I think dietpi too with Allo usbridge.

what high res DSD are we talking about?

1 Like

I rip my SACDs to .dsf files usually coming in as DSD64 or DSD128. The audio gaps seem to just be dropouts and then the music recovers. It’s very quick but annoying. In looking for an answer I seem to keep turning up that the PI shares its data bus between ethernet and USB, and that’s my configuration. But I could be wrong as others seem to not have the issue. Just find it perplexing. Will do more testing but have only noticed it with DSD playback. So was wondering if there might be some config options - even via SSH - that might help with this.

Why would you rip them at anything more than DSD64? That is all that is on them so you won’t get anything useful by ripping them to DSD128. In fact, by doing so, all you have accomplished is to waste storage space and get nothing more for it than upsampling on the fly as you play.

1 Like

The software I use is called TraX. It’s Mac software that allows you to set a straight rip to .dsf so I don’t actually specify the resolution, i.e. DSD64 etc. The software does a clean rip from the disc without any file format changes. I can look into it to see if TraX allows for changing the audio file resolution while maintaining the .dsf format.

There aren’t any configuration options for this as this should ‘just work’. Yes there are some limitations to the Pi’s design, but still DSD128 is reachable without any doubt.

So if you notice drop outs then there’s obviously something wrong in the chain.

Can you test this with PCM384 (comparable to DSD128 wrt bandwidth) so we can rule a things out?

They say that TRAX’s input for DSD is .iso so what are you using to rip the .iso from the disc?

" Input Format: SACD Disk Image (ISO Format)"

“* Support of DSD formats (DSF and DSDIFF) (only extraction not conversion)”

Okay, I’ll try this as part of my further testing and see what happens.

I did this a while ago when I was ripping all my CDs and SACDs before storing them. I think the SACDs .iso were created with Disk Utility and/or a disk image maker running under Windows in a VM. I know the .iso creator does a bit for bit copy and a checksum so those images are golden. I suppose it’s possible that in ripping the images TraX glitched and the problem is in the file itself. So I’ll do more testing to confirm by playing some of these files to see if the dropouts happen in the same place and are repeatable.

I am skeptical about this process, especially without details.

Of CDs, sure, but not so sure it can even see SACD. Can you tell me how big they are?

It takes a special drive to read the sacd layer as I recall. Apple drives don’t do this afaik.

Not sure how capturing the .iso is relevant to my dropout issue but…

I have/had an external USB drive that read the format along with other disc formats including Blu-ray etc… MacOS Finder couldn’t deal with SACDs back when I was doing this but the imaging software could see the drive and create an .iso from it.

Assuming other people want to make .iso from an SACD (even though it is not the topic of this thread) you can simply google this to find out the instructions. It is a bit more complicated that you would like but pretty easy to follow. I did this a few years ago as part of an archiving effort to get away from physical media so my memories of the exact process are limited. But the info is out there for sure for both Mac and Windows users. I think I went the Windows route for the SACDs and Disk Utility for regular CDs.

Mine turned out to be a little less than 2GB each. Sometimes a bit more and sometimes less. The bigger ones are usually because there are both Stereo and Multichannel versions of the songs on the discs.

I am also a bit confused how you come to this result?
To my knowledge there are two methods of ripping SACDs (i mean the SACD layer, not the CD layer, if available);

  1. An old Sony Playstation PS3 with original firmware and the early firmware (i have one of those)
  2. Using a bluray player such as Oppo BDP-103/105 and ripping to the network.

There are no other optical readers able to both read the SACD layer, and extract it’s contents.

I think you have ripped the CD layer and converted it into some form of bitstream, but i can be wrong… (i often am! :slight_smile: )

I’m with you on this @Mikael_Ollars (I have the Oppo 105) and have used it to rip my SACD’s the extracted the ISO to DSD tracks, normally on a Mac box with the Sonore software

Yeah. I suspect something is amiss. My .iso files run from just under 2G to 8G+. Typical ones are between 3 and 5G.

I agree with your supposition (and not your self-doutbt).

Yes, in the case of the newest Pi3B+ since WiFi (includes .11ac support) and USB bus are not shared…

If you have that Pi model already, give WiFi a try…

Hmmmmm…well that would be unfortunate as I gave away all my CDs and SACDs after ripping them to what I thought was the native format. Will dig into this a bit more.

Do you have any of the ISOs? Perhaps we can compare a few specific ones. Also, one can look at the frequency response of the files and see the range of frequency content.