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

[Superdad]

  Or why does the totl and very impressive Sonore Rendu Signature not work with Roon, or RAAT or Roon/RAAT? Even thought it does DNLA/UPNP??  But then maybe it does - but Sonore doesn't list it.
 
And my confusion just goes on and on.  Like HQPlayer working with and USB DDC?  It an enigma wrapped in a mystery for me.
 

 
I can clear that one up for you.  The Sonore Signature Rendu (which Swenson did the truly SotA S/PDIF and I2S/LVDS output boards for), uses an expensive Swiss-made, Blackfin-based DSP module for its Ethernet input.  And it is pretty much a DLNA-only affair.
 
The MicroRendu on the other hand, is based on a small iMX SoC (system on chip) module (socketed into a groundbreaking audio-optimized six-ways-to-Sunday baseboard by Swenson) running Linux, hence its ability to be set up as an endpoint for all sorts of audio network protocols.  The MicroRendu could easily be installed into a DAC, but as I recall, getting greater than 192Khz I2S out of the iMX6 subsystem is currently impossible.

 

[rb2013]

  The problem with making a great AOIP solution is it takes big bucks to do it right. I'm talking about over $500K if you seriously want a solution from start to finish to work like clockwork. The Lead FPGA engineer over at Coveloz lives down the road from me. His son goes to the same preschool as my daughter. When he told me the bill for just the FPGA programming he did for them my jaw dropped. This is the reason Alex doesn't have a solution. But just because you can't afford it, doesn't mean you should bash it.

+1

 
Thank goodness Forcusrite can and has - so why shouldn't they maximize that investment.

 

[Superdad]

  Since 99.9% of my 3200 albums - are mostly Redbook, but many 32/176k digitalized LPs and SACD's (maybe 500-600) the need for 384k, DxD, DSD, i2s is well not a huge priority.  Not saying not nice to have - but totally unessential.  Great if your microRendu can do that - so can the $450 3 yr old Gustard X12.  Big deal.  Not my listening cup of tea.

 
The point of high SRC and DSD SDM has nothing to do with source material.  It is entirely about supplanting the resource-constrained digital filters inside the DAC. The higher you can get in s/w--before the DAC--the better.

 

[rb2013]

   
I can clear that one up for you.  The Sonore Signature Rendu (which Swenson did the truly SotA S/PDIF and I2S/LVDS output boards for), uses an expensive Swiss-made, Blackfin-based DSP module for its Ethernet input.  And it is pretty much a DLNA-only affair.
 
The MicroRendu on the other hand, is based on a small iMX SoC (system on chip) module (socketed into a groundbreaking audio-optimized six-ways-to-Sunday baseboard by Swenson) running Linux, hence its ability to be set up as an endpoint for all sorts of audio network protocols.  The MicroRendu could easily be installed into a DAC, but as I recall, getting greater than 192Khz I2S out of the iMX6 subsystem is currently impossible.

OK thanks for that.
 
But I still can't see why Roon/RAAT can't be made to work with the Signature??  It's their totl statement product.
And Roon does do UNPN (correct my typo for the anal out there - UPNP)  right - at least I see these streamers listed on their website as partners, like Aurualic (not the Vega but the Aries) :
AURALIC ARIES

FEATURES

1. Streaming Services
2. Local uPnP/DLNA library content
3. Qobuz and WiMP online streaming
4. Internet Radio
5. AirPlay and Songcast
6. USB hard drive files*

 

Signature Series Rendu
http://rendu.sonore.us/signature-series-rendu.html

STANDARD FEATURES
Supports Tidal lossless streaming via BubbleUPNP controller on an Android device
Supports Tidal lossless streaming via BubbleServer and Linn Kazoo controller
Supports gapless playback
Supports DSD/DoP pass through via SPDIF output
Isolation from server noise over network
Asynchronous Ethernet to SPDIF / LVDS i2s output
Integrated, 32 bit, high precision volume control
Supports 24 bit PCM playback at sample rates up to 192KHz via SPDIF and LVDS i2s output
Supports native DSD playback up to DSD128 via LVDS i2s output 
Controlled via apps on a computer, Android, and iOS device
UPnPTM AV 2.0 / DLNA compliant
Gold plated exposed copper on printed circuit boards
Impedance control on digital output module 

You see how I can be confused about this state of affairs (everyone like my new stately diplomatic tone).
 
Then on the microRendu - you have to use your own USB device - like adding garbage on top of a fine meal (well not completely stately).
And don't get this wonderful SPDIF design and clocking of the Signature -

This output board holds the dual Crystek CCHD oscillators, the re-clocking circuitry, and the output drive circuitry for SPDIF and I2S.  Because the Signature Series Rendu generates clean clocks and then reclocks on the output board right before the SPDIF and I2S output jitter is lowered even further.  Additionally, a very special SPDIF driver circuitry results in a perfectly clean SPDIF waveform which allows one to get the best out of any SPDIF input DAC.  While the original Rendu has set the Ethernet to SPDIF and I2S standard up to now, the new ​

Signature Series​

Rendu takes performance to the next level, this is the best SPDIF and I2S we can make, and we suspect that you will think so as well​

 

Don't you think Roon and Sonore customers wouldn't want a "perfectly clean SPDIF waveform".

 

 

[rb2013]

   
The point of high SRC and DSD SDM has nothing to do with source material.  It is entirely about supplanting the resource-constrained digital filters inside the DAC. The higher you can get in s/w--before the DAC--the better.

Well that is what the Mutec is for - as SPDIF reclocker - about the improvement to the USB version of the MC-3+:
 
http://mutec-net.com/product_mc-3-plus-usb.php
 

This is what MUTEC’s proprietary re-clocking algorithm paired with the 1G-Clock technology provides at the highest level! Our MC-3+ Smart Clock already impressed critics and users around the world, and the MC-3+USB now marks the next generation of re-clocking by MUTEC. Extreme oversampling of incoming data allows the audio to be recombined and merged with a newly generated ultra-low jitter clock signal at ultimate precision, enhancing the re-clocked audio with unparalleled richness of details, spatiality, and musicality.

 
So why burden the CPU with this 'extreme upsampling' when a dedicated and much cleaner DAP/DSP in the Murtec can do it better?
 
Now I do upsample - 44k to 192k with Foobar and SoX.  Now you can argue that HQPlayer does it better - great not going there - not when I have a Mutec doing this for me h/w optimized.

 

[Superdad]

  The problem with making a great AOIP solution is it takes big bucks to do it right. I'm talking about over $500K if you seriously want a solution from start to finish to work like clockwork. The Lead FPGA engineer over at Coveloz lives down the road from me. His son goes to the same preschool as my daughter. When he told me the bill for just the FPGA programming he did for them my jaw dropped. This is the reason Alex doesn't have a solution. But just because you can't afford it, doesn't mean you should bash it.

But Mike, the goal of firms like Covelez (and Dante, and several others) is to offer their modules to OEMs for integration.  I am not bashing that.  Read what I wrote.  I am simply complaining that the s/w to support it is not readily available.  Ask Merging how much time and money it took to develop their virtual sound card s/w--for Win and OS X--for their AES67/Ravenna offerings.  That's why they are not sharing it with the rest of the AES67 community.  
 
And if the expectation is that each DAC maker is going to write their own VSC s/w (for all platforms, and keep it current with OS changes), that's crazy.  And that's why adoption (by high-end DAC makers) has been very slow.  I am not making this up. We were in serious talks with several prominent DAC designers regarding our now back-burnered "USB>Ethernet Audio Bridge OEM Solution," and they issue is very real.  Each of the firms had also researched the Dante, Covelez, etc. options.
 
Clearly I have been repeating myself--in pretty much every argument you an I have had on this subject.  Show me the open s/w solutions and I might be next in line to embrace AES67/Ravenna.

 

[Kelowna]

+1

Thank goodness Forcusrite can and has - so why shouldn't they maximize that investment.

Adopting a 3rd party OEM solution into your product like Focusrite did isn't big bucks. It's coming up with your own solution. Even with Ravenna being open source we are still talking roughly $500K. Well unless you know the right people that is. Unfortunately Alex doesn't.

 

[Kelowna]

But Mike, the goal of firms like Covelez (and Dante, and several others) is to offer their modules to OEMs for integration.  I am not bashing that.  Read what I wrote.  I am simply complaining that the s/w to support it is not readily available.  Ask Merging how much time and money it took to develop their virtual sound card s/w--for Win and OS X--for their AES67/Ravenna offerings.  That's why they are not sharing it with the rest of the AES67 community.  

And if the expectation is that each DAC maker is going to write their own VSC s/w (for all platforms, and keep it current with OS changes), that's crazy.  And that's why adoption (by high-end DAC makers) has been very slow.  I am not making this up. We were in serious talks with several prominent DAC designers regarding our now back-burnered "USB>Ethernet Audio Bridge OEM Solution," and they issue is very real.  Each of the firms had also researched the Dante, Covelez, etc. options.

Clearly I have been repeating myself--in pretty much every argument you an I have had on this subject.  Show me the open s/w solutions and I might be next in line to embrace AES67/Ravenna.

You made it clear that Ravenna was a poor choice for high end audio a year ago on CA. Now you will be first in line? It's too bad you felt that way a year ago. Because now you're in the back of the line

While the forward thinkers were adopting, you were trashing.

 

[rb2013]

Adopting a 3rd party OEM solution into your product like Focusrite did isn't big bucks. It's coming up with your own solution. Even with Ravenna being open source we are still talking roughly $500K. Well unless you know the right people that is.

Unfortunately Alex doesn't.

Now your just being a tease! LOL!

 
Well I hope you get to the 'right' people and get us a lower cost Ravenna solution!

 

[rb2013]

 
But Mike, the goal of firms like Covelez (and Dante, and several others) is to offer their modules to OEMs for integration.  I am not bashing that.  Read what I wrote.  I am simply complaining that the s/w to support it is not readily available.  Ask Merging how much time and money it took to develop their virtual sound card s/w--for Win and OS X--for their AES67/Ravenna offerings.  That's why they are not sharing it with the rest of the AES67 community.  
 
And if the expectation is that each DAC maker is going to write their own VSC s/w (for all platforms, and keep it current with OS changes), that's crazy.  And that's why adoption (by high-end DAC makers) has been very slow.  I am not making this up. We were in serious talks with several prominent DAC designers regarding our now back-burnered "USB>Ethernet Audio Bridge OEM Solution," and they issue is very real.  Each of the firms had also researched the Dante, Covelez, etc. options.
 
Clearly I have been repeating myself--in pretty much every argument you an I have had on this subject.  Show me the open s/w solutions and I might be next in line to embrace AES67/Ravenna.

There is Dante - but you insist on 384k PCM, 256DSD, i2s - when those are not necessary for great audio!

 

[Kelowna]

I'm waiting for the admin lady to contact me with the info to become a sponsor. After that I can talk a bit more

 

[Kelowna]

I wonder what happened to this?
 

 

[Kelowna]

   
 
 
The MicroRendu on the other hand, is based on a small iMX SoC (system on chip) module (socketed into a groundbreaking audio-optimized six-ways-to-Sunday baseboard by Swenson) running Linux, hence its ability to be set up as an endpoint for all sorts of audio network protocols.  The MicroRendu could easily be installed into a DAC, but as I recall, getting greater than 192Khz I2S out of the iMX6 subsystem is currently impossible.

The problem with streaming devices with USB outputs are, no matter how great they might be at providing a clean USB signal, the USB path doesn't end at the USB output on the device. It ends at the I2S/DSD outputs on the DAC's USB interface. Most of them are poorly implemented, and devices upstream of the chain from them have no influence on this. You are only polishing half the turd. Yes a half polished turd is better than a completely dull turd, but still not the ultimate solution.
 
If only resolutions 24/192 or under are required, and you must use USB out of the server PC, a better solution is a very good USB/AES/EBU bridge like the Mutec everyone is raving about here.
 
But with devices like the Rednet 3 being on par cost wise with a Microrendu and a cheap power supply, it's a no brainer to go AOIP/AES/EBU. This is the next best thing to I2S direct if you have low jitter clocks and a clean signal coming from the bridge.

 

[occamsrazor]

  So why burden the CPU with this 'extreme upsampling' when a dedicated and much cleaner DAP/DSP in the Murtec can do it better?
 
Now I do upsample - 44k to 192k with Foobar and SoX.  Now you can argue that HQPlayer does it better - great not going there - not when I have a Mutec doing this for me h/w optimized.

 
It's not a "burden", the argument is that it is better to do the heavy lifting i.e. upsampling/filtering/PCM>DSD etc on a powerful computer to take advantage of CPU-intensive algorithms to do the best quality upsampling, but also that it makes sense to do this on a machine further back in the chain, so that the extra noise produced by this CPU-intensive process is isolated from the simpler lower-noise device that is actually connected to the DAC.
 
This is the HQPlayer > NAA architecture and it makes a lot of sense to me. That said I don't like the HQP player interface, or lack of ALAC compatibility (unless used with Roon) and this kills that for me (though clearly not many others)
 
Here's an idea.... To me, HQP/NAA clearly has a good ethernet transport system (not player, I'm talking the transmission protocol). Does anyone know what exactly it is using for the transmission to NAA? And there are now a few decent NAA endpoints. But not everyone likes the player. I wonder if Miska would consider floating off that side of things and instead of having a player + ethernet audio transmitter combined, instead offered an option to have the ethernet transmitter part spun off into a virtual sound card - as an optional purchase. Then you could run for example a uRendu from any player over ethernet, and not just the various options currently supported.

 

[occamsrazor]

  The point of high SRC and DSD SDM has nothing to do with source material.  It is entirely about supplanting the resource-constrained digital filters inside the DAC. The higher you can get in s/w--before the DAC--the better.

 
Yes I am with you on this. It's a point many don't seem to get - it's not about what your source material is, it's about using a computer to upsample e.g. Redbook files to higher rates... Currently I have a DAC that only supports 96khz PCM, but looking to upgrade to something that does high PCM and DSD rates. It's not because I have lots of Hires or DSD material - the vast majority of my collection is Redbook - but to allow me to take advantage of upsampling.
 
Look, if we're thinking about AOIP solutions to be adopted, it simply doesn't make sense in 2016 to limit things to 192khz, when ethernet has a bandwidth far, far, far greater - you're just building-in obsolescence.
 
The more difficult and probably harder problem to overcome is we don't yet have a great interconnect method from ethernet bridge to DAC to use those higher rates - all AES/SPDIF/Toslink are limited, and USB has issues. i2s is the only other current method, or perhaps Thunderbolt. It just seems bizarre to me that in these days of massive bandwidth available we are still using methods that are severely constrained.