@jbuhl When you set the Pi to Roon Ready it shuts down MPD I do believe.
And I suppose we could presume that this could be happening with other OS and their native players (maybe).
@mgrif104 My belief (I don’t have factual data to back up but it is a logical conclusion) is that Roon must operate across many hardware systems (much like MSFT windows) and proprietary OS are able to address cache and buffers directly. Each hardware system is different in this regard. Size, signal path, etc are different in every device. And, similar to windows performance being variable across different hardware systems, Roon must do the same.
This would essentially indicate that the OS native streamer doesn’t necessary have an impact on how Roon is implemented or its SQ, but that instead it’s more or less the nature of Roon and how it interacts across the different hardware systems (as you mentioned). The delta of performance is how the native OS addresses the cache and buffers directly (again, as you mentioned). That makes a whole lot of sense to me.
@welcher I believe the hardware interface between the DAC and source has a bigger impact on the sound than the software being used. (I am not saying that software does not have an impact on the sound) When the hardware interface is usb, AES or SPIDF then you must contend with noise and timing issues. When the interface to the DAC is ethernet then you must contend only with noise.
I agree with the hardware interface between the DAC and source having a greater impact than the software. When the interface to the DAC is Ethernet and only needing to contend with noise, I wondered whether in certain situations that simply adding an Ethernet filter or optical conversion prior to a DAC/streamer combo in comparison to a separate DAC and streamer via USB (for example) may actually be more cost effective for the SQ one may be attempting to achieve. Again, this is me attempting to reduce the variables while attempting to comprehend what’s being said, which had me thinking.