· I found a reproducible difference between regular Roon playback through a Windows endpoint and Roon ARC.
Test environment Windows Roon endpoint using RAAT FiiO BTR7 connected by USB WASAPI Exclusive Mode MQA Capabilities: Renderer Only MQA Core Decoder enabled DSP and Volume Leveling disabled Test results
1. 44.1 kHz MQA source
Roon correctly applies the MQA Core Decoder:
Source: FLAC 44.1 kHz / 16-bit, MQA 44.1 kHz MQA authentication is shown MQA Core Decoder is shown Output becomes 88.2 kHz / 24-bit The BTR7 performs MQA rendering correctly
2. 88.2 kHz MQA source
With the same endpoint, device and settings, Roon does not apply the MQA Core Decoder:
Source: FLAC 88.2 kHz / 24-bit, MQA 352.8 kHz MQA Studio authentication is shown The MQA Core Decoder stage is missing The signal is sent directly to the BTR7 The BTR7 does not enter MQA rendering mode
3. The same 88.2 kHz MQA track in Roon ARC
When I play exactly the same track through Roon ARC:
The MQA Core Decoder stage is shown The BTR7 performs MQA rendering correctly
The FiiO BTR7, USB connection and MQA renderer are therefore working correctly. The only variable is the playback path: regular Roon/RAAT versus Roon ARC.
It appears that regular Roon playback skips MQA Core processing when the source stream is already 88.2 kHz, while Roon ARC processes the same stream correctly.
Could Roon support please confirm whether this is expected behavior or an MQA processing bug?
Tell us about your home network
· The same behavior occurs at home, at the office, and over a VPN connection, so it does not appear to be a network or hardware issue.
Thanks for the detailed, well-documented report, this is exactly the kind of write-up that makes it easy to see what’s happening.
Good news first: what you’re seeing in tests 1 and 2 is expected behavior, and no MQA information is being lost.
The key detail is how the MQA Core Decoder works. The Core Decoder only performs the first unfold, and its output is capped at a maximum of 88.2/96 kHz:
With your 44.1 kHz MQA track, there's unfolding work to do (44.1 → 88.2 kHz), so Roon runs the Core Decoder and you see that stage in the signal path.
With your 88.2 kHz MQA track, the stream is already at the Core Decoder's ceiling. There's no first-unfold step left to perform, so Roon passes the stream straight through to your renderer. The Core Decoder stage isn't shown simply because no unfolding operation took place, not because MQA processing was skipped.
Importantly, in that second case Roon is still delivering the full MQA-signaled stream to the BTR7 for rendering. Our logs for your zone confirm this: the 88.2 kHz track is handed off as 24/88 MQA, with MQA signaling intact, ready for the BTR7 to render.
Roon ARC shows an explicit Core Decoder stage because it uses a separate decode pipeline, but functionally both paths deliver the same thing: an 88.2 kHz stream with MQA signaling passed to the renderer. So the difference you’re seeing in the signal-path display is presentation, not processing.
That leaves one thing I’d like to pin down. When you play the 88.2 kHz track through the Windows/RAAT path, does the BTR7’s own hardware MQA indicator (its LED/color) fail to light up, or is it only the Roon signal-path display that looks different? That distinction matters, because it tells us whether the device is actually entering render mode or whether this is purely a display question. If the BTR7 indicator itself isn’t engaging, we’ll want to look at the USB render handshake on that endpoint next.
Thanks again, happy to keep digging once we know what the BTR7’s indicator is doing.
To clarify, this is not only a difference in Roon’s signal-path display. When I play the 88.2 kHz MQA track through the Windows/RAAT path, the BTR7 itself does not display the MQA indicator.
However, when I play the same track through Roon ARC with the same BTR7, the MQA indicator appears normally.
Therefore, the BTR7 does not appear to be entering MQA render mode through the Windows/RAAT path, while it works correctly through Roon ARC.
That’s a really useful clarification, thank you, and it changes the picture in an important way. If the BTR7’s own MQA indicator isn’t lighting on the Windows/RAAT path, then you’re right that the device isn’t entering render mode there, and that’s worth chasing down rather than chalking up to the signal-path display.
I dug into the logs for your zone, and here’s what’s happening. On the RAAT path, the two source types are handed to the BTR7 with different MQA flags:
44.1 kHz source: Roon runs the Core Decoder (first unfold to 88.2) and passes the stream to the BTR7 already core-decoded. That's a renderer-ready stream, so the BTR7 finishes the render and its indicator lights. This is your Test 1.
88.2 kHz / MQA 352.8 source: Roon passes the stream through without a first unfold, because a native 88.2 kHz MQA file is above the Core Decoder's 88.2/96 kHz ceiling, so there's no first-unfold step Roon can perform. The stream reaches the BTR7 still needing that first unfold.
Here's the key part: with MQA Capabilities set to "Renderer Only," the BTR7 only completes streams that have already been core-decoded. It doesn't perform the first unfold itself. So on the 88.2 kHz track it receives a stream it can't act on in renderer mode, and it never enters MQA render mode. That's exactly why the indicator stays dark on RAAT but lights up in ARC. ARC uses a separate full-decode pipeline that does the first unfold before handing the stream to the BTR7, so the device gets something it can render.
The good news is this should be a quick fix. The BTR7 is a full MQA decoder, so please try this:
In that mode Roon passes the original MQA stream untouched and lets the BTR7 do both the first unfold and the render itself, which is the same work ARC is doing for you. Replay the 88.2 kHz track after changing it and let me know whether the BTR7’s indicator lights up. I’d expect it to.
If for some reason it still doesn’t engage after that, let me know your FiiO Windows driver version and we’ll take a closer look at the USB handshake next.
Thanks for the suggestion. I tested the BTR7 with MQA Capabilities set to “Decoder and Renderer,” but it does not work.
The BTR7 is an MQA Renderer-only device and cannot perform the first unfold itself. With “Decoder and Renderer” selected, the BTR7 does not recognize MQA at all, even with a 44.1 kHz MQA source.
For comparison, my other full MQA decoder devices, including the FiiO KA17 and Cambridge Audio CXN100, work correctly when configured as “Decoder and Renderer.” This appears consistent with the documented behavior of these settings.
Therefore, “Renderer Only” is the correct setting for the BTR7. Under that setting:
44.1 kHz MQA works correctly because Roon performs the Core Decode first.
Native 88.2 kHz MQA does not engage the BTR7’s MQA renderer.
The same 88.2 kHz track works correctly through Roon ARC with the same BTR7.
The remaining issue therefore appears to be specific to renderer-only devices such as the BTR7. On the Windows/RAAT path, Roon does not seem to provide a renderer-ready stream for native 88.2 kHz MQA sources, while full-decoder devices work as expected.
Could you please revisit this based on the BTR7 being an MQA Renderer-only device?
Thank you for testing that so carefully, and you’re right to push back. Your result settles the question, the BTR7 behaves as a renderer-only device on this Windows/USB path, so “Renderer Only” is indeed the correct setting for it, and the “Decoder and Renderer” suggestion was the wrong call on my part. Apologies for sending you down that path.
I went back through the logs for your zone, and they line up exactly with what you’re describing. The two source types are handed to the BTR7 with different MQA flags:
44.1 kHz source (Test 1, works): Roon runs the Core Decoder (first unfold to 88.2) and hands the BTR7 a stream flagged mqa_core — i.e. already core-decoded and renderer-ready. The BTR7 finishes the render and its indicator lights.
Native 88.2 kHz / MQA 352.8 source (Test 2, fails): Roon passes the stream through flagged mqa (the original, un-core-decoded MQA), with no first unfold performed. There is no mqa_core handoff anywhere in the logs for this track. So the BTR7 receives a stream it can't act on in renderer mode, and it never lights.
The reason Roon doesn't core-decode the 88.2 track is the Core Decoder's ceiling: its output tops out at 88.2/96 kHz, and the first unfold of an already-88.2 file would land at 176.4 kHz, above that ceiling. So per MQA's design, Roon leaves the stream encoded for a full decoder downstream. The catch is that a renderer-only device can't perform that first unfold either. That's the gap you've identified: native ≥88.2 kHz MQA effectively requires a full MQA decoder in the path, and a renderer-only device can't cover it on the RAAT path.
On the Roon ARC comparison: ARC decodes on the phone itself, using a separate full-decode pipeline, and hands the BTR7 an already-unfolded stream. So ARC working isn’t a case of RAAT delivering something worse, it’s a different decode topology doing the first unfold before the device. That’s why the same physical BTR7 renders under ARC but not on Windows/RAAT.
So the short version: what you’re seeing is consistent with how MQA’s Core/renderer split works rather than a straightforward RAAT defect, but your report is a genuinely good edge case, and I’ve flagged it to our development team to confirm the intended behavior here and to look at whether we can surface this more clearly (right now Roon passes an unrenderable stream to a renderer-only device without telling you why).
A couple of things that would help while they look:
Could you share your FiiO Windows USB driver version, and whether FiiO's own MQA rendering/passthrough option is enabled in their control panel?
If you have a native 96 kHz MQA track handy, does it behave the same way as the 88.2 kHz one? I'd expect it to, and confirming that helps us rule out anything specific to 88.2.
Thanks again for the thorough testing on this, it genuinely helped pin down what's going on. 🙌
Thank you for reviewing this in detail and for raising it with your development team.
Regarding the driver version, I previously used the FiiO USB driver V5.74.3 and experienced the same issue with the BTR7. I later switched to the Microsoft native USB Audio driver through WASAPI, mainly to determine whether the FiiO driver provided any relevant advantage or changed the behavior. It did not appear to make any difference regarding this MQA issue.
Therefore, my most recent tests were performed with the Microsoft native driver, but the same native 88.2 kHz MQA behavior had already occurred with FiiO USB driver V5.74.3 as well.
Regarding the MQA rendering/passthrough option, I was not playing through the TIDAL desktop application, so I believe this may be different from TIDAL’s own “Passthrough MQA” setting. I also do not recall seeing a separate MQA rendering or passthrough switch in the FiiO USB Audio Control Panel while using driver V5.74.3.
Please let me know if you are referring to a specific setting elsewhere, and I will check it.
I also tried to locate a native 96 kHz MQA track in my currently accessible TIDAL catalog through Roon, but I was unable to find one. The available MQA sources I could identify were limited to 44.1 kHz and 88.2 kHz, so I could not perform the requested 96 kHz test.
Thank you very much for your active support, detailed investigation, and coordination with the development team.
I understand that the timing of the fix cannot be confirmed at this stage. Whenever it becomes available in a future update, I will be very pleased to continue using Roon with the issue resolved.
Thanks again for all your help and support throughout this case. It has been greatly appreciated.
