As an IP-based solution, RAVENNA is based on protocol levels on or above Layer-3 of the OSI reference model.
IP can be transported on virtually any LAN and is used as the base layer for communication across WAN connections (including the internet). Although Ethernet will be deployed in most
cases as underlying data link layer, IP is in general infrastructure-agnostic and can be used on virtually any network technology and topology.
While simple streaming across a network can be achieved without any synchronization at all, in pro audio applications a tight synchronization between all devices and streams is absolutely
mandatory. While playback synchronization in most applications requires sample accuracy, it has been the goal for RAVENNA to optionally provide superior performance by providing
phase-accurate synchronization of media clocks according to AES-11; this would render the separate distribution of a reference word clock throughout the facility or venue obsolete.
In RAVENNA, synchronization across all nodes is achieved through IEEE1588-2008 (Precision Time Protocol - sometimes referred to as PTPv2), another standard protocol which can be operated
on IP. PTPv2 provides means for synchronizing local clocks to a precision in the lower nanoseconds range with reference to a related master clock - provided that all participating
switches natively support PTPv2. But even without native PTP support, the achievable precision - while varying depending on size and bandwidth utilization of the network - will be more
than sufficient to reach sample accurate synchronization across each node.
Sample-accurate synchronization can even be reached across WAN connections, when local master clocks are synchronized to GPS as a common time domain.
As IP has been chosen as a basis, it's only natural to use RTP for streaming of media content.
RTP - the real-time transport protocol, as defined by the IETF is widely used and supported by numerous applications and comes with a large number of standardised payload formats.
For RAVENNA, specifically RTP/AVP over UDP together with RTCP (the real-time transport control protocol) according to RFC 3550 is used. This provides the possibility to transport any
RAVENNA stream across IP-based WAN connections. Basic payload formats for audio are 16 and 24-bit @48 kHz with any desired number of channels. This would allow any standard media player
to potentially link to a RAVENNA stream and monitor its content - even without knowledge or support of any of the other RAVENNA-specific features or methods. Of course the payload format
is not restricted to those basic formats as with RTP a huge variety of different payload formats for audio and video is already defined; it is even is supported both in unicast and
multicast mode on a per-stream basis providing the highest flexibility to match the distinct requirements of different applications. Unicast is preferred in situations where a certain
stream needs to be transported to a single destination only or where the network infrastructure or application prohibits the use of multicast (e.g. across most WAN connections). On the
other hand, multicast allows resource-efficient usage of network links and faster switching between available streams in situations, where a certain stream will be accessed at different
locations.
As different services can co-exist with RAVENNA on the same network, it has to be ensured that the traffic related to RAVENNA will be expedited with priority across the network.
For IP-based traffic, several QoS schemes have been defined as standard over time. Today, DiffServ has largely supplanted other Layer 3 QoS mechanisms (such as IntServ) as the primary
protocol to provide different levels of service and is widely supported by most modern managed switches. DiffServ operates on the principle of traffic classification, where each data
packet is placed into a limited number of traffic classes, rather than differentiating network traffic based on the requirements of an individual stream. Each traffic class can be managed
differently, ensuring preferential treatment for higher-priority traffic on the network.
Even within RAVENNA there are different priorities assigned to different classes of traffic: while traffic related to synchronization receives highest priority, immediately followed by
any real-time media traffic, control and configuration traffic will be on a lower priority level. Any non-RAVENNA traffic would receive the lowest (standard) priority and will be treated
as best-effort traffic.
A receiver can connect to any existing stream through RTSP / SDP protocol. Again, this scheme is supported by most common media players. While RTSP is used for control communication between receiver and sender, the SDP record contains any relevant information about one or more streams - like stream name, payload formats, number of channels, access information etc. Although a typical RAVENNA SDP contains some specific extensions (i.e. clock domain and sync information), any non RAVENNA-aware media player can still receive and play-out a RAVENNA stream by just ignoring the specific extensions.
In order to participate in an IP-based network communication, a device must obtain a unique IP address. Then, in order to be recognized by other RAVENNA nodes, a device must announce its existence and advertise information about available services (e.g. IP address and host name, supported protocols, access information, information about available streams etc.). Service advertisement & discovery is based on the DNS-SD protocol. In order to support a wide range of application environments, RAVENNA supports two different methods for device configuration and service advertisement & discovery: In managed networks usually DHCP and DNS services are operated under management and control of a network administrator. In small networks, where usually no DHCP / DNS server is present, the zeroconf mechanism - a fully automatic, self-configuring method - will be used for auto-IP assignment and service advertisement & discovery.
RAVENNA offers a highly flexible latency scheme, ranging from very low latency numbers in the sub-milliseconds area up to latency numbers large enough to suit the constraints of a WAN
infrastructure. Unlike in other solutions, RAVENNA does not force the latency to system-wide defaults. In fact, the latency can be set for any stream individually and depends on a number
of factors:
- Network infrastructure - since RAVENNA is based on IP, virtually any network infrastructure supporting IP transport can be used. Thus, transport speed and latency numbers scale directly with the performance parameters of the underlying network infrastructure. Although Fast Ethernet is supported, the use of Gigabit Ethernet (at least for the backbone links) is recommended. As faster network technologies get available, RAVENNA can gain direct advantage from them.
-
- Packetization factor - as samples are grouped into packets before they enter the network, the number of samples per packet is directly influencing the latency, where less samples per packet result in a smaller latency. RAVENNA allows packets with just one sample per channel; however, this usually results in higher bandwidth utilization (due to framing overhead) at the expense of stream count.
-
- Network jitter - although packets containing the payload data are generated and inserted into the network at a relatively stable and isochronic rate, they usually tend to arrive intermittently at their destination due to the influence of competing traffic on their way through the network. This is compensated for by a jitter buffer on the receiver side, which must be large enough to account for the maximum expectable delay variation. In order to minimize the negative influence of interfering traffic, RAVENNA supports the use of IP-based QoS schemes. The use of DiffServ (DSCP) is highly recommended as it is supported by most managed switches and requires only very moderate administrative interaction as most switches already come with a pre-configured setup for DSCP support.
-
- Play-out correlation between streams - as the exact play-out time of different streams can be correlated - even across different devices in the network - latency of all affected streams needs to be increased to match the maximum latency of all related streams.
-
- Front-end or back-end data processing - although RAVENNA-related latency is understood to account for all above mentioned network-related factors, a device usually adds additional processing latency (e.g. A/D or D/A conversion, DSP functions etc.), which contributes to the overall end-to-end latency. In certain setups this device-specific latency can be taken into account when calculating the different stream-related latencies in a correlated play-out scenario. Latency can be configured independently for each individual stream. However, in order to simplify latency configuration, a RAVENNA setup may offer generic latency presets (e.g. small, medium, large) from which the latency of any individual stream may be selected. The corresponding numbers can be set by a system designer or network administrator.
A fundamental part of the Ravenna standard is the almost limitless configuration options that allow you to fine tune network audio streams between devices to best suit the application and hardware involved. In order to assist with operation and choice of these configuration options the concept of profiles has been designed. All Ravenna devices must have the ability to connect using a ‘generic’ profile which has been defined as follows:
- Channels - 1-8 (should this be 2 or 8?)
- Bit depth (word length) - 16 or 24
- Sample frequency - 48kHz
- Frames per packet - ?
- Generic profile
- Ultra-low latency profile
- AES67 profile
- High performance profile
|
|
|
|
