No, I promise you it’s sent natively 
1 Like
The Roon Core / Server always Decodes to LPCM and streams that to each of the endpoint / zones
Many reasons for doing it this way…not least of which is multi-room sync
what’s the difference then between RAAT and Roon Squeeze?
Netowrk bandwidth monitor tallies with a FLAC file being sent to the the Transporter.
The signal path only tells you the source is FLAC. Bandwidth observation is interesting though
Perhaps @brian can enlighten us: is data sent by Roon through the Squeeze protocol native or PCM?
The Knowledge Base posts below confirm that the Roon Core / Server convert to LPCM or DSD and sends that Stream onto the Endpoint / Zones
This and several previous comments from Roon Devs confirm this approach
Roon transmits raw PCM to Squeezeboxes. There is no compression on the wire.
1 Like
Colour me corrected! 
It does beg the question, why? If you sent the file natively to Squeezebox you’d reduce server and network overhead.
Your question is good, but the vantage point that the question comes from is really narrow. Let me broaden it.
The design/architecture problem at hand is not “send music to Squeezebox endpoints”. It’s “build an audio distribution infrastructure that supports N output mechanisms, grow N at a reasonable pace over time and support them all indefinitely”.
In context of that broader goal–server/network overhead for one output mechanism needs to be considered alongside many other factors, and in context of a strategy that is much larger than Squeezebox.
Roon’s playback engine manages:
- Fetching media from sources + seeking within seekable media (local files, local caches, random access http, sequential access http, authenticated/DRM streams, HLS streams, SMB, …)
- Decoding file formats (lots of them) to streams
- Stitching decoded audio into gapless, crossfaded, volume-normalized streams
- Converting streams into streams supported by the output module
- (In the future) DSP/processing features
Output modules manage:
- Reporting the set of stream formats that they support
- Starting, Stopping, Pausing, and Un-pausing playback of raw (PCM or DSD) streams.
We could have drawn the line between these two parts of the system in many places, up to and including writing an independent playback engine from scratch for each output mechanism.
We chose to draw the line in a place that limits the complexity of adding additional output modules because we expect there to be many of them, we want them to be inexpensive to implement (so we can say “yes” to more things), and because testing them completely is relatively difficult–which suggests that we should make them simple, and architect the system so they are modified rarely.
If we drew the line in a place that allowed output modules to get their fingers into the files, we probably would not have been able to afford to support Squeezebox or HQPlayer.
A side effect of sharing the playback engine across all mechanisms is that there are a lot fewer potential bugs/defects, and fixes are more likely to apply across the board. It also means that when we do something like adding DSP features in the future, we won’t be tempted (or forced) to limit that functionality to only the “highest priority” output mechanisms.
Another side effect is that there is only one codec for each format–a surprisingly important thing if we want the software to be self-consistent. It would be annoying if Roon could decode a file and SB couldn’t, or vice versa. 100% chance that this would happen (in both directions) if we let Roon determine whether a file was “ok” or not, then used that information to predict whether SB would play it successfully. This sort of inconsistency is really poisonous to user experience. We try not to let it happen.
As for your two points, directly:
- The server load associated with decoding an MP3, AAC or FLAC file for real-time playback on a computer suited to running Roon is so small as to be negligible.
- I wasn’t sure if the increased network demand would be a problem or not–in theory it could cause reliability differences between Roon/LMS. If it turns out to be a problem, there are avenues open for us to fix it. 6 months later, and it hasn’t caused a measurable support load, so I’m glad we didn’t spend the effort prematurely.
2 Likes
Well Mark, you did ask! 
Cheers, Greg
1 Like
@brian, very insightful response. Thank you.
Do you see a day where Roon would be able to group SB playback with RoonReady/RAAT playback? I’m using a Sonore uRendu as one endpoint but various SBs for others. I can put the uRendu in Squeezelite mode to still accomplish grouping it with my other SB endpoints (kitchen, dining room, porch, …) when needed, but ideally it would be great if I didn’t have to.
@mdconnelly, It’s something I would very much like us to do because I feel like the current limitations are a sort of wart on the product. I’m honestly not sure if/when it will happen or what the extent of the feature will be.
Each of the streaming protocols works differently, sometimes very differently, and they were not built to be interoperable. I believe that it’s technically feasible, but complex to implement and (especially) test. I worry that it would never be 100% reliable, and that it would be an extraordinarily difficult feature to support in the field given the potential permutations involved.
Doesn’t mean we won’t do it–but it’s an expensive feature to have, so it needs to be worth it.
Coming back to the original post title: the sound quality of my setup (Squeezebox Touch (EDO), YBA WD202 DAC) has improved after using Roon instead of LMS. More spatial clues (particularly depth) and pace/rhythm have improved. And as stated it’s very reliable.
Count me as one satisfied customer.
2 Likes