Ravenna Streamer?

[tranz]

With the first consumer LAN input DAC showing up on shows with the NADAC, is there a way to still use our streamers?

 

Is there already a streamer that will communicate using the Ravenna protocol? Anything planned? Will it be an improvement?

 

The Ravenna protocol used in NADAC : http://www.merging.com/uploads/assets/Merging_pdfs/Horus/Merging%20Ravenna%20Network%20Guide%20V8%20rev7.pdf

 

Cheers

[Cebolla]

The majority of current network audio players/renderers (eg UPnP/DLNA, Squeezebox, etc) actually benefit from not having to consider network timing problems impacting on sound quality, as they only stream non-realtime audio file data.

 

Unfortunately, the Ravenna protocol appears to use the network to actually stream realtime digital audio signals, so has the added burden of accounting for jitter over the network. It will most likely require robust 'pro' network hardware to implement, so the user will no longer be able to get away with using a cheap consumer grade components for the majority of the network infrastructure.

 

Do we really want to open up this can of worms again? Eg:

http://www.computeraudiophile.com/f22-networking-networked-audio-and-streaming/synce-ethernet-real-timing-17212/

[One and a half]

Ravenna is no different to an interconnect, it provides a path through a myriad of network devices from point A to B without a sync pulse. All is not lost as far as jitter is concerned though. Pro devices use a Word clock to sync timing on any number of devices at the same time otherwise you end up with a real mess of different Word clocks on each device creating their own timing. Makes things impossible to monitor, echoes all over the place for one.

 

 

Quote from Page 8 of the pdf:

 

"A Ravenna system requires a carefully configured IP network, a master clock device and any number of Ravennaenabled I/O nodes. The master clock can be either a dedicated device or any Ravenna node capable of serving as a

grandmaster. The preferred time domain reference is GPS. Simple streaming across a network can be achieved

without any synchronization at all but in pro audio applications tight synchronization between all devices and

streams is absolutely mandatory. While playback synchronization in most applications requires sample accuracy,

one goal for Ravenna is to provide superior performance by offering phase-accurate synchronization as an option

thus rendering separate reference word clock distribution throughout a facility or venue redundant."

 

Word clocks typically are short distance devices like 2m max, so how does the Word clock sync to nodes which maybe 100m away, a question I'd liked answered.

 

 

There's a clue here on page 43

 

"PTP sync does not permit synchronization to word clock or an audio input. However, this is not an issue since all Horus' will be synchronous. Only one Horus can lock to an external source; it then becomes the PTP master; other Horus’ switch automatically to PTP slave (see Horus User Manual)."

 

Would this occur with a NADAC, to become the master clocking device. Hrrmm, looks like there is more to Ravenna than just the Ethernet Hardware side of things. Would a non Merging Ravenna device work with all this?

 

Where is all this going? Geez, just give a simple AES3 out of computer to play music.

[tranz]

The majority of current network audio players/renderers (eg UPnP/DLNA, Squeezebox, etc) actually benefit from not having to consider network timing problems impacting on sound quality, as they only stream non-realtime audio file data.

 

Unfortunately, the Ravenna protocol appears to use the network to actually stream realtime digital audio signals, so has the added burden of accounting for jitter over the network. It will most likely require robust 'pro' network hardware to implement, so the user will no longer be able to get away with using a cheap consumer grade components for the majority of the network infrastructure.

 

Do we really want to open up this can of worms again? Eg:

http://www.computeraudiophile.com/f22-networking-networked-audio-and-streaming/synce-ethernet-real-timing-17212/

 

Thanks Cebolla, I had not seen that thread. Guess we need a Roon for mining audio forum threads for all the duplication of conversations.

 

The embedded timing makes sense from an audio studio perspective when you are trying to lock/sync multiple sources and destinations at once. Perhaps for multi-room, multi-channel playback it could help as well. For just stereo playback perhaps not as much. The clock is listed as 1 nanosecond for the NADAC, which is not even in the same building as the femtoclocks on some of the streamer setups.

 

I am looking for that perfect digital playback, and who knows whether the impact of a more efficient stack is better than UPnP. I hear people, especially those having to code, complain about UPnP and even more so DLNA, but in the end for me the audio quality, accurate clock and lack of electrical noise is of utmost importance. It the streamer receiving chip has to work less to get the data through a better protocol then that might be beneficial. Similar impact I guess to the network isolation discussion on another thread.

 

Cheers

[tranz]

Ravenna is no different to an interconnect, it provides a path through a myriad of network devices from point A to B without a sync pulse. All is not lost as far as jitter is concerned though. Pro devices use a Word clock to sync timing on any number of devices at the same time otherwise you end up with a real mess of different Word clocks on each device creating their own timing. Makes things impossible to monitor, echoes all over the place for one.

 

 

Quote from Page 8 of the pdf:

 

"A Ravenna system requires a carefully configured IP network, a master clock device and any number of Ravennaenabled I/O nodes. The master clock can be either a dedicated device or any Ravenna node capable of serving as a

grandmaster. The preferred time domain reference is GPS. Simple streaming across a network can be achieved

without any synchronization at all but in pro audio applications tight synchronization between all devices and

streams is absolutely mandatory. While playback synchronization in most applications requires sample accuracy,

one goal for Ravenna is to provide superior performance by offering phase-accurate synchronization as an option

thus rendering separate reference word clock distribution throughout a facility or venue redundant."

 

Word clocks typically are short distance devices like 2m max, so how does the Word clock sync to nodes which maybe 100m away, a question I'd liked answered.

 

 

There's a clue here on page 43

 

"PTP sync does not permit synchronization to word clock or an audio input. However, this is not an issue since all Horus' will be synchronous. Only one Horus can lock to an external source; it then becomes the PTP master; other Horus’ switch automatically to PTP slave (see Horus User Manual)."

 

Would this occur with a NADAC, to become the master clocking device. Hrrmm, looks like there is more to Ravenna than just the Ethernet Hardware side of things. Would a non Merging Ravenna device work with all this?

 

Where is all this going? Geez, just give a simple AES3 out of computer to play music.

 

Hi One and a half,

 

Thanks. That last bit already exists. Full circle on the Lynx card on this forum?

 

http://www.lynxstudio.com/product_detail.asp?i=72

[One and a half]

Hi One and a half,

 

Thanks. That last bit already exists. Full circle on the Lynx card on this forum?

 

E44

 

Ah yes, I seriously looked at the E44 and its mate E22 the 2Ch model. There's an inbuilt DAC which output levels you can set manually via trimpots. You would have to do this live in the PC, with a plastic screwdriver, I'm sure if you have a metal one and accidentally dropped it... also thought about extra analog gear that wasn't going to be needed and possibly prone to interference, so decided against these two.

 

To receive an AES3 output, there's an RME HDSPe AIO being delivered next week out of Holland that will fit in a slot in the HP Z800. This will remove USB out of the picture totally, and the RME clocking mechanisms look pretty good for an S/PDIF output. The card supports ASIO out of the box, so apps like Jriver, HQPlayer integration is seamless.

 

I do think the (upcoming) Uptone Audio Ethernet Bridge to provide a path between the Ravenna type (over the top for home) superstructure and streaming. There are USB over IP solutions about, but I could not get any of them to work reliably for audio. Goodness knows what protocol they used to imbed clock data if at all.

 

What we're after here is a simple routable (local) transmission method that imbeds clock data with 'some' protocol that supports Quad DSD and PCM to 358KHz... not much to ask for, hey?

[Serge_S]

Unfortunately, the Ravenna protocol appears to use the network to actually stream realtime digital audio signals, so has the added burden of accounting for jitter over the network.

Doesn't Ravenna transmit IP packets? Where would jitter come from?

[Cebolla]

Sorry, Serge_S, I don't follow the logic of your questions. Are you actually suggesting that Ravenna's method of ovecoming any jitter issues with the realtime audio signal is by it transmitting IP packets?

[Cebolla]

I am looking for that perfect digital playback, and who knows whether the impact of a more efficient stack is better than UPnP. I hear people, especially those having to code, complain about UPnP and even more so DLNA, but in the end for me the audio quality, accurate clock and lack of electrical noise is of utmost importance. It the streamer receiving chip has to work less to get the data through a better protocol then that might be beneficial. Similar impact I guess to the network isolation discussion on another thread.

Fair enough, Tranz. I'm just sceptical of any system that places even further audio signal timing complexity and physical distance between the audio file player/decoder and the DAC. Seems to me what the DAC & player designers should be concentrating on is the complete opposite.

[Serge_S]

Sorry, Serge_S, I don't follow the logic of your questions. Are you actually suggesting that Ravenna's method of ovecoming any jitter issues with the realtime audio signal is by it transmitting IP packets?

Hi Cebolla. I believe by real-time audio they refer to all the devices being able to receive traffic simultaneously and with minimal latency, but they do not actually transmit digital audio signals. Thanks, Serge

[Superdad]

Are you actually suggesting that Ravenna's method of ovecoming any jitter issues with the realtime audio signal is by it transmitting IP packets?

 

To clear gang:

Ravenna is based on AES67, which is a standard for audio-over-IP interoperability. It is a layer 3 (Network layer) protocol. Instead of using TCP, it uses RTP (that's based on UDP), and that allows for use of IP-multicast (one-to-many or many-to-many). So again, this is all still packet-based transmission and the "payload" data can take many routes.

 

Just want to be sure that nobody thinks this is some new transmission method for audio on Ethernet cables. Still in IP/packet-land. Nothing wrong with that, it is just that there is no revolution going on here.

 

That said, it is nice to see Ravenna/AES67 coming to a consumer DAC (from Merging) with s/w that allows it to work with some popular operating systems and player apps.

I'm curious to know what audio player apps like HQ Player. Audirvana+, and XXHigh-End will make of the NADAC/Ravenna driver s/w.

 

--Alex

[jabbr]

 

Just want to be sure that nobody thinks this is some new transmission method for audio on Ethernet cables. Still in IP/packet-land. Nothing wrong with that, it is just that there is no revolution going on here.

 

 

Yeah it specifies a Dell (or whatever) switch that does ... now everybody sit down ... QoS. Not that there is anything wrong with that :) In any case my own home network is designed to store and serve multimedia all over the house. Multiple 1080p (or eventually 4K) streams to different devices simultaneously. So clearly there's a lot that's already been done in this area off the shelf.

 

I don't think Audirvana is playing in the streaming space. HQPlayer with NAA already has this nailed. Nothing for Ravenna to add (IMHO). Can't comment on XXHighEnd ... but would be willing to if a NOS1a happened to show up on my doorstep

[Superdad]

I don't think Audirvana is playing in the streaming space. HQPlayer with NAA already has this nailed. Nothing for Ravenna to add (IMHO). Can't comment on XXHighEnd ... but would be willing to if a NOS1a happened to show up on my doorstep

 

What I meant is that I wonder about the compatibility between the Merging's Ravenna software (the stuff that makes their NADAC look to the OS and apps like another sound output "card") and player apps like those mentioned which have their own OS-workarounds to allow them to shine. In other words, will an HQ Player or A+ user be able to output to a Ravenna network DAC?

If not, then while it is a different topology, it is no more interesting to me than DLNA/UPnP solution.

[bibo01]

What I meant is that I wonder about the compatibility between the Merging's Ravenna software (the stuff that makes their NADAC look to the OS and apps like another sound output "card") and player apps like those mentioned which have their own OS-workarounds to allow them to shine. In other words, will an HQ Player or A+ user be able to output to a Ravenna network DAC?

If not, then while it is a different topology, it is no more interesting to me than DLNA/UPnP solution.

Of course HQPlayer or A+ are able to output to a Ravenna network DAC, in Core Audio or ASIO.

Here with Hapi:

[Distinctive]

Just a small comment about the Ravenna being UDP multicast or unicast based.

This also means that any packet loss will not be remedied, i.e. there is no re-transmission due to e.g. network congestion as you find with TCP.

[Cebolla]

Serge (& Alex),

Hi Cebolla. I believe by real-time audio they refer to all the devices being able to receive traffic simultaneously and with minimal latency, but they do not actually transmit digital audio signals. Thanks, Serge

To clear gang:

Ravenna is based on AES67, which is a standard for audio-over-IP interoperability. It is a layer 3 (Network layer) protocol. Instead of using TCP, it uses RTP (that's based on UDP), and that allows for use of IP-multicast (one-to-many or many-to-many). So again, this is all still packet-based transmission and the "payload" data can take many routes

Ok, I see now what you were referring to and I certainly did not mean to imply that Ravenna wasn't using IP. I also didn't mean that Ravenna wasn't using a standard layered network protocol stack for that matter (as Superdad appears to have picked up on). Sorry for any confusion guys

 

What I was attempting to point out in my first post is that the Ravenna model uses the network between the audio file player and DAC, whereas the majority of current music file streaming devices use the network between audio file storage device and audio file player (ie the streaming devices are the audio file players).

 

Ravenna uses the network to carry the (realtime) digital audio signal, so the DAC is subject to any network timing issues and Ravenna needs to account for this. On the other hand the streaming devices (network audio players/renderers/streamers) I mentioned use the network to carry audio file data (ie, non-realtime and yet to be decoded to a digital audio signal), so any DAC further down the chain is not subject to network timing issues.

 

Hope this has clarified things.

 

John

[Cebolla]

Edit: deleted.

[Superdad]

What I was attempting to point out in my first post is that the Ravenna model uses the network between the audio file player and DAC, whereas the majority of current music file streaming devices use the network between audio file storage device and audio file player (ie the streaming devices are the audio file players).

 

Ravenna uses the network to carry the (realtime) digital audio signal, so the DAC is subject to any network timing issues and Ravenna needs to account for this. On the other hand the streaming devices (network audio players/renderers/streamers) I mentioned use the network to carry audio file data (ie, non-realtime and yet to be decoded to a digital audio signal), so any DAC further down the chain is not subject to network timing issues.

 

That's better; Glad we are on the same page John.

That's also what I was alluding to (barely because I was really tired) in post #13 above when I mentioned topology. I was trying to find the words you did with regards to the push versus pull model differences between DLNA renderers (pulling files) and something like Ravenna, AirPlay, or Signalyst NAA where the device gets packetized audio "pushed" to it.

 

A potential advantage to the latter is that the Ethernet input of the DAC does not have to be an "intelligent," programmed processor. Perhaps more importantly, an Ethernet-input DAC that does not have to be a full "renderer" depends only on the s/w and drivers at the end (the computer), and does not burden the DAC maker quite as much with ongoing support for the hardware. I know that is a generalization, and indeed some of the standardization and market penetration of DLNA has made the above a little easier. But still, look at the struggle a lot of companies have in implementing trouble-free DLNA/UPnP. I think you know this more than most.

 

All that said, I think Ravenna/AES67 has to make it out into the real world and in a number of products before it can be judged one way or another. If it indeed has stringent network switch and wiring requirements, those might become a deal-breaker for wide acceptance Not everyone has a QoS configurable switch--and if they do, do they know how to configure it? If Ravenna proves more challenging than DLNA (i.e. is not a totally easy, plug-and-play solution), then I don't expect it to gain significant market-share.

 

Sort of brings me back to my now-old rant on just how much Apple screwed up by keeping Airplay so closed, expensive, and data-format constrained. Because the user side of it is the easiest thing imaginable.

 

Have a great weekend,

--Alex C.

[Miska]

That said, it is nice to see Ravenna/AES67 coming to a consumer DAC (from Merging) with s/w that allows it to work with some popular operating systems and player apps.

I'm curious to know what audio player apps like HQ Player. Audirvana+, and XXHigh-End will make of the NADAC/Ravenna driver s/w.

 

I believe there's an ASIO and CoreAudio driver available. But I personally don't want to touch RTP with a yard long stick... I've seen enough of it for this life while working on VoIP for mobile phones...

[Miska]

Ravenna is no different to an interconnect, it provides a path through a myriad of network devices from point A to B without a sync pulse. All is not lost as far as jitter is concerned though. Pro devices use a Word clock to sync timing on any number of devices at the same time otherwise you end up with a real mess of different Word clocks on each device creating their own timing. Makes things impossible to monitor, echoes all over the place for one.

 

Challenge with word clock is that it's a slow speed (typically 44.1k) clock, while modern DAC chips need high stability high speed clock. With PCM inputs, ESS Sabre needs up to 100 MHz MCLK. Trying to keep such clock stable while syncing to a slow speed clock like WCLK is challenging. Distributing a 10 MHz atomic clock frequency is already a closer solution. Generating a low jitter clock with a clock multiplier is very tricky...

[Serge_S]

Ravenna uses the network to carry the (realtime) digital audio signal, so the DAC is subject to any network timing issues and Ravenna needs to account for this.

John, do you mean to say that Ravenna encodes clock with audio signal similar to AES/EBU? Thanks

[bmoura]

I believe there's an ASIO and CoreAudio driver available. But I personally don't want to touch RTP with a yard long stick... I've seen enough of it for this life while working on VoIP for mobile phones...

 

Right. The NADAC provides drivers with ASIO and Core Audio over Ethernet. That is how testers of the NADAC are running it with current music players like JRiver.

[One and a half]

Challenge with word clock is that it's a slow speed (typically 44.1k) clock, while modern DAC chips need high stability high speed clock. With PCM inputs, ESS Sabre needs up to 100 MHz MCLK. Trying to keep such clock stable while syncing to a slow speed clock like WCLK is challenging. Distributing a 10 MHz atomic clock frequency is already a closer solution. Generating a low jitter clock with a clock multiplier is very tricky...

 

Oh, I thought the Word Clock would match the sampling frequency to keep up somehow. Hmm a 44.1kHz needs then several iterations to say sync with a 96KHz pulse train, that alone is difficult, can see that. Or you have one super clock that does say 10MHZ, then gear down to whatever sampling frequency is going with the transmission, another tough ask.

 

I gather no one transmits at 10MHz MCLK across Ethernet?

[Distinctive]

The industrial approach is IEEE 1588 PTP:

[Serge_S]

Just a small comment about the Ravenna being UDP multicast or unicast based. This also means that any packet loss will not be remedied, i.e. there is no re-transmission due to e.g. network congestion as you find with TCP.

Pro-audio networks are isolated, so, if designed properly, shouldn’t be any congestion. For majority of audiophile use it would just be PC directly connected to D/A via CAT5e. Regular consumer wants wireless streaming, so Ravenna is of no use there methinks. Serge