Multichannel Dac with Streamer and Roon?

[mansr]

2 minutes ago, Kal Rubinson said:

There is no option to defeat the input ASRC but  you can define the sample rate as needed.

I need something that can do a bit perfect capture.

[jtwrace]

11 hours ago, Kal Rubinson said:

It does.

 

There is no option to defeat the input ASRC but  you can define the sample rate as needed.

So you're saying I could take (4) Topping DX7s and the miniDSP UDIO-8 and put them together with a streamer going to one DX7s and that would work for 8 channels?  

 

It sure is a wire mess but I'm curious.  I really look forward to a proper 8 channel dac that doesn't cost crazy money.  

[Kal Rubinson]

3 minutes ago, jtwrace said:

So you're saying I could take (4) Topping DX7s and the miniDSP UDIO-8 and put them together with a streamer going to one DX7s and that would work for 8 channels?  

No.  The streamer goes to the UDIO-8 and it connects to the 4 DACs via S/PDIF.  https://www.minidsp.com/products/usb-audio-interface/u-dio8

 

All explained in my next column.

[jtwrace]

Just now, Kal Rubinson said:

No.  The streamer goes to the UDIO-8 and it connects to the 4 DACs via S/PDIF.  All explained in my next column.

So that will work.  Hmmm  Next column when? 

[jtwrace]

Have you tried it?  Do you think the miniDSP takes away anything?  Sure would be interesting to have Amir (ASR) measure a dac with and without it.  

[Kal Rubinson]

1 minute ago, jtwrace said:

So that will work.  Hmmm  Next column when? 

Music in the Round.  September Stereophile.

[mansr]

1 minute ago, jtwrace said:

Have you tried it?  Do you think the miniDSP takes away anything?  Sure would be interesting to have Amir (ASR) measure a dac with and without it.  

The audio data should pass through unchanged. Since the DACs will be slaved to the shared S/PDIF clock, its quality matters to an extent dependent on how good their jitter rejection is.

[jtwrace]

5 minutes ago, mansr said:

The audio data should pass through unchanged. Since the DACs will be slaved to the shared S/PDIF clock, its quality matters to an extent dependent on how good their jitter rejection is.

The "should be" is the question though.  ?  I sure would prefer a Benchmark, RME or other high performing MCH dac with USB input and remote volume control that will take a USB streamer and be done.  Even better would be Ethernet in and Roon Ready.  One power cord and it's simple.  I'm shocked that no manufacturer has done this.  

[Chopin75]

I did check with manufacturer that the mini dio8 works as masterclock to clock with the Computer but reclockong only at  the input only,  Not surenwhat that means. Probably means it will send out 8 channels based in the masterclock in the mInidsp but i suppose any jitter of the signal after leaving the Minidsp dio is not relocked. ? Does it require additional clocking of each DAC, not sure.

 

Here is the actual answer:

JUL 19, 2018  |  11:58AM HKT  Tech support team replied: Hello Correct, the UDIO-8 will be the master to provide Clock and data to the DAC, the clock rate will follow the MAC PC sampling rate. Reclocking only happen at the Inputs on the UDIO-8 to match the PC sampling rate. Best Regards  DevTeam  miniDSP Ltd  Office Hours: Mon-Fri 9am-5.30pm Hong Kong Time zone / Thanks for your patience.  JUL 18, 2018  |  03:01AM HKT  Original message   I have bought your miniDSP U-DAC 8 But now I want to try U-DIO-8, because I want to to use my own DACs but I am not sure if this device can be connected to multiple external DACs, so can this device be connected to 3 DACs to do 5.1 multi-channel ? I would be using my Mac computer to play the M-ch files. Would there be reclocking issue? It appears the master clock is within the U-Dio itself correct?

[[d862005bd193ebc9efb18ea92c9f0a59The

[Chopin75]

The reason I want to painfully use 3 DAC is  because I want to get 3 R2R DAC (or at least 2 for center and FL and FR speakers) to run PCM m-ch. i want to avoid signa delta chip DAC. I also want to try 3 chipless DAC for DSD.

 

i am now using their Minidsp DAC 8 which used AKM SD chip and works quite nicely! Consider it costs $275. It cannot do DXD Nor DSD.  A bargain nonetheless. I find one does not need state of the art DAC for M-ch. It is a lot to do with speaker placement. M-ch playback as much better soundstage anyway if u set it up properly. The instruments are solidly placed, less fatigue and strain on each speaker as the work is shared by 5 to 6 speakers. Sound is naturally more relaxed. I wonder how it would sound with 3 DAC and each is R2R DAC.

[jtwrace]

On 7/18/2018 at 11:58 AM, Kal Rubinson said:

Mmmmm.  exaSound e28 or e38...................................used.  At the moment. ?

 

On 7/18/2018 at 3:01 PM, Kal Rubinson said:

Indicates that the situation may change soon.

 

On 7/18/2018 at 3:07 PM, jtwrace said:

Do you know something?  When?  What?  Come on man!

 

Still waiting!  Seriously though, do you have any time frame?  

 

 

[Kal Rubinson]

1 hour ago, jtwrace said:

Still waiting!  Seriously though, do you have any time frame?  

I will not comment because I have written about this and cannot comment until the September issue is published.

 

However, see the posts of Chopin75 above for a clue.

[ronkuper]

On 7/20/2018 at 3:02 AM, jtwrace said:

I'm shocked that no manufacturer has done this.

 

Indeed.

 

[jabbr]

On 7/19/2018 at 7:47 PM, Kal Rubinson said:

No.  The streamer goes to the UDIO-8 and it connects to the 4 DACs via S/PDIF.  https://www.minidsp.com/products/usb-audio-interface/u-dio8

 

All explained in my next column.

Someday we will be able to stream with Ethernet and/or Wi-Fi, to multiple DAC/speakers including digital crossovers ... and it will all be synced ? someday ...

[mansr]

39 minutes ago, jabbr said:

Someday we will be able to stream with Ethernet and/or Wi-Fi, to multiple DAC/speakers including digital crossovers ... and it will all be synced ? someday ...

AES67?

[jabbr]

15 minutes ago, mansr said:

AES67?

I’d prefer something cheap and easy

[Kal Rubinson]

AES67 will be cheap and easy ? someday ...

[R1200CL]

2 hours ago, jabbr said:

Someday we will be able to stream with Ethernet and/or Wi-Fi, to multiple DAC/speakers including digital crossovers ... and it will all be synced ? someday ...

 

Well my Theta Casablanca 4a has 12 DAC’s, 

So i guess I’m there ?

 

Feed either HMDI or spdif, which has a limit of 8 channels if I remember correctly. 

 

I wonder if we will see an endpoint supporting HMDI. 

 

Maybe @JohnSwenson can design, but question may as well be if there is a marked huge enough. And can such a endpoint be sold (well) below $999 ?

[R1200CL]

2 hours ago, Kal Rubinson said:

AES67 will be cheap and easy ? someday ...

 

Well, do we need it ?

 

Or what does AES67 do that RAAT isn’t already doing ?

 

@mansr you may answer as well, since you suggested that AES67

You may noticed the standard is at the present limit to 24/96. 

 

 

Also I hope this is interesting info:

https://community.roonlabs.com/t/raat-vs-aoip-protocols/33573/3

[mansr]

15 minutes ago, R1200CL said:

Well, do we need it ?

 

Or what does AES67 do that RAAT isn’t already doing ?

Probably quite a lot, since it's what pro gear uses. More importantly, it's a standard that anyone can implement without being at the mercy of one company and its whims.

 

15 minutes ago, R1200CL said:

@mansr you may answer as well, since you suggested that AES67

You may noticed the standard is at the present limit to 24/96.

That shouldn't be too hard to extend.

[jabbr]

5 hours ago, mansr said:

Probably quite a lot, since it's what pro gear uses. More importantly, it's a standard that anyone can implement without being at the mercy of one company and its whims.

 

There are several ways to accomplish that goal.

 

Standards are fine, but design by committee often leads to feature bloat/complexity that makes implementation more difficult.

 

At the moment companies are distributing their own network drivers and we have multiple competing options including:

UPnP/DLNA

Roon

HQPlayer

 

As well as various implementations of network remote ALSA etc.

Ravenna (AES67) doesn't seem to be getting the adoption of the others ... why?

5 hours ago, mansr said:

 

That shouldn't be too hard to extend.

Of course then its not standard ...

 

Open source software implementation can achieve the same goals

[Kal Rubinson]

7 hours ago, R1200CL said:

Well, do we need it ?

Or what does AES67 do that RAAT isn’t already doing ?

Since AES67 can synch multiple end-points, it can support multiple stereo DACs for multichannel audio in multiple locations.  I have tried to do similar with Roon but, so far, no luck.  No suggestions from Roon headquarters either.

[jabbr]

3 hours ago, Kal Rubinson said:

Since AES67 can synch multiple end-points, it can support multiple stereo DACs for multichannel audio in multiple locations.  I have tried to do similar with Roon but, so far, no luck.  No suggestions from Roon headquarters either.

Roon isn’t designed to do this. AES67 contains special sync details. RAAT doesn’t use this architecture. (Uses TCP not RTP + sync)

[Chopin75]

The methods described requiring wireless connection won’t work as this would require specific DAC and/or  speakers 

But i want to use the DACs and speakers of my choice.

[R1200CL]

14 hours ago, mansr said:

Probably quite a lot, since it's what pro gear uses. More importantly, it's a standard that anyone can implement without being at the mercy of one company and its whims.

 

https://community.roonlabs.com/t/raat-vs-aoip-protocols/33573/3

Did you read the link ?

 

Here is what it saying:

 

I’ve spoken a lot about RAAT’s goals before…but let me state a few of them again here.

• Create an ecosystem of certified products that meet a centrally enforced quality standard
• Provide a solution for DIY users and computer audiophiles
• Create consistency of user experience and mutual compatibility across devices from many manufacturers without requiring them to cooperate with each other
• Provide reliable audio streaming for high-resolution music listening
• Provide a control-channel for non-audio aspects like Volume Control, Convenience Switching, Standby, and other device controls.
• Reliable autodiscovery
• Stable on Ethernet and WiFi networks in the homes of real people
• Suitable for hardware devices at a wide range of cost levels
• Accomodate a large variety of existing, in-pipeline, and future products without dictating their hardware/platform choices

So the first thing to understand is–RAAT is very different in design goals and scope than the other protocols. Some of the other protocols have some of these other goals, but as a general rule, we are concerned a lot more about the end-to-end user experience than the people making the protocols you asked about–they are building infrastructure, and we are building product.

You may be thinking “but I asked about the technology” and yes I will get to that–but looking at RAAT as a streaming technology in isolation is missing important context. RAAT isn’t just plumbing–it’s a product that executes on the goals stated above.

From a user experience standpoint

It’s almost not worth comparing RAAT with the others. They don’t solve the quality assurance problem. They don’t create a consistency of experience. They don’t handle out-of-band concerns like volume control or standby or convenience switching without out-of-band extensions (like what Merging have done on the NADAC). They don’t work on WiFi, …

On a technical level

To fully extract the benefits of AES67/DANTE/RAVENNA, you need a well-engineered ethernet network, and controlled computing environments on the sending/receiving side.

In return for that, you get low latency capabilities and extremely scalable matrix mixing. This is important for some applications, but most homes (meaning, 99.99%) are not large enough to need unlimited matrix scalability and most music listening does not require low latency. With RAAT, we’ve made a different set of tradeoffs. We’ve sacrificed some things that are not so important in return for properties that are better for our application.

AES67+Friends are streaming in real-time through a relatively small fixed-sized buffer. Maybe 1ms, maybe 500ms–pretty short either way. Packets are sent in real time. When you press “pause” you wait for the buffer to drain. When you press “play” you wait for the buffer duration to pass before hearing anything. The protocols behave sort of like a speaker cable with a built in delay.

RAAT is different. When you press play, Roon blasts a couple of seconds of audio into a buffer on the endpoint as quickly as possible. Often this can be done in just a few milliseconds, since computers and networks move faster than audio streams. Then playback starts, and Roon continues filling the endpoint buffer in a faster-than-realtime manner until it is full (currently that means 10 seconds of audio in the endpoint).

Once playback starts, the endpoint drains this buffer using its own playback clock, and Roon’s job is to replace data as it is consumed. Once full, it takes a pretty large network failure to have that whole 10 second buffer drain before it can be replenished.

Of course, you wouldn’t want to pipe TV Audio through a buffering scheme like this. But for music listening, streaming latency doesn’t matter because we are free to pre-fetch data out of your files–and we can solve user experience latency while keeping our large buffer sizes by buffering faster than real time, so even though we have 10 seconds of buffer in the chain, playback still starts in a few hundred milliseconds or less.

Why the huge buffer? Because it makes RAAT stable on networks that were not installed by professionals, including WiFi networks.

Compared to the other protocols, RAAT is a lot more involved in the discipline of playback. When you press pause, we simply stop the buffer from flowing and retain the audio data on the endpoint until you unpause. With the others, the buffer drains on “pause” and then must be refilled when you unpause. This is all the result of RAAT being designed around music listening, and not simply for moving audio around.

RAAT tries to “tread lightlly” on the network. We use TCP to move the audio instead of UDP because that’s what 99% of peoples’ home network usage looks like–web pages, Netflix, Youtube, and Spotify also use TCP. So if you have a network that supports those, RAAT will probably work.

Finally, RAAT is built to evolve in place without firmware updates. This means that many of the details I described above are not actually details of RAAT, but rather details of Roon. 6 months ago, RAAT was a UDP based protocol with a 2.5 second buffer. Now it’s a TCP based protocol with with a 10 second buffer. We reworked part of the “flow” of starting a new stream a couple of releases ago because some newer WiFi devices were having trouble with the old “flow”. All of these changes rolled out without modifying any devices or having people wait for their manufacturers to “catch up”.

These changes are delivered via Roon without device firmware updates–so in that sense, RAAT is much more of a living protocol. I have some ideas about how to improve clock synchronization on high-latency WiFi networks, and how to improve sound quality during multi-zone playback. When we find the time to work on those, those will result in changes to the protocol and the benefits will roll out uniformly to all of our devices.

In this regard, RAAT is more of a vehicle for delivering Roon’s current idea of state-of-the-art audio streaming to your devices, rather than a protocol in and of itself.

In closing

RAAT is a streaming product targeted at music listening on home networks. AES67/RAVENNA/DANTE are 

If I wanted to build ethernet-based matrix switching for a huge home that was going to be used for routing real-time sources like TV audio, I wouldn’t use RAAT. If I want to stream music and internet radio to the WiFi speaker in my kitchen, the other protocols wouldn’t even be an option.