I have an Emotiva XDA-2 connected to a Raspi-4 using RopieeeXL via USB. Everything used to work fine, but now recently, I’m noticing high bit-depth tracks are being downgraded from 24-bit to 16-bit. In Roon, there are no MQA options listed for this endpoint (which is also strange, as I recall there used to be). The DAC is capable of playing back 24-bit, 192kHz streams without issue.
Does anyone have any thoughts on why the change in behaviour?
Unplug the USB. Power cycle everything (including but not limited to DAC and Pi) then retry.
No joy, same behavior persists. It is not passing through the 24-bit signal to my DAC, but rather trying to convert to 16-bit. Also worth mentioning is that it usually fails Playback while trying to do this. Not sure which update is to blame for the new behaviour; RoPiEEE update or Roon server though. Will roll-back each successively to see if I can sort it out.
I’d imagine it’s not RoPieeeXL doing this down-sampling, but Roon Core, right? What are you running Core on? What does Roon identify the endpoint as? And – playback fails? Playback of what? Streamed or local? If local, on the Core machine or elsewhere on the network?
For the core, I’m running Roon Server on a Windows Server 2016 Virtual Machine. My endpoint is the the RoPieeeXL on raspi4 connected to an Emotiva XDA-2 DAC via USB. My normal way of interfacing with it is usually with Roon client on my office desktop (Win10 Pro), or through my phone (Android Roon app). This setup has, until recently, had no issues.
FWIW, I’ll also mention that the VMs are run on a 12-core (dual socket) server chassis with 128GB RAM, where 4 cores, 8GB RAM are allocated to VM, all connected through a 10Gbps backbone…(performance metrics do not indicate it is starved of resources).
Also, regarding ‘Failed playback’, it is simply that. I will start to play a high bit-depth track (which shows audio path as above), it will play for about 30-40s, and then…it just stops. Roon doesn’t lockup, I can restart the track (same behaviour occurs), or skip to next track without issue (unless that is also a 24-bit track).
I suggest you take this up with the Roon team. Pretty sure this downsampling is not done by RoPieee but by Roon, so they can investigate the ‘why’. Could be as simple as the DAC not reporting it’s capabilities correctly, hence Roon decides to downsample.
Thanks
‘Find my device option’ allows you to pick any DAC from the list RoonReady/Tested. I suggest you pick one with similar characteristics and check the settings in device settings. Adjust them to the specifeid capabilities of your DAC and with that you override what Roon reads from the DAC capabilities
I recall I used to have the option of selecting capabilities of the hardware, but no longer appear to have as many options available to define, regardless of what hardware I assert the RoPieee+XDA-2 is.
…and if I tell it its an AudioQuest DAC (for example), then options look the exact same.
Meanwhile, I also have a Raspi with a HiFiBerry Digi+ also connected to the core, and all the usual options are there.
I think this is really an MQA thing. You have to tell Roon that the endpoint can handle full MQA decoding on its own. There should be two things under “Private zone” but above “Volume control”. At least, in my Roon, there are. “DSD playback strategy”, and “MQA capabilities.” You need to set “MQA capabilities” to “Decoder and renderer”, which will keep Roon from doing the initial decoding (I think).
So what version of Roon are you running that you don’t have those two settings?
See above…those settings are available for my HiFiBerry. But not for RoPieee+XDA-2
