Auralic Aries UPnP Renderer: Double DSD Over Wi-Fi

Wang Xuanqian · January 4, 2014

Does Streamer support Multichannel download files - or Stereo only ?

The digital audio outputs such as AES, COAX and TOSLINK can only support 2ch as it is the standard. However USB host support up to 24channels in 24BIT/192KHz but it is much depend on software design. Our correct solution is 2ch only but upgrade for multi-channel supporting will not request hardware design change but purely a firmware upgrade.

Wang Xuanqian · January 4, 2014

Thanks Wang. Won't this bring wifi next to the rest of our equipment potentially bringing rf/emi noise into the system? I ask as I went through great effort to have the caps server hard wired and without wifi.

The RF noise is not a problem for as because of our Purer-Power technology can handle everything, however you can still disable the WiFi hardware in Lightning App and using Gigabit Ethernet if you wish.

bmoura · January 4, 2014

The digital audio outputs such as AES, COAX and TOSLINK can only support 2ch as it is the standard. However USB host support up to 24channels in 24BIT/192KHz but it is much depend on software design. Our correct solution is 2ch only but upgrade for multi-channel supporting will not request hardware design change but purely a firmware upgrade.

OK, that helps clarify things a bit. Stereo only for now. But it could be upgraded to support Multichannel down the road.

davide256 · January 4, 2014

Lightning is back compatible with DLNA/UPNP control software and we already tested JRMC, it works fine. However, you will not abel to enjoy some advanced function such as on-device playlist, multiple control point supporting. High-Res audio streaming from WiFi is much depend on network situation, that's we we choose 802.11ac for recommended WiFi standard, it give you much room when the actual connection is not so good and you will still have a smooth experience.

My day job is network communications and service level agreements. Wireless is an awful choice for repeatable, predictable, high quality data transfer. I will never use wireless for other than casual listening... I need 99.999% reliability/ performance in an audiophile data transfer setup.

jtwrace · January 4, 2014

The RF noise is not a problem for as because of our Purer-Power technology can handle everything, however you can still disable the WiFi hardware in Lightning App and using Gigabit Ethernet if you wish.

OK. So we can use ethernet connection if we choose. Good move IMO as I do not want to use wireless as I have it all wired via ethernet.

Also, what about PCM > 2xDSD up sample Since I'm able to do that now within JRiver is this something that can be done with the ARIES and your UI? This has become my default since the subjective sound quality is so much better.

Wang Xuanqian · January 4, 2014

My day job is network communications and service level agreements. Wireless is an awful choice for repeatable, predictable, high quality data transfer. I will never use wireless for other than casual listening... I need 99.999% reliability/ performance in an audiophile data transfer setup.

The uPNP/DLNA and OpenHome are based on TCP/IP connection which means it will be reliable as lost package or error will be resent. It is not like UDP(AirPlay) that cannot have stable signal quality. We dont have problem streaming music via WiFi here at several home environment testing program but we all understand it will be much depend on network infrastructure that you are using. This is our job to support our client with correct network setup. Let's wait and see how good we can do.

Wang Xuanqian · January 4, 2014

OK. So we can use ethernet connection if we choose. Good move IMO as I do not want to use wireless as I have it all wired via ethernet.

Also, what about PCM > 2xDSD up sample Since I'm able to do that now within JRiver is this something that can be done with the ARIES and your UI? This has become my default since the subjective sound quality is so much better.

PCM>DSD is still under development and will not appear in our first version of firmware that is going to launch on May. Actually it is not just up sampling but with down sampling too. Since the digital output(AES, COAX and TOSLINK) can only output up to 24/192. We have to find a way to let people choose how to output DSD and DXD though these ports. The UI can be pretty simple and easy to understand with just some options inside hardware setting section of the software.

I personally think room acoustics correction is a big deal but we are still in research stage.

jtwrace · January 4, 2014

PCM>DSD is still under development and will not appear in our first version of firmware that is going to launch on May. Actually it is not just up sampling but with down sampling too. Since the digital output(AES, COAX and TOSLINK) can only output up to 24/192. We have to find a way to let people choose how to output DSD and DXD though these ports. The UI can be pretty simple and easy to understand with just some options inside hardware setting section of the software.

I personally think room acoustics correction is a big deal but we are still in research stage.

How long do you think it will take for the updated firmware version that will up sample PCM > 2xDSD? If the unit comes out in May are you thinking the end of 2014 or late summer of 2014? I'm not asking for a firm date but I need to decide whether I get this or get an updated computer at this point and then go with this once it's all figured out in the latter stages. I love the concept and really like my Vega so this is obviously my first choice.

Wang Xuanqian · January 4, 2014

How long do you think it will take for the updated firmware version that will up sample PCM > 2xDSD? If the unit comes out in May are you thinking the end of 2014 or late summer of 2014? I'm not asking for a firm date but I need to decide whether I get this or get an updated computer at this point and then go with this once it's all figured out in the latter stages. I love the concept and really like my Vega so this is obviously my first choice.

The firmware and control software will upgrade monthly at least for bug fix and performance improvement. New functions will be introduced each quarto, we have some in plan such as AirPlay, build-in uPnP server(read attached USB disk), more radio services. The DSD up sampling is in the plan but not first priority. Maybe end of 2014 is a reality timeline.

Paul R · January 4, 2014

This is somewhat misleading - Airplay uses a slightly modified RTP and RTCP protocol on top of UDP (or perhaps on top of SCTP or DCCP).

RTP is a Real Time protocol specifically designed for transmitting audio/video streams, and is reliable. Missed packets will be resent, there is provision for time synchronization, QOS, control of jitter, and multiple streams among many other things.

I would be surprised if you are not using RTP or some other proprietary protocol... ?

-Paul

The uPNP/DLNA and OpenHome are based on TCP/IP connection which means it will be reliable as lost package or error will be resent. It is not like UDP(AirPlay) that cannot have stable signal quality. We dont have problem streaming music via WiFi here at several home environment testing program but we all understand it will be much depend on network infrastructure that you are using. This is our job to support our client with correct network setup. Let's wait and see how good we can do.

Wang Xuanqian · January 4, 2014

This is somewhat misleading - Airplay uses a slightly modified RTP and RTCP protocol on top of UDP (or perhaps on top of SCTP or DCCP).

RTP is a Real Time protocol specifically designed for transmitting audio/video streams, and is reliable. Missed packets will be resent, there is provision for time synchronization, QOS, control of jitter, and multiple streams among many other things.

I would be surprised if you are not using RTP or some other proprietary protocol... ?

-Paul

AirPlay is using RAOP protocol which is somewhat similar to RTSP but with Apple's encryption. uPnP/DLNA and OpenHome are all HTTP based. RTP is designed for real time audio video transmission but not for stand for high quality especially when we talk about audiophile quality.

Miska · January 4, 2014

RTP is a Real Time protocol specifically designed for transmitting audio/video streams, and is reliable. Missed packets will be resent, there is provision for time synchronization, QOS, control of jitter, and multiple streams among many other things.

RTP doesn't have retransmission for lost packets and it is sender clocked. I know because we implemented a VoIP and video call stack for mobile phones. Most VoIP audio codecs contain packet loss concealment algorithms and in case this is missing common practice is to play comfort noise instead. There are special comfort noise packets to indicate level and spectral properties of the background noise that are transmitted when other side is not speaking, so the recipient doesn't think that the call has broken. In addition ASRC is used to compensate for clock drifts between sender and receiver hardware. Rate estimation is done based on recipient jitter buffer statistics.

Most used codecs for RTP voice are G.726, G.729, Speex and Skype's SILK.

In realtime streaming case like VoIP, there's no time for retransmission especially because for comfortable conversation the overall delay shouldn't exceed 250 ms - that includes all software/hardware delays, codec's algorithmic delay, and transmission delays.

firedog · January 4, 2014

This sounds like a really intriguing product and I can really see myself buying this instead of a new server and just connecting it to an NAS. Hopefully it will sound better than a server as Auralic seems to think.

Paul R · January 4, 2014

RTP certainly does have retransmission. RTP connections usually consist or two protocols, a port for RTP data and the next port up being RTCP, which has retransmission and all of the goodies in it. It is very commonly used just this way for media transmissions, including Airplay.

In VoIP, RTCP or a similar protocol is used, primarily to control Quality of Service (QoS).

I know this because I too design and code for VoIP as well as media transmissions on a network.

I can retrieve the list of relevant RFCs.

-Paul

RTP doesn't have retransmission for lost packets and it is sender clocked. I know because we implemented a VoIP and video call stack for mobile phones. Most VoIP audio codecs contain packet loss concealment algorithms and in case this is missing common practice is to play comfort noise instead. There are special comfort noise packets to indicate level and spectral properties of the background noise that are transmitted when other side is not speaking, so the recipient doesn't think that the call has broken. In addition ASRC is used to compensate for clock drifts between sender and receiver hardware. Rate estimation is done based on recipient jitter buffer statistics.

Most used codecs for RTP voice are G.726, G.729, Speex and Skype's SILK.

In realtime streaming case like VoIP, there's no time for retransmission especially because for comfortable conversation the overall delay shouldn't exceed 250 ms - that includes all software/hardware delays, codec's algorithmic delay, and transmission delays.

Paul R · January 4, 2014

Okay, being somewhat dense, I often need to draw pictures to understand what I am talking about.

In the picture below, and speaking of 2C Audio only, which pieces of the new Auralic gear would replace the computers, the DACs, or both below. Each computer sees the other computers as a separate zone, as well as the each DAC or other connection as a Zone.

The Browsers connect directly to JRMC and can also play media.

The iPhone/iPad are running JRemote, which can control all the computers and zones, and can playback compressed or uncompressed audio streamed to it from any computer.

Thanks - Paul

----

ted_b · January 4, 2014

Mr Wang. Thanks for being on this thread and providing some good mfg'er feedback and q&a.

I will be at CES also, and will head over to this demo asap. I am very interested in:

* compatibility with all DSD-capable DACS (as has been already brought up, what if Linux driver incompatibility with DAC) especially, in my world, Chord, exaSound, Meitner, Mytek, MSB, etc.

* adding an additional voice for the re-prioritizing of multichannel (Kal, Brian, you guys with me? ) and DSD128 upsampling (Jason, I agree that this feature is invaluable for those DACs that shine with DSD128).

* look and feel of the control app. Metadata/Tagging functionality is critical. I love Jremote, and couldn't live with early Lumin app (is better now, but gave up).

This product category is a real keeper. Like other aspects of home audio, being able to component-ize a signal path with dedicated (and less expensive to update and upgrade) black boxes is why none of us use those stereo consoles that included the source/preamp/amp and speakers in one jack-of-all-trades box. Up until now most DSD streamers were an all-in commitment (like Lumin's $7200 integrated streamer/control point/DAC), and many of us already have some of the parts, and believe they may actually work better than those included in the all-in-one. Moreover, this bridge approach allows a less savvy computer user (all the way down to the plug-n-play user) to potentially manage his/her hirez setup much easier than those of us who love to optimize Windows Server 2012.

jerryct · January 4, 2014

... the digital output(AES, COAX and TOSLINK) ...

Is the coax connector RCA or BNC?

jerry

ted_b · January 4, 2014

Paul, Looks like you got it covered. You and your video and SPDIF multichannel needs (lossy?..not according to your spec that all connections play DSD, but SPDIF will not play 5.1 DSD nor 24 bit PCM multichannel) are not a candidate for replacing your multiple servers with a single lightning solution. Did you expect it would?

The Aries is like a specialized MPD Auraliti black box that features minimalist design, plug and play, dedicated music OS and player that offers theoretically better sonics (due to 100% of its processes dedicated to music and network serving, not spreadsheets, video or gaming work) and a highly tweaked DSD bandwidth handler (wifi and wired), among other things. Your setup, Paul, is much more complex than what this product and thread are all about. But with that complexity comes all sorts of potential gremlins. For example, I count at least 12 physical cable connections in your setup, and handshakes galore. Three multipurpose OS's, etc. It is a testament to you, Paul, for making this all work. Some folks don't have that in them....but want uninterrupted DSD in their living room and have their NAS in their home office. All without much care and feeding. At least that's the picture.

jtwrace · January 4, 2014

The firmware and control software will upgrade monthly at least for bug fix and performance improvement. New functions will be introduced each quarto, we have some in plan such as AirPlay, build-in uPnP server(read attached USB disk), more radio services. The DSD up sampling is in the plan but not first priority. Maybe end of 2014 is a reality timeline.

Thank you very much for the honesty. There is nothing worse then being under delivered as a paying customer.

Perhaps, I will go ahead with my Mini purchase but also purchase this so I can go along with the development. Not a bad decision to have to make. I look forward to hearing and seeing more after CES.

Good Luck to you at CES and safe travels.

Miska · January 4, 2014

In VoIP, RTCP or a similar protocol is used, primarily to control Quality of Service (QoS).

RTCP is not used for VoIP and video calls. VoIP and video calls are designed to be able to tolerate packet loss, that's why they are designed to have packet loss concealment algorithms and such. If you have 100 ms cross-Atlantic latency, you cannot afford to do retransmissions because the roundtrip is too long and the available network bandwidth usually doesn't allow it...

You need to have some latency in RTP jitter buffer, because of possible out-of-order packet arrival. SIP + SDP is the most used protocol to control calls and set up RTP media.

Let me know of the RFC and section if I have overlooked some part...

By quick glance I can see packet loss detection in RFC1889, but not retransmission request (since UDP would require such since it is unreliable by itself).

Paul R · January 4, 2014

Remember, we are talking about Audio/Video here, not just VoIP, however, I know that Cisco VoIP and Mitel VoIP will retransmit lost packets a certain number of times. Advantages of not using just SIP protocol I suppose.

But more on track, RTP payloads for H.264 video most definitely support retransmission, that would be RFC 6184 I think. Also, the basic RTP protocol is in RFC 3550, and I am pretty sure retransmission is in there when they start talking about translators. I'm on my phone right now or I would check that, but it is somewhere around section 7. RFC 3551- RTP with minimal control does not support retrains so far as I know, but it might.

The point is, it is misleading to say using UDP vice TCP precludes error checking, reordering, or retransmitting the packets delivered. Those functions are simply moved into a higher level protocol like RTP (RTCP), etc.

-Paul

RTCP is not used for VoIP and video calls. VoIP and video calls are designed to be able to tolerate packet loss, that's why they are designed to have packet loss concealment algorithms and such. If you have 100 ms cross-Atlantic latency, you cannot afford to do retransmissions because the roundtrip is too long and the available network bandwidth usually doesn't allow it...

You need to have some latency in RTP jitter buffer, because of possible out-of-order packet arrival. SIP + SDP is the most used protocol to control calls and set up RTP media.

Let me know of the RFC and section if I have overlooked some part...

By quick glance I can see packet loss detection in RFC1889, but not retransmission request (since UDP would require such since it is unreliable by itself).

Paul R · January 4, 2014

Hi Ted - I do not think it is all that complex or that much effort to build.

Still, it is a heck of lot easier than designing and building DR sites.

-Paul

bmoura · January 4, 2014

Mr Wang. Thanks for being on this thread and providing some good mfg'er feedback and q&a.

I will be at CES also, and will head over to this demo asap. I am very interested in:

* compatibility with all DSD-capable DACS (as has been already brought up, what if Linux driver incompatibility with DAC) especially, in my world, Chord, exaSound, Meitner, Mytek, MSB, etc.

* adding an additional voice for the re-prioritizing of multichannel (Kal, Brian, you guys with me? ) and DSD128 upsampling

Agreed on the need for Multichannel download support !

Miska · January 4, 2014

The point is, it is misleading to say using UDP vice TCP precludes error checking, reordering, or retransmitting the packets delivered. Those functions are simply moved into a higher level protocol like RTP (RTCP), etc.

Well regardless of retransmissions you also need some way of flow control to support recipient side clocking and then you pretty much end up reimplementing TCP. Of course it is technically possible to put all the reliability on top of UDP, but then it becomes more heavy than TCP and it's not anymore serving the purpose UDP was originally designed to provide (unreliable lighweight datagram protocol). And then it's not anymore something widely supported by high quality audio and video streaming...

UPnP theoretically supports RTSP, but I'm yet to see it widely supported. All I've seen to the date rely on HTTP.

Kal Rubinson · January 4, 2014

Agreed on the need for Multichannel download support !

We should plan a multichannel intervention at CES.

Auralic Aries UPnP Renderer: Double DSD Over Wi-Fi

Recommended Posts

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Create an account or sign in to comment

Create an account

Sign in