Many understand “sound quality” as “the sound they prefer” which would result in many individually different “sound qualities” for a single device. Not the best wording, but possible for sure.
Therefore, it’s better to clearly distinguish between a single (technical) sound quality of a single device and an individually experienced preferred sound.
Which brings us back to the initial context. Whether you prefer the pot. (hidden) DSP processed UPnP/DLNA path or the rather likely DSP free or openly DSP processed roon/RAAT path is totally up to you and is rather independent of any technical sound quality.
And when some people say that Maestro/UPnP/DLNA “sounds so much better than roon/RAAT” they actually mean they prefer the “DLNA sound”.
This doesn’t say anything about a general “sound quality”. It’s totally subjective and is no real base for talking about “sound quality”. It’s telling other people about what you prefer, nothing more, nothing less.
But none of that is relevant for the simple test that is needed.
All that is required is a local file. The waveform produced by that file needs to be compared to both the waveform of that file as delivered to the streamer by Roon and the waveform of that file as delivered to the streamer by Maestro. Simple null tests will show if there are any differences in the way Roon handles the file compared to Maestro. If both pieces of software deal with the file in a bit perfect manner, the argument advanced by Paul McGowan is lost.
The conflict is inevitable when McGowan is producing products that were never evaluated to establish their value to the audio chain in the first place. It is not difficult to show value and many vendors explicitly describe how they use exactly the methodologies that ASR uses during their engineering process, from Magico to Schiit. There are even lower-cost alternatives like the Cosmos ADC methodology @Marian describes above.
Hence we are back to “blah blah blah” value propositions without any meat, per the OP stance.
I’m not sure its “hidden” or inadvertent DSP. I wouldn’t rule it out but I do hear a difference and it just sounds to me like phase inversion in the electro-mechanical domain so it is random depending on recording. Sometimes I prefer Maestro, sometimes I prefer roon. Any track I have found I prefer in Maestro, compared with roon, I can make indistinguishable at my current location by applying a phase inversion in roon. My system here is very mid-range built around a laptop a WiSA hub and active Buchardt A500’s.
Sure, someone could do such a test (in a professional way) for a number if available devices, at any time. But I believe the real interest in doing so isn’t quite high enough, yet.
But with the right equipment and process it’d be rather easy to do.
And depending on the results you would be able to draw some basic conclusion at least.
But do not forget, such devices are black boxes. To actually prove things in a more detailed way someone has to show the spec for it (white box). No one will do this. And words are words.
All of this would be put to rest by testing if Maestro is bit perfect, as we know Roon is. I tried to do what, but since it doesn’t support ASIO and I can’t get exclusive WASAPI to work with my DAC, that’s not possible at this time.
If their “description” is correct, Maestro does not send any audio data to a device. It only offers browsing and provides audio data links to a “controlled” device for UPnP/DLNA playback. The audio data itself is received directly via the original source, i.e. file or streaming. Maestro just triggers the device to do so.
Which brings us to another aspect regarding tests. Since UPnP/DLNA is built into such a device it can use this protocol also completely without Maestro.
So, would the output be identical comparing Maestro and device built-in user interface?
A more complete test would therefore be the following.
roon/RAAT
UPnP/DLNA via Maestro
UPnP/DLNA via built-in user interface
All for sure with one and the same file.
But you won’t be able to trace any audio data coming from Maestro since it doesn’t send any.
Thanks, yes, I think your logic is absolutely correct there, and I had missed that aspect.
Hmm…so effectively his claim is that Roon is not delivering the file as it is saved locally or streamed more remotely. He is saying Roon is not bit perfect.
I guess Maestro can use any device that advertises itself as a DLNA media player on the network, but if you install Maestro on a machine - which will run a Maestro service - a DAC attached to that machine also becomes visible. I guess Maestro service is acting as a DLNA media player, and in that case, audio does flow through it, and it should honor the device settings. This is similar to Roon, which can use other kinds of endpoints - e.g. AirPlay - beside its own.
Yes, and a variety of non-UPnP/DLNA standards. My undersstanding is that it may use UPnP/DLNA depending on its initial handshake evaluation of a variety of network advertisement standards. It must have some kind of capability map. I don’t know what criteria are used. There is a crowd sourced self certification process in the GUI. Maybe it happens there. My Platin Hub is UpNP/DLNA and your Bluesound mDNS/Bonjour. There are other advertisement protocols. My understanding is, it is the “LAN Relay” where that routing occurs.
mjw
(You want nice, supportive? Call a damn helpline.)
219
Yes, maybe, its some kind of multi-protocol broker pattern, whatever the endpoint advertises. My Platin does support UPnP/DLNA for example and I have other DLNA devices at another location I cannot test. But what I notice is the lack of synchronisation between the GUI and the stream. Streams got repeated and also the play/pause button does not match the play status, neither does the replay animation next to tracks. Responsiveness of the play actions on the GUI is poor as well. On the other hand playback is pretty stable although I haven’t stressed it with concurrent database editing as I do all the time in roon.
I just put it down to a general “beta” state of the product. But with this level of statelessness I am not so sure. Maybe it really is a simple HTTPS handoff regardless of endpoint and Maestro “gets out of the way”. That’s not to say that there aren’t improvements planned. It looks very early days to me but I think it must be at the limits of a one-man-band project. Needs more resources.
Meastro neverever sends audio data to any device (“doesn’t touch the audio data”).
Meastro is able to detect which protocols/services a rendering device supports (UPnP/DLNA, Tidal, Qobuz, etc.)
Those detected services must support direct handoff, i.e. they must be able to accept a sent URL (via Maestro) to play directly from it. As if you would start the playback with the renderer’s own UI.
So, bluesound renderers are able to be detected and used by Maestro despite the lack of UPnP/DLNA support, i.e. when using any kind of supported internetaudio streaming service like Qobuz etc.
But… what about using local files?
According to the above it should then be impossible to playback local files with Maestro to a bluesound renderer since there’s no service running on the renderer which would accept a URL of a local file given by Maestro.
With one exeption. In the (rather unlikely?) case Maestro can make use of the bluesound API.
But in any case Maestro wouldn’t send any audio date but only references/links to a renderer/endpoint.
I think that is probably what is going on. But if that is the case it is not clear to me how he is synchronizing play and UI. It might just be my environment and others may have a different experience, but for me play and UI are very noticeably disconnected/unsynchronised.
And of course Maestro must sometimes send audio data to a device. Otherwise how would the Mastering suite work? (I still don’t understand why a mastering suite of of tools is needed if the whole aim of Maestro is to avoid touching the audio,)
And so far as I understand it, Roon doesn’t touch the audio unless it’s running DSP. Roon simply points the end point to the streaming service if no DSP is in use?
That makes totally sense. Since the renderer must send playback progression “from time to time” to Maestro controller app, untriggered or polled. And if this doesn’t work properly, it will be visible on the screen.