NOW! 12-13 - Telos

More documents

Recommendations

Info

AXIA | NETWORKING | TECHNOLOGY ARTICLE 100 AoIP IN BROADCAST ENGINEERING » Livewire’s patented synchronization iltering algorithm in slave devices ensures exceptional stability in presence of network jitter, and works equally well both with the original Livewire sync protocol and the IEEE 1588 (PTP) standard. Un- der certain conditions, Livewire networks can achieve better sync performance than IEEE 1588 alone would deliver. » IP multicast-based routing ensures eficient one-to-many connectivity, as well as instant setting up, rerouting, and clearing of individual connections. » Advanced device and source discovery protocol ensures RAVENNA instant availability of dynamically changing data through- out the network. RAVENNA (an acronym for Real-time Audio Video Enhanced Next-generation Networking Architecture) is a new offering from Lawo, the German manufacturer of ultra-high end broadcast consoles. Just recently they have started to demonstrate real device prototypes. From the fundamental technology viewpoint, in the area of pro audio, RAVENNA is actually making a second round on the basis of IETF documents. Although it has its own independent roots, this effort essentially results in a generalization of the Livewire solution. RAVENNA follows exactly the same way of thinking as does Livewire, which is to say that it is aimed at building open systems on the basis of widely adopted public standards – so it’s not a surprise that they, too, are building their technology on IP, UDP, RTP, and the related protocols. There is a difference in the business model though: » The Livewire project has been focused on bringing a practi- cal solution to market since its very inception. It was pri- marily designed for a speciic product line, although fully recognizing the value of being standards-based and open. The focus on a product resulted in selecting a technically suficient, and at the same time economically justiied, functionality set. This precisely deined functionality is con- sistently supported across the entire Livewire product line, ensuring universal interoperability. » Unlike Livewire, RAVENNA started from offering a highly generic speciication, which taken alone can not effectively ensure multi-vendor interoperability due to too many vari- ables that are left unresolved in the framework. This will be addressed by means of providing precisely deined interoperability proiles – a work currently in progress. As to the actual technical differences in the application overlap area, there is not much to speak about. Besides allowing multiple interoperability proile deinitions, the biggest difference is the selection of a synchronization method. While Livewire uses its own synchronization protocol, RAVENNA has selected the IEEE 1588 (PTP) standard, which simply did not exist yet at the time Livewire was developed. However, today even this difference starts to disappear, as Livewire has introduced support for IEEE 1588 beginning with the debut of Axia’s xNodes. And of course, Livewire retains the option for users to operate with its original sync protocol as well. To put all this into context, in terms of the RAVENNA framework, the audio streaming part of Livewire would correspond to a speciic proile. Paradoxically, if such a proile were deined, at the time this is written, Livewire would be the only existing RAVENNA proile that is implemented in real products, widely deployed and ield-proven. There is also open speciication work in progress yet, especially at the higher application layers of RAVENNA. OTHER AoIP TECHNOLOGIES? Thanks to the popularity of Livewire, some companies have announced their own competing AoIP protocols, but these are closed, proprietary solutions, and information about them is limited. None have achieved wide acceptance in broadcasting. » Dante: 100Mb or Gigabit Ethernet, IEEE 1588-2002, UDP unicast or multicast, 48/96/192kHz sampling rates, 24-bit proprietary coding, Bonjour discovery » Q-LAN: Gigabit Ethernet or higher, IEEE 1588-2002, UDP unicast, 48kHz sampling rate, 32-bit loating proprietary coding, proprietary discovery protocol » WheatNet: Gigabit Ethernet, UDP multicast, 48/44.1kHz sampling rate, 24-bit RTP coding THIS IS NOT AoIP! Ethernet is not AoIP. Probably the biggest point of confusion for those seeking an AoIP solution is confusing Ethernet with IP, since they are nearly inseparable. But there is a signiicant difference between technologies built on the IP layer (layer 3) and those implemented directly on the Ethernet data link layer (layer 2), or even the Ethernet physical layer. The biggest difference is that non-IP technologies are not routable, signiicantly limiting their usefulness. For example, none of these otherwise great technologies are AoIP, even though they use an Ethernet transmission link: » Cobranet – legendary for its time and niche, but it is an Eth- ernet layer-2 technology » AES50 – Ethernet layer-1 » Ethersound – Ethernet layer-2 » AVB – Ethernet layer-2 AVB is not AoIP. Surprised by this? Even with the understanding that AVB is not AoIP, it is often touted as a possible replacement, or even a superior technology. While AVB is a great advancement in the area of audio streaming, designed to deliver high-resolution audio at a guaranteed low latency, it’s a pretty tricky proposition for the system engineer willing to build an AVB application.
TECHTALK BLOG TELOSALLIANCE.COM/BLOG AVB claims to be an inherent capability of standard networking equipment, implying that, unlike AoIP, AVB would not require an engineered network. But when you look closely, this seemingly huge advantage starts fading. Support of IEEE 802.1AS (subset of IEEE 1588) is mandatory in all switches and terminal devices. Support of IEEE 802.1Qat, the Stream Reservation Protocol (SRP), is mandatory too. Since AVB trafic cannot be routed through network equipment that is not AVB-enabled, it effectively still requires an engineered network – at least in terms of careful selection of the switch models (until such time as AVB is included in all industrially made switches). And even with all AVB-enabled network equipment in place, signiicant restrictions remain. AVB is layer-2, not routable, so the audio trafic cannot pass the boundaries of LAN subnets. Don’t even think about WAN links. And only 75% of the bandwidth can be reserved for actual AVB trafic. While generally this kind of a restriction makes sense for mixed-application networks, it robs 25% of the bandwidth from a dedicated audio setup. WHAT’S IN AoIP’S FUTURE? No one can say for sure. But there are some things peeking over the horizon that are worth mentioning. INTEROPERABILITY The value of a networking technology is only as great as the number of devices it allows to interconnect. Users and manufacturers realize this – several interoperability initiatives have appeared, and some of them have already produced useful results. These initiatives indicate a new level of AoIP evolution. EBU – ACIP project: The Audio Contribution over IP (ACIP) project lead by the network division at EBU, is perhaps the earliest major initiative that has already produced practically useful results. Recognizing the fact that more and more equipment is using IP links for audio contribution, EBU launched a project group in 2006 to develop minimum interoperability requirements for devices interconnected via IP. Agreement on a common standard was reached in September of 2007. The standard is based on a number of IETF documents, in particular RTP over UDP for audio streaming, and SIP for session management. It also deines a number of mandatory audio codecs to be supported by all compliant devices, as well as a number of recommended codecs. The project proved to be successful – most of the manufacturers taking part in the plug tests in 2009 appeared compatible. AES – X.192: The effort started by the EBU ACIP project is logically continued by the AES X.192 high-performance AoIP interoperability project, attempting to reconcile the existing in-facility AoIP networking solutions. This project has chosen an approach to identify an area of overlap, where the different technologies might be able to interoperate, hopefully with no, or minor enhancements. A task group, of which Axia is a BROCHURES AXIAAUDIO.COM/BROCHURES SOFTWARE UPDATES AXIAAUDIO.COM/DOWNLOADS member, has been created and is working on a draft document. More information can be read at www.x192.org. NRJ Networks, Paris World’s largest AoIP mixing console? Likely. This 36-position, 28-fader Axia Element is in the master control room of NRJ Networks, Paris. WIDE-AREA AoIP NETWORKS Network bandwidth and latency, and (to some extent) the processing power of network devices are the main factors limiting AoIP applications. But these factors are also the ones we can observe evolving quickly and steadily. The cost of processing power is reasonably low, and keeps dropping, allowing network devices to become faster as well as functionally more capable. Huge amounts of bandwidth are added to backbone links worldwide every month; more and more connections get upgraded to high-speed copper and optical links, and new wireless technologies cover low-density areas. This stimulates services that were originally conceived for use only on a LAN to break the walls of the closed networks and go out to the WAN. MPLS (Multi-Protocol Label Switching) is a technology that helps greatly here. Although MPLS doesn’t create new bandwidth, it allows utilizing WAN bandwidth for LAN protocols and applications without any redesign of the latter. It is capable of tunneling Ethernet frames to transparently link distant clusters of a virtual LAN. The Virtual Private LAN Service (VPLS) is well known and widely deployed, but has yet to ind its way into broadcast applications. When backbone networks build up suficient FIND A DEALER AXIAAUDIO.COM/BUY IP-AUDIO STUDIO NETWORKING | AoIP CONSOLES | AUDIO INTERFACES | IP INTERCOMS | ROUTING AUTOMATION AXIAAUDIO.COM 101
Page 2 and 3:
TELOS ALLIANCE | COMPANY HISTORY 2
Page 4 and 5:
TELOS ALLIANCE | TABLE OF CONTENTS
Page 7 and 8:
TECHTALK BLOG TELOSALLIANCE.COM/BLO
Page 9 and 10:
Page 11:
Page 14 and 15:
TELOS | BROADCAST PHONE SYSTEMS 14
Page 16 and 17:
TELOS | BROADCAST PHONE SYSTEMS 16
Page 19 and 20:
Page 21 and 22:
Page 23 and 24:
Page 25 and 26:
Page 27 and 28:
Page 29 and 30:
Page 31 and 32:
Page 33 and 34:
Page 35:
Page 38 and 39:
OMNIA | RADIO PROCESSING 38 OMNIA.1
Page 40 and 41:
OMNIA | RADIO PROCESSING 40 OMNIA.9
Page 42 and 43:
OMNIA | RADIO PROCESSING 42 ONE FM
Page 44 and 45:
OMNIA | RADIO PROCESSING | APPLICAT
Page 46 and 47:
OMNIA | CODED AUDIO 46 OMNIA A/XE T
Page 48 and 49:
OMNIA | CODED AUDIO 48 OMNIA.8x EIG
Page 50 and 51: OMNIA | CODED AUDIO | APPLICATION A
Page 52 and 53: OMNIA | FM-STEREO TRANSMISSION | TE
Page 61 and 62: TECHTALK BLOG TELOSALLIANCE.COM/BLO
Page 65 and 66: + 4-Fader modules accommodate any s
Page 77 and 78: + + + TECHTALK BLOG TELOSALLIANCE.C
Page 81 and 82: Silky-smooth, side-loading 100mm. c
Page 96 and 97: AXIA | NETWORKING | TECHNOLOGY ARTI
Page 105 and 106: LINEAR ACOUSTIC Viewers are listeni
show all

NOW! 12-13 - Telos

Create successful ePaper yourself

Delete template?

Save as template?