AUDIO over IP - REDNET 3 & 16 Review. AES67 Sets A New Standard for Computer Audio

[rb2013]

   
I really have no idea the point you are trying to make by reposting all those comments by Miska about UPNP & DLNA.
I was talking about HQPlayer and NAA endpoints, and whether the NAA protocol and endpoint functionality could be floated off into a separate virtual soundcard product.
Given neither HQP nor NAA uses UPNP or DLNA, I fail to see the relevance.....

Well he basically said that NAA was closer to Dante AOIP then UPNP/DNLA ethernet audio.  In fact if you read that post carefully he says it's much like Apple's 'Airplay' 
 

You shouldn't put LMS or UPnP/DLNA in the same sentence with NAA, because those are vastly different... NAA is closer to AirPlay than LMS or UPnP/AV.​

 ​

 

 

In addition to NAA and building a NAA inside a DAC you have bunch of pro-audio gear (with ADC too) already on this area. So nothing new, but depends on what you want.​

Originally Posted by tranz
Always enjoy reading your input. Do you have examples of the pro-audio gear?






For example:
​

Merging Horus​

​

Focusrite RedNet​

​

Both work with ASIO capable applications.​

 

For example NAA makes remote audio devices appear just as if they were locally connected, player behaves the same as if the playback would happen locally. So it's more like the Merging/Focusrite devices above.​

 

 
I know this stuff is complex and confusing - but it helps to read the posts.
 
Although it's not AES67.  Anyway not really sure of the deep dark secret working of NAA.  And really don't care much about it.  Unless it's open to any player like Dante/Ravenna - to discuss it is pointless...unless it has been changed to become 'open'.  Does it work with Foobar and JRMC?
 
Anyway I'm sick and tired of talking about NAA/HQPlayer/Roon/Rendu/RAAT/DNLA/UPNP.
 
Maybe you can start your own thread about those - or post to threads that address them directly...I only comment here as Alex seems obsessed with mentioning them here constantly.

 

[occamsrazor]

 
Well he basically said that NAA was closer to Dante AOIP then UPNP/DNLA ethernet audio.  In fact if you read that post carefully he says it's much like Apple's 'Airplay' 
 
...
 
I know this stuff is complex and confusing - but it helps to read the posts.
 
....
 
Anyway I'm sick and tired of talking about NAA/HQPlayer/Roon/Rendu/RAAT/DNLA/UPNP.
 
Maybe you can start your own thread about those - or post to threads that address them directly...I only comment here as Alex seems obsessed with mentioning them here constantly.

 
Umm... this thread is about "Audio over IP", not just Rednet, I thought discussing the different possible methods of doing so and the merits/disadvantages of each was on-topic and relevant, and has provoked some very interesting discussion so far.For the record I don't personally use HQP or Roon and have no stake in anything, I'm just interested in the technology and possibilities.
 
There’s a good explanation of how NAA works here:
http://www.computeraudiophile.com/f22-networking-networked-audio-and-streaming/hqplayers-network-audio-adapter-13892/index66.html#post553242
 
But if it's really disturbing you that much I'll leave it at that.

 

[rb2013]

   
Umm... this thread is about "Audio over IP", not just Rednet, I thought discussing the different possible methods of doing so and the merits/disadvantages of each was on-topic and relevant, and has provoked some very interesting discussion so far.For the record I don't personally use HQP or Roon and have no stake in anything, I'm just interested in the technology and possibilities.
 
There’s a good explanation of how NAA works here:
http://www.computeraudiophile.com/f22-networking-networked-audio-and-streaming/hqplayers-network-audio-adapter-13892/index66.html#post553242
 
But if it's really disturbing you that much I'll leave it at that.

Well you are right - just I find it a convoluted subject - so post away and I will refrain from comment.

 

[Kelowna]

The Roon RAAT and NAA protocol's appear to work similar to AES67. But there's key differences that make them far inferior.

1: They are proprietary closed formats that work specifically with Roon and HQplayer.

2: They are designed to run on general purpose computer hardware running Linux, Windows or OSX.

AES67 uses audio specific hardware that spits out CMOS I2S/DSD direct from the onboard FPGA's. CMOS I2S/DSD is the language that the DAC chips talk for PCM and DSD. When you use any protocol, (USB, SPDIF, AES/EBU) they all spit out CMOS I2S in the end to send to the DAC chip. Sending it out direct without going through additional processing and conversions is by far the best way it can be done. With AES67 the audio data is actually buffered into the onboard RAM chip, and the CMOS I2S/DSD is pipelined out via the FPGA in the purest way possible. And you are not bound to any particular audio player. AES67 gives the user 100% freedom to choose their favorite audio player. AES67 makes the need for RAAT and NAA null and void. The only way to get the audio out of RAAT and NAA is via the highly flawed USB protocol. The USB protocol was never intended for audio use, it was a compromised solution to a 2008 problem. However it's been a cash cow for trinket manufacturers who take advantage of its shortcomings to line their pockets. AES67 is a nightmare for these guys as the protocol has no ulgy warts requiring band aids. Use dirt cheap fiber Ethernet cable and the endpoint is 100% isolated from the influence of any external tweaks preformed on any of the hardware upstream of the endpoint device. AES67 is going to kill the business of all of these trinket companies offering endless server tweaks, and bandaids for USB. Is this a bad thing for the end consumer? Not in my book.

Another thing is anyone who has signed an NDA with Dante, Colevoz or anyone else regarding their AOIP products will be sued in a heartbeat if they attempt to make any competitive products. Dante and Colevoz are very aware of who has signed their NDA's and have a close eye on these guys. They also have much deeper pockets and better lawyers, so it's not something I would personally challenge.

 

[rb2013]

The Roon RAAT and NAA protocol's appear to work similar to AES67. But there's key differences that make them far inferior.

1: They are proprietary closed formats that work specifically with Roon and HQplayer.

2: They are designed to run in general purpose computer hardware running Linux, Windows or OSX.

AES67 uses audio specific hardware that spits out CMOS I2S/DSD direct from the onboard FPGA's. CMOS I2S/DSD is the language that the DAC chips talk for PCM and DSD. When you use any protocol, (USB, SPDIF, AES/EBU) they all spit out CMOS I2S in the end to send to the DAC chip. Sending it out direct without going through additional processing and conversions is by far the best way it can be done. With AES67 the audio data is actually buffered into the onboard RAM chip, and the CMOS I2S/DSD is pipelined out via the FPGA in the purest way possible. And you are not bound to any particular audio player. AES67 gives the user 100% freedom to choose their favorite audio player. AES67 makes the need for RAAT and NAA null and void. The only way to get the audio out of RAAT and NAA is via the highly flawed USB protocol. The USB protocol was never intended for audio use, it was a compromised solution to a 2008 problem. However it's been a cash cow for trinket manufacturers who take advantage of its shortcomings to line their pockets. AES67 is a nightmare for these guys as the protocol has no ulgy warts requiring band aids. Use dirt cheap fiber Ethernet cable and the endpoint is 100% isolated from the influence of any external tweaks preformed on any of the hardware upstream of the endpoint device. AES67 is going to kill the business of all of these trinket companies offering endless server tweaks, and bandaids for USB. Is this a bad thing for the end consumer? Not in my book.

Another thing is anyone who has signed an NDA with Dante, Colevoz or anyone else regarding their AOIP products will be sued in a heartbeat if they attempt to make any competitive products. Dante and Colevoz are very aware of who has signed their NDA's and have a close eye on these guys. They also have much deeper pockets and better lawyers, so it's not something I would personally challenge.

To the rescue!  Thanks man

 

[occamsrazor]

The Roon RAAT and NAA protocol's appear to work similar to AES67. But there's key differences that make them far inferior.

1: They are proprietary closed formats that work specifically with Roon and HQplayer.
 

 
I agree with that sentiment. I'm very much in favour of open standards.
I do find Dante/AES67/Ravenna exciting and hope they take off more. If a 2-channel cheaper smaller bridge does come out, I'd been very keen on it.  

The only way to get the audio out of RAAT and NAA is via the highly flawed USB protocol.

 
Is that true though? I don't believe there is anything in the RAAT or NAA protocols that dictates a USB output is there?. Yes, the uRendu only has a USB output but that's just one piece of hardware. You can run an NAA endpoint on many other types of hardware even a Raspberry Pi and output i2s from that, at least from what I've read. It's just a question of the hardware you choose to use it on - not the protocol. As I say, at least from what I've read.

PS - Thanks for joining this thread, I do find your posts interesting....

 

[occamsrazor]

  Well you are right - just I find it a convoluted subject - so post away and I will refrain from comment.

 
No worries, I will try to keep discussion on topic and I very much appreciate all your posts and the efforts you've made to explore this area.
I just try to correct statements or information I see that is not factually correct.
For what it's worth I'm actually very excited by Dante, and hoping that more hardware becomes available soon.

 

[rb2013]

   
 
I just try to correct statements or information I see that is not factually correct.
 

You are not alone...

 

[Kelowna]

Is that true though? I don't believe there is anything in the RAAT or NAA protocols that dictates a USB output is there?. Yes, the uRendu only has a USB output but that's just one piece of hardware. You can run an NAA endpoint on many other types of hardware even a Raspberry Pi and output i2s from that, at least from what I've read. It's just a question of the hardware you choose to use it on - not the protocol. As I say, at least from what I've read.


PS - Thanks for joining this thread, I do find your posts interesting....

No I suppose there's nothing dictating that USB must be used for an audio output device with NAA or RAAT. They are compatible with any audio output device that can be discovered in Linux, Windows and OSX. The I2S outs on a Raspberry PI are so poor that USB is even a better choice. Tell me about 1 device running NAA or RAAT that spits ultra clean I2S or DSD direct out of an onboard purpose programmed for audio FPGA. Sure it might be possible to build a custom solution, but that's a lot of effort to be bound to a single proprietary protocol.

 

[Kelowna]

To the rescue!  Thanks man

No problem. The truth sure is refreshing. Nice to see its embraced around here

 

[rb2013]

No I suppose there's nothing dictating that USB must be used for an audio output device with NAA or RAAT. They are compatible with any audio output device that can be discovered in Linux, Windows and OSX. The I2S outs on a Raspberry PI are so poor that USB is even a better choice. Tell me about 1 device running NAA or RAAT that spits ultra clean I2S or DSD direct out of an onboard purpose programmed for audio FPGA. Sure it might be possible to build a custom solution, but that's a lot of effort to be bound to a single proprietary protocol.

 
Thanks for joining the thread - yes keeping the facts straight.

No problem. The truth sure is refreshing. Nice to see its embraced around here

Great insights into the deeper design elements - much appreciated!

 

[Kelowna]

No problem guys. When I have some time later I'll share some details on I2S over LVDS, AES/EBU and SPDIF. And why all 3 can be better than USB for interfacing to external transport devices.

It's not by accident that folks are getting such great sound from the Rednet 3 via the AES/EBU and SPDIF ports. There's real reasons for it.

 

[gldgate]

Got my D16 today. Will need some more time to absorb and put together impressions. However, I just wanted to say to those folks who like Roon/Tidal it works fine with D16. Right now I'm playing Roon/Tidal through virtual soundcard ASIO to D16 and then out to Mutec MC-3 + USB (for reclocking)  via AES. I am also using AES from Mutec to Yggy. Not a USB cable to be seen. I've also been listening via JRMC.

 

[Soundsgoodtome]

Hey guys, good news bad news but first I want to acknowledge @atomicbob and his experiment, I read what you did and have some questions. I may want to try replicating your ASIO bridge setup to try it myself with a Breeze Du-u8 and the R3 for a simultaneous control over two output devices. I want to say that while the U12 is a fantastic device I believe that the R3 is a step up so I want to see where things may have changed.. read: does the ASIO bridge/virtual soundcard setup make sq difference void because of how it processes the audio and possibly added (for the lack of words) goobleygook to the audio signal?

So the good news bad news, from my phone call to Focusrite and having a chat with their Rednet specialist: The good news is the Rednet 3 is capable of outputting to multiple DACs and I've confirmed this to be possible but only via AES/EBU breakout cable (Tascam format not Yamaha). The output signal on the optical is not your standard spdif optical but adat optical widely used in pro sound. Unfortunately our DACs are incompatible with only 2ch optical spdif. ADAT is capable of carrying multiple channel signals over optical where as spdif is your standard 2ch; in short the Rednet 3 can't output to our DACs via optical without some kind of conversion from ADAT to SPDIF -- which I'm not sure exists. I'm sure it does but having it in the chain will probably defeat the purpose. So unless you're using a DAC that takes ADAT via optical input, the R3 can not send a signal to your DAC.

 

[Kelowna]

Hey guys, good news bad news but first I want to acknowledge @atomicbob
and his experiment, I read what you did and have some questions. I may want to try replicating your ASIO bridge setup to try it myself with a Breeze Du-u8 and the R3 for a simultaneous control over two output devices. I want to say that while the U12 is a fantastic device I believe that the R3 is a step up so I want to see where things may have changed.. read: does the ASIO bridge/virtual soundcard setup make sq difference void because of how it processes the audio and possibly added (for the lack of words) goobleygook to the audio signal?


So the good news bad news, from my phone call to Focusrite and having a chat with their Rednet specialist: The good news is the Rednet 3 is capable of outputting to multiple DACs and I've confirmed this to be possible but only via AES/EBU breakout cable (Tascam format not Yamaha). The output signal on the optical is not your standard spdif optical but adat optical widely used in pro sound. Unfortunately our DACs are incompatible with only 2ch optical spdif. ADAT is capable of carrying multiple channel signals over optical where as spdif is your standard 2ch; in short the Rednet 3 can't output to our DACs via optical without some kind of conversion from ADAT to SPDIF -- which I'm not sure exists. I'm sure it does but having it in the chain will probably defeat the purpose. So unless you're using a DAC that takes ADAT via optical input, the R3 can not send a signal to your DAC.

Another problem is clock sync between all of the DAC's. If you want to use your DAC's internal master clock, you won't have sync between the DAC's. Most DAC's these days reclock the incoming AES/EBU and SPDIF signals internally with a reclock/SRC chip. This causes latency. This is one area where having the Ravenna or Dante interface built into the DAC shines. You have clock sync through the IEEE 1588 grandmaster clock protocol. The only other way is syncing them all through word clock in's and outs. But that's a sub par way of doing things because tons of jitter is introduced with the connections and cable length. Unless a DAC has a very poor internal master clock, you will almost always get better jitter performance using the internal master if it's located very close to the DAC chip. With Ravenna and Dante, each DAC still uses its own master, it's just the skew that the grandmaster clocking keeps in sync within 1 nanosecond. Don't confuse this spec with jitter. The actual jitter performance is still determined by each of the DAC's individual masters.