[Moderator comment: For better visibility and to allow continued contributions, I’ve split out the wider discussion to its own topic.]
—————
Again, specific audio formats/signals supported by a device are (technically) divided across the available inputs. Each input has its own range of support. And RAAT is such an input.
So, whenever you want to get sure that concrete formats are supported via RAAT by some device you usually must ask the device manufacturer directly.
Unfortunately, such information is often not part of published tech sheets or manuals of roon Ready devices.
In some cases manufacturers don’t even publish such information for regular, non RAAT inputs, instead showing/advertising some information in a rather loose context.
I think Vadim’s answer leaves some room for interpretation.
In case roon should run some separate own online database reporting all certified/enabled formats for each roon Ready device the roon server might fetch exactly this information comparing it with the device’s RAAT response. In case roon might not have certified a specific format they’d be able to ignore such formats even if the device says “I do”.
Maybe during certification it came out that 192kHz via RAAT is not 100% stable and McIntosh just forgot to exclude this from their RAAT response. Or vice versa. Or something completely different. @vadim Are you able to enlighten us here?
Note: Roon’s sample rate conversion defaults to use power of 2 sample frequencies, IIRC.
So while 352,8 kHz is more than 192 kHz and it could in theory (and even in practice if the default option gets changed) convert this to 192 kHz, it will convert it to 176,4 kHz instead. There is no proof for the claim that Roon converts 384 kHz to 176,4 kHz in this case so far. People showing up here on the forum making false claims happens daily – so I believe when I see it.
I see this as a technical explanation of the current resampling implementation in roon, no doubt. And it’s good to know.
But many threads are created here asking why some (roon Ready) device shows unmatching audio properties when fed by roon compared with the original audio format. For many it’s not clear why they see this happening. We already could identify…
The (roon Ready) device with the connected input does absolutely not accept a certain format from roon, though other inputs do. This is esp. with DSD or/and multichannel. Usually a lack of information in the device’s manual plus rather ambiguous advertising of supported formats. Depending on settings in roon this will or won’t do some format conversions before sending the signal to the endpoint.
Now, roon skips certain resampling formats in case it’s not in the same kHz family of the original audio data.
Is there more we should/could know?
I totally understand the confusion and repeatedly asking for explanations.
Since roon clients are not very transparent in explaining why some audio format conversion is actually done.
One step forward could be to simply show all audio formats a specific device supports with roon via RAAT, USB etc. roon requests this information anyway and knows all of it, but only in the background, not readable by the user. Could be a simple info page in a roon client
Not really, indirectly at best if you want to be generous. The network as audio input does not get mentioned in the manual’s specification section at all.
From this, only USB is specified for higher sample rates and DSD support. SACD for MCT means SACD player (encoded with Sony copy protection cypher) only.
Note: The network isn’t a straight audio input. It is sort of a meta input, supporting various (transport) protocols that may have each their own limitation. Examples: AirPlay (44.1 kHz, 16-bit), ChromeCast (48 kHz without and 96 kHz with hi-res flag set, 24-bit), …
Roon Ready network devices have Roon’s streaming technology built in, and are certified by Roon Labs to provide the highest level of quality and performance in network streaming.
Sure, but showing the concrete supported formats of the currently connected device in use should be no big deal. It’s not about an absolute general list but the situation while roon is being used
Again, roon fetches the concrete support anyway in the very concrete and current situation of connections and settings..
And I really understand all the frustration. But Roon Labs only certifies the devices and does not build them. They certify for the highest level of quality and performance available (as implemented by the device) network streaming – which may even be lower as what is offered by the device for other streaming protocols. Quality and performance here both refer to the network streaming and not perceived sound quality (or highest resolution audio format).
My opinion: The consumer electronics industry is very good in building average devices that fulfill common task regularly used by “the average customer” while concealing true capabilities and, not only through that but also, create high/false expectations. We users should vote with our purses. High prices buy you higher material and build quality at best, but not (necessarily) higher format support, better sound quality, better support, better documentation, plausible marketing, exact, true and all encompassing datasheets / specifications. Exceptions may exist to emphasize the rule.
Nobody questions this here. But roon fetches the possible formats of a specific connected device with certain active settings anyway. So the roon server (and remote clients) are aware of them anyway. Why not showing them transparently to the user…? So, everyone could follow the path why roon decided for the one or the other format.
But look at the current case please. How would such a minor function have helped the McIntosh customer and prevented his frustration? To see that information the money had already to be spent. For real customer satisfaction this information has to be provided by McIntosh (device manufacturers in general actually) upfront in marketing material and specification. Even if they did, we would probably still see disappointed users here that never looked-up any of the aforementioned information before buying.
Oh, and I don’t know if legality comes into it. It is a contract between two parties. I’d think that just like Roon Ready certification requires many other things from the manufacturer, publishing the connection specs for Roon might have been made a part of it.
Of course, I’m sure that there are many pragmatic considerations, too, and maybe this would have been too much. Or maybe nobody foresaw that it would be necessary to prevent manufacturers from misleading their customers.
Maybe more demand leads to more questions
Well, sure as a customer you’d have to be very deep in the roon topic to be able to raise questions towards roon, the device manufacturer or your dealer.
Looking at the prices of some endpoints… I’d do so, rather before a purchase. But since we talk rather about a blackbox it involves some work and patience maybe not everyone has.
Interesting quote regarding “parity”…
So, parity is limited to network connections here. The rest is rather ambiguous.
Hhmmm… so, following this “definition”, their shall be no roon Ready device that accepts multichannel audio through a network connection like e.g. DLNA/UPnP but doesn’t via RAAT?
Might be true.
