What's the point RAAT vs DLNA?

Roon Software Discussion
1

Into Roon since a couple of months, which is heaven since I started to lose track of my music files…
From DLNA to Roon is not technically a huge step, I have built a 8i3 NUC with ROCK and got myself a plain Roopie RPI as endpoint and everything works likes a charm.

Then I started to REALLY dig into digital audio and thought, hey I need a really good USB endpoint to feed my DAC. Ended up with the SOtM ultra on my shopping list. Then I thought, what is really the point here, what am I doing? So I thought I should ask the lovely Room community :slightly_smiling_face:

Back in the DLNA days I got my music from the media server running on the Synology NAS directly through the LAN into my DAC, controlled with an iOS app.

With Roon I use the same Ethernet cables to get the bits eventually into the DAC.

Why would I get a better sound using the Roon network concept instead of the DLNA concept? Same source, same LAN/switches and same DAC?

Why wouldn’t the DAC be capable of maximising the stream from the Ethernet cable in the same way as the “Roon way”.

What I am really after with Roon is the fantastic way of finding my music (compared with pretty much everything else I have tried…), but should I go for a more mainstream solution than SOtM to get the same SQ?

Using Roon does not intrinsically means I get a better sound compared to my DLNA approach?

Opinions and facts are more than welcome!

/Per

2

Oh, what a can of worms you’re opening! Technically, the difference is the RAAT protocol controlled by Roon versus the DLNA protocol, implementations of which seem to be all over the map with regard to compliance. Roon may be said to “try harder” in getting the right bits to the right place in time. So the SQ improvements you may encounter would be mainly on the digital (time-based) side of the house – fewer dropouts, stutters, disconnects, etc. Personally, I had come to the end of my patience with the DLNA client built into my Onkyo receiver, and was about to throw it out and get something else when I stumbled across Roon. One Roon core and one RoPieee box to provide a USB endpoint, and I’m a happy Onkyo camper again, plus half-a-dozen additional Roon endpoints scattered around the house.

3

Here’s a good starting point from Roon’s perspective.

4

DLNA is such a clunky old-fashioned, never quite finished interface. Yes, both DLNA and RAAT will play digital music delivered from a server. But this is like saying a 1972 Ford Pinto and a 2018 Porche 911 are both cars that will transport your body from one location to another. True, but… :sunglasses:

2 Likes
5

You wouldn’t. The problem with UPnP/DLNA is not sound quality.

Years ago, I wrote what we hate about UPnP/DLNA here: What's wrong with UPnP?

That said, Roon itself can give you enhancements to the SQ using DSP.

3 Likes
6

Thanks for the feedback guys. So two things, clock and DSP…

Reading (again) the article about RAAT i got a new perspective on this sentence “Letting the DAC control the pace of streaming removes the need for a clock-drift-compensation mechanism”. Why would I then even think that a fancy box switching from Ethernet to USB, like the SOtM, makes sense? If the DAC ultimately decides, it is the quality of the DAC clock that matters (at least to 99%…), right?

Or the other way, having a masterclock to “rule them all” - expensive but logical.

Danny, your comment about DSP really got me interested. I thought that DSP is never anything that could contribute positively to SQ. I switched that off without even giving it a thought. Please point me in the right direction here.

Thx
/P

7

A big benefit of RAAT over upnp is its multiroom capabilities that can sync all endpoints to keep perfect timing across different manufacturers.

2 Likes
8

Really interesting thread. But the reach of RAAT for correcting clock drift is not beyond each Roon “device”, right? I mean, my NAS does not use RAAT, neither the DAC. Can RAAT influence every clock on its way from NAS to DAC??

The difficult point here, not being an electronics engineer, just an audiophile, is to understand enough to take wise decisions about where to spend money where it actually matters…

9

Not sure if I’ve misunderstood your post, but RAAT doesn’t control timing; it is an asynchronous protocol that let’s the DAC control the stream. RAAT makes sure music is delivered to your DAC without it getting messed up.

  • Audio devices must own the audio clock . Many other protocols get this wrong, including AirPlay. It’s not possible for two clocks to agree perfectly. Letting the DAC control the pace of streaming removes the need for a clock-drift-compensation mechanism that is bound to increase cost, decrease sound quality, or both.
10

Hm, confused but on a higher level :slight_smile:

I thought, after reading the old thread from Danny and another thread where Brian wrote “In any case, RAAT already measures and corrects for clock drift.” - that RAAT actually did this.

I guess it’s me and semantics here. So a SOtM NAA with a really good clock does not make sense in the chain since it is the quality of the clock in my DAC which will have the impact on jitter and digital noise eventually? Or is this apple and pears?

1 Like
11

Clock drift and jitter are not the same thing.
To control jitter, it’s a good idea to have a local clock in the DAC, and the endpoints pulling content asynchronously.
To synchronize sound over several endpoints, in spite of the clocks in the devices drifting (house-wide “party mode”), it’s good to have a control clock pushed to the endpoints.

RAAT allows both at the same time.

Also, much of the dislike for DLNA is about poor quality, inconsistent implementations.

But there are other differences. DLNA sends the original files to the endpoints, means those endpoints must have horsepower and the license to decode all formats. I recently read about an expensive new Sony headphone rig, the specifications had a long list of formats it supported — pfft, I haven’t worried about that I; years.

Etc. etc. etc.

12

That’s the conclusion I came to, as well. The important thing on the digital side of the world is speed – enough of it to move the bits to the right place in the right order at the right time. Most modern hardware has plenty of that (given a fast enough network connection). The other thing to think about is electrical noise filtering from the digital side to the analog side through your DAC, coming over the USB cable from the streamer to the DAC. Reading this article convinces me that a modern well-designed DAC will probably handle what electrical noise there is just fine, without fancy hardware on the digital side, or a fancy USB cable.

So what kind of DAC do you have?

2 Likes
13

I use a Oppo Sonica DAC.

14

That’s a nice modern DAC from a good design house, so I’d suspect a simple streamer like a RPi would be fine.

15

This is my impression too, the “Femto clock” should be in the DAC, not the renderer.

16

It’s a well debated topic, some of the more qualified opinions (in my humble one) are on CA (Computer Audiophile as was). I would argue everything matters. Current developments include clocking the whole chain and isolating the renderer and thus DAC from noise. The “Femto clock” should be in both (and possibly the switch).

Personally I find/found an increase in using RAAT over DLNA, or more accurately switching from what I had to RAAT sounded better. I understand that it shouldn’t necessarily but it seemed pretty clear to me. RPis can be excellent.

17

RPis seem to be popping embedded in all sorts of hifi these days.

18

Many of the issues with DLNA/UPNP vs. RAAT may have had to do with very poor implementations when networked digital audio first became a possibility.

I remember trying to use a version of Foobar’s DLNA server with a Popcorn Box (network media player) back in the early 2000s and being dismayed that you could load a playlist and start the server but then could not modify the playlist at all - it just played through as initiated unless you killed the process on either end. Then there were all the issues with gapless playback and one format working fine while another choked the system. You could make it work but it wasn’t nearly as reliable or easy to use as just straight playback from a single device without beaming the media stream through the network.

These may not be inherent in DLNA so much as half-done implementations and compatibility between implementations. It seems like Plex does pretty well for folks when using both a Plex server and a Plex client.

Until I saw Roon’s signal path display, I’d never seen such a good trouble-shooting and quality-confirming tool. Maybe it is like the blue light on an MQA DAC, but I do feel better when I see the white or purple indicator that confirms bit perfect quality.

So i think the real answer is that DLNA given the proper love and attention may work reasonably well on implementations meant to work together. RAAT already assures this because it is either RAAT capable or not, for the most part. That also means you get all the signalling necessary for the signal path to be displayed accurately. I love that feature of
Roon.

2 Likes
19

Or bridge between Roon and DLNA using the Sonore UPnP Bridge software running on a microRendu.
Here you can try maintaining the Ethernet connection into your Network player or use the USB output from a cleaner environment.
You can run Roon DSP on both of the signal paths.

I use the UPnP Bridge on a UltraRendu into my Naim NDS/555DR network player, so I can use Roon from ROCK on a NUC with library on a NAS, instead of a UPnP Server and Naim’s own iOS app.
That is until I can fund the ND555 upgrade, which is RoonReady, but this is presently, many years off.
Simon

20

Thanks Simon, didn’t know about that option. Sounds surely as an alternative.