Calrec Network Primer

Calrec Audio NETWORKING Primer

Introduction to professional audio networking

calrec.com

Putting Sound in the Picture

Published in association with

fastand wide .com

Keeping audio professionals up to speed in the fast-changing world of sound and image.

fast andwide.com

The established policy of Calrec Audio Ltd. is to seek improvements to the design, specifications and manufacture of all products.

It is not always possible to provide notice outside the company of the alterations that take place continually.

No part of this manual may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying and scanning, for any purpose, without the prior written consent of Calrec Audio Ltd.

Calrec Audio Ltd Nutclough Mill Hebden Bridge West Yorkshire England UK HX7 8EZ Tel: +44 (0)1422 842159 Fax: +44 (0)1422 845244 Email: enquiries@calrec.com calrec.com

Whilst the Company ensures that all details in this document are correct at the time of publication, we reserve the right to alter specifications and equipment without notice. Any changes we make will be reflected in subsequent issues of this document. The latest version will be available upon request. This publication is for International usage.

Despite considerable effort to produce up to date information, no literature published by the company nor any other material that may be provided should be regarded as an infallible guide to the specifications available nor does it constitute an offer for sale of any particular product.

Apollo, Artemis, Alpha, Sigma, Omega, Zeta, Hydra Audio Networking, Hydra2 and Bluefin High Density Signal Processing (HDSP) are registered trade marks of Calrec Audio Ltd. All other trade marks are acknowledged.

Calrec Audio Ltd reserve the right to change specifications without notice. E & O.E.

© 2013 Calrec Audio Ltd. All Rights Reserved.

AUDIO NETWORKING PRIMER FOREWORD

calrec.com

Putting Sound in the Picture

4

NE T WORK PRIMER

Foreword

This Primer is designed, like the Audio Primer that preceded it, to explain often complex concepts in straightforward, approachable terms. With this Network Primer, our aim was to explain the background and technology behind data networks with specific reference to its application in broadcasting, such that a broadcast engineer with no formal training in the field of computer networking technology might gain a clearer understanding of the subject.

One semantic problem should be dealt with right away: ‘network’ is a word that already had a meaning in broadcast long before the rise of affordable computer technology — particularly in the USA, where it usually refers to a broadcasting company itself. To be utterly clear and unambiguous: this Primer aims to explain the increasing use of data networking technology in broadcast applications, examines the benefits that this technology can offer forward-thinking modern broadcasters, and considers where it may take the world of broadcast in the future.

Hebden Bridge, Spring 2013

CALREC Putting Sound in the Picture

5

6

NE T WORK PRIMER

NETWORK PRIMER CONTENTS Introduction Introduction

9 11

Chapter One 13 The Benefits of Networking 14 Interoperability – The Holy Grail 14 Routing and Cost Benefits 16 Networks and Resilience 18 Networks and Contingency Planning 19 Networks and Control Protocols 19 Chapter Two Some Technical Background Layer 3 Protocols Layer 2 Protocols Layer 1 Protocols

21 22 23 23 23

Chapter Three Routes to Interoperability AES-X192 The AVnu Alliance & AVB ALC Networx & Ravenna

25 26 26 26 27

Chapter Four Calrec’s Hydra2 Reliability Vs Compatibility Latency & Redundancy H2O & Network Management Compatibility with Other Standards

29 30 30 31 32 33

Chapter Five Control Protocols & Networking SW-P-02/08 & RAP CSCP & Automation EMBER

35 36 37 37 38

The Future of Broadcast Networks? 38

8

NE T WORK PRIMER

NETWORK PRIMER Introduction

calrec.com

Putting Sound in the Picture

10 NE T WORK PRIMER

Introduction

The word ‘network’ has a long history; it was first recorded in the mid-sixteenth century, but its Germanic roots hint that it may well have been in use much earlier than that. Like much of modern English, it has gone through a variety of ever more abstracted meanings, from a description of a physical object to more figurative, intangible concepts.

What began as a way of describing an invention for catching fish was later applied to similarly interconnected physical systems, including those of canals, railways, telephone wires – and eventually computers.

By the early 20th century, the word had come to refer to systems of related entities that were no longer physically connected, as with radio and TV transmitters belonging to a single broadcaster, or groups of business colleagues. In the last few years, we’ve had ‘wireless networks’ (which medieval speakers of English might have regarded as an oxymoron) and ‘social networks’ composed of users that ‘connect’ solely via data transmissions over the Internet; itself a network of physically disconnected, but nonetheless linked computers.

A similar process of abstraction has been taking place in recent years in the world of broadcast technology, transforming the hard-wired, localized studios of the past into more flexible, networked systems.

Forty years ago, television studios consisted of cameras and microphones hard-wired into discrete hardware vision mixers, patchbays and audio mixing consoles which routed to specific video tape machines in one location. In such systems, a separate physical connection is required for each audio channel, whether from a microphone, mixing console, or recording device. Modern networked

CALREC Putting Sound in the Picture

broadcast systems offer more flexibility; all of the hardware is permanently connected to a data network, and the precise nature of the interconnections between the equipment can be redefined and/or reassigned at any time under software control, remotely if required.

Such ideas are not new, and small-scale proprietary networks of this type have existed in broadcasting for many years.

But over the past decade, the declining complexity and improving cost-to-benefit ratio of implementing large-scale, networked broadcast systems and the ever-widening scope and capabilities of the technology, control protocols and equipment designed to work with such systems, has tempted more and more of the world’s forward-thinking broadcasters to move to networked systems.

At the same time, mixing equipment used in broadcast studios has undergone massive changes, playing far less of a central role. Once, mixing desks were the crucial nodes of a broadcast studio, through which all signals were routed and processed; now large consoles in networked studios are more usually assignable control surfaces, mere ‘clients’ connected to associated processing and routing units elsewhere on the network.

This further level of abstraction offers many benefits for broadcasters, as we shall see, including the ability to move projects swiftly from one studio to another when required by simply reassigning connections, or to control certain aspects of the mixing process remotely, without having to be in front of the console moving faders.

11

12 NE T WORK PRIMER

CHAPTER ONE The Benefits of Networking

calrec.com

Putting Sound in the Picture

THE BENEFITS OF NETWORKING

A networked broadcast studio, editing suite or transmission station isn’t necessarily more efficient than a hard-wired one — indeed for smaller broadcasters, the costs associated with setting up a network can outweigh the benefits. But introducing networking into a largescale broadcast environment can benefit the whole system; networked equipment is both more accessible and more flexible than its hard-wired counterpart.

To understand this, consider what audio patchbays did for arrays of hard-wired studio equipment. Studios function perfectly efficiently when equipment is connected directly, but time is always lost whenever new equipment is connected and its output needs to be made available to other parts of the system. Introducing patchbays to studios initially costs money and the time to wire everything up to the patchbay, and some studios chose to save themselves that time and expense.

However, once a patchbay has been integrated into a studio, any input can be routed to any output, producing significant long-term savings. Introducing new equipment to the system and giving it the same routing flexibility becomes a simple matter of connecting it to the patchbay.

When MIDI patchbays were invented, the routing of signals also became remotely controllable, and this greater flexibility and remote controllability is another benefit of networked studios.

But in the 2010s, data networks have sufficient bandwidth to do much more than route audio around; today it’s theoretically possible to send broadcast video, audio and hardware control signals over a modern network. As we shall see, the technology is not yet quite at the

14 NE T WORK PRIMER

stage where all of these signals interface seamlessly with one another, but progress is moving swiftly in that direction.

Furthermore, because network technology has been developed to very high standards in the IT world, and because IT infrastructure is now so widespread, it is now possible to develop affordable broadcast audio networking technology that builds on existing IT technologies.

This makes the cost of networking broadcast systems relatively affordable, and also introduces the idea of making them remotely controllable.

THE BENEFITS OF NETWORKING

Interoperability — The Holy Grail However, as with many areas of human activity, theory and reality are often quite different. Just because data networks are now interconnected across the world and there are ways of adapting IT networking technology to carry audio and video data, it doesn’t necessarily follow that a live broadcast stream can simply be fed into an Ethernet router in Salford, UK and emerge unscathed in an edit suite in Shenzhen, China; and nor would you be able to guarantee any of the access control or data security that modern broadcasters demand.

In all of the modern world’s major population centers, we take access to electricity for granted, yet the irritating adaptors and transformers we carry with us from continent to continent are a small reminder that even today, the supply is far from standardized worldwide.

International data networks have been with us for far less time, so it should be no surprise to learn that IT infrastructures which were originally designed to handle office-based data transport are far from optimal for routing, mixing, processing and controlling real-time multichannel audio and video, or the equipment that uses them.

That’s not to say widespread Ethernetbased networking technology can’t be developed to form the basis of broadcast networks — indeed, as we have already covered, this is already a reality. The problem is that there are already many proprietary ways to do this, and there is no one standard for handling audio and video together across a network other than embedding the audio with the video, de-embedding it when processing or mixing is required, and re-embedding it afterwards.

CALREC Putting Sound in the Picture

The Holy Grail is a networking standard that allows the use of a single highcapacity network for all of a broadcaster’s infrastructure: IT, phones, intercoms, broadcast audio and video (analogue or digital), with equipment monitoring and control protocols, together with some kind of system management, with all the equipment being able to talk to all of the control protocols on the network irrespective of its manufacturer.

This shining goal is known as ‘interoperability.’ The good news is that cross-manufacturer standards to facilitate it are in development, and we will look at two of the most promising, AVB and Ravenna, later in this primer (see Chapter Three).

In the meantime, such monitoring and control aspects are present only in some of the available proprietary standards (few of which are mutually compatible) and the ability to network video signals and hardware is still missing. That said, the majority of broadcast mixing consoles can route multi-channel audio via their networking protocols, and some of these can also pass control data so that thirdparty hardware can be controlled from the consoles.

You may well ask what difference it makes whether audio is being routed around a studio via CAT5 network cable, fiberoptic or co-axial links or even analogue tie-lines? It’s also fair to consider how much would it cost to add a network infrastructure to traditional connectivity in an existing studio for such little apparent benefit, much less replace one with the other? Surely retaining the existing infrastructure and having patchbays to take care of the routing is more costeffective?

15

THE BENEFITS OF NETWORKING

Routing & Cost Benefits In truth there are a number of benefits associated with a networked approach.

Firstly, modern mixing consoles can now take control all of the audio routing in your studio, allowing broadcasters to save themselves the expense of a separate audio router or patchbay, together with all the connections and wiring to it (more on this point towards the end of this chapter).

Furthermore, from a future-proofing perspective there’s no question that it’s now prudent to connect the constituent parts of a broadcast workflow via a network, certainly on the audio side and especially in the case of new-build projects that are not adapting existing infrastructure.

This is particularly the case for broadcast complexes with large numbers of mixing consoles, control rooms and studios.

Using a network and a proprietary audio routing protocol/management system, it’s possible to route microphone sources from a wallbox in one studio into the control room of another in seconds, or assign the mixer in one control room the task of mixing the combined output of two or more studios, and then return it to being dedicated to a single room again when the job is complete.

Even with patchbays that allow flexible interconnection between studio and control room, this would be a challenge.

What’s more, achieving such ‘superstudios’ via traditional audio connections, whether analogue or digital, requires the running and temporary installation of a lot of extra, expensive cables and looms, and increases the risk of on-air faults.

But in a new-build studio designed around a network from the outset, the cost of the network interconnection cabling is minimal and all the hardware is already

16 NE T WORK PRIMER

connected to the network. The routings simply have to be reassigned by control software. A few clicks of a mouse, and the work is done — or undone.

Such flexible workflows are increasingly the everyday stuff of modern broadcast and the genie is out of the bottle. The next logical step to take once broadcast audio is networked is to connect one audio console’s router to another, making it very simple to transfer all of the audio being received at one console, or even just at one I/O box to a console, to a completely different studio for mixing.

FIGURE 1 - STAR NETWORK

Given the bandwidth of today’s networks, which typically allow many hundreds of audio channels to be passed down a single connection, there’s no need to stop at interconnecting a pair of consoles and their associated I/O. Why not link many consoles together with a standalone audio network router, and thus allow several mixers to freely swap audio channels? This is the basis for a star network like the one shown below (Figure 1), with several consoles connected to a stand-alone router.

THE BENEFITS OF NETWORKING

In a broadcast complex structured like this, sound stages or studios are (quite literally) no longer tied to a single control room. It’s very simple to take multi-channel audio being received from one studio and mix it in another, or to route that audio to another studio to create different mixes for (say) international versioning or commentary. On a rolling news show, the production team in one control room can be mixing the live audio from the news studio and can hand the audio from that studio over to the incoming team in a different control room and go off shift.

FIGURE 2 - MODIFIED STAR NETWORK

Or the team in one control room can switch from mixing the output of one studio or sound stage to working on the output from a different one in seconds.

Such things can be done with analogue or digital tie-lines, but a vast amount of expensive wiring is required. This is not a concern with networked audio given that you can route several hundred channels of high-resolution audio down a single inexpensive Ethernet-style network cable.

But even a star network is only the beginning once multiple consoles are networked. In the example above (Figure 2), each console still has its own dedicated I/O interface (or more usually in this day and age, several interfaces, each handling different audio output formats).

This is still quite a traditional structure that owes much to the days when the I/O was a fixed part of individual consoles. A network permits something more like the modified star structure shown below. Here an assortment of I/O interfacing boxes in a central location is shared commonly by all of the consoles in a broadcast complex, and is connected to them via the central stand-alone router.

CALREC Putting Sound in the Picture

Packing hundreds of channels of audio into a single high-bandwidth networked data connection, where connections can be easily made and reassigned, encourages the construction of complex workflows and network topologies that would be difficult to achieve with standard audio connections.

Consider that it’s not unusual for the cost of wiring a national broadcaster’s transmission control centre to exceed several million dollars, and it becomes clear that audio networks can offer significant savings.

17

THE BENEFITS OF NETWORKING

SPLIT ROUTER CORE

Networks & Resilience For the same reason, it’s considerably less costly to design failsafe systems if your broadcast audio is part of a network. In broadcast, the failure of mission-critical connections live on-air is unacceptable and modern broadcast control centers like to factor redundancy into their designs so that every connection has a backup which can easily be pressed into service in the event of a failure.

Doing this with traditional analogue or digital connections requires twice the amount of expensive cabling and a lot of complicated cable splits. With networked audio, the entire output of a master control room or transmission centre, which may include thousands of channels of audio, can be duplicated on a few Ethernet-style IT cables. Many broadcasters choose to mirror their resources across a network in this way, assembling identical equipment in physically or geographically separate buildings which may be networked

18 NE T WORK PRIMER

together, but may also continue to function independently in the event of one half of the network becoming unusable, as in the diagram below which shows one such ‘linked star’ network.

In this way broadcasters can be said to achieve ‘resilience’ in their systems more easily and affordably than those employing traditional designs. Several leading broadcast audio mixing console manufacturers also take advantage of this technology to offer highly resilient network structures with redundant hardware as well as routing.

In such systems, the fundamental hardware components of the audio console can be duplicated, and the duplicates placed in separate physical locations. In the event that one of the locations is rendered inoperable by power failure, fire, flooding or some other unforeseeable natural or manmade catastrophe, the components in the other

location can take over and be switched into operation seamlessly over the network, ensuring continuity of operation.

Calrec consoles offer this way of working as part of a standard setup, as all of the fundamental hardware components that drive its latest generation of consoles (such as the main processor, router, and DSP cards) are supplied in pairs as standard. Placing one set of the pairs in a different location and linking them via the audio network is a simple matter, and constructing similar resilient structures with consoles from other manufacturers, including Lawo and Stagetec, is equally straightforward and increasingly commonplace. Once again, it stands repeating that offering such resilient workflows without networked audio would be incredibly complex and expensive.

THE BENEFITS OF NETWORKING

Networks & Contingency Planning Networks also make contingency planning easier and more flexible. For example, what do studio owners do if routine maintenance needs to be performed on one studio or control room, and the programme that usually transmits from that studio is due to be broadcast? Or, in a commercial broadcast complex, what happens when a last-minute booking is received from an important client and needs to be accommodated without disrupting the usual assignment of studios and control rooms to other clients?

For example, video switchers can often exercise basic control over gain settings on an audio console, or control source and destination pairs on an associated audio router. More capable control protocols, such as that from Ross Video or Calrec’s development of that protocol (known as the Calrec Serial Protocol or CSCP), permits the control of audio channel levels, and CSCP even allows pan settings, buss assignments and routings to be controlled remotely. Many broadcasters would miss these capabilities if no stand-alone router is included in the system.

In a networked broadcast complex, the output of any studio can easily be assigned to a different control room, or conversely a familiar control room can be used to mix the output from a different studio.

Consequently, some console manufacturers (including Calrec) have begun to add support for these hardware control capabilities into their networking protocols. Whilst it can be argued that this is merely adding functions to networked devices that were already available in a pre-networked era, the attraction of incorporating these control abilities into networked devices is too good to ignore.

The degree to which control protocols can be integrated into networks varies from manufacturer to manufacturer at present, but the intention is to include control protocols in the interoperable network standards of the future.

There are other challenges to overcome, such as ensuring that settings made on one console can be seamlessly ported over to the replacement studio’s console along with all the routings and channel assignments, but manufacturers are working on ways of making this possible over a network too — see Chapter Five for examples of how Calrec is approaching it.

Networks & Control Protocols One of the benefits of using networking technology for audio routing is that the router in a broadcast audio console can then do the job of an expensive stand-alone studio audio router, allowing broadcasters to dispense with the latter and save money. However, over the years, stand-alone routers have developed the ability not only to pass and route audio and video, but also to exercise limited control, via specially developed protocols, over some of the hardware they were connected to.

CALREC Putting Sound in the Picture

We’ve now covered most of the benefits that networks can offer broadcasters, and it’s time to look more closely at the exact state of play in the market today.

In the absence of true interoperability, what options are out there for networking broadcast equipment, and how far do they extend?

19

20 NE T WORK PRIMER

CHAPTER TWO SOME Technical Background

calrec.com

Putting Sound in the Picture

SOME Technical Background

As we’ve discussed, a number of proprietary standards have been developed for transmitting audio over IT networks. Some are better than others, but all have been designed to deal with the fact that the requirements for delivering broadcast audio over a network are considerably more stringent than those for ITrelated data.

NETWORK PROTOCOL LAYERS

IT networking protocols for data transfer (such as the ubiquitous Ethernet) are asynchronous, meaning that the order in which data arrives is not held to be so important as long it arrives eventually.

However, a broadcast audio feed usually consists of many channels of highresolution audio, all of which must be kept in sync with respect to each other and which have to be delivered in real time to avoid dropouts. Looking at the technicalities of data transport over a network, we can categorize audio networking protocols in terms of how closely (or not) they resemble IT networking data standards.

Modern electronic networks are often described in terms of a notional model of up to seven layers of increasing complexity that can be used to integrate communications protocols into real-world applications. For audio networking, the most important of these are the first four layers (which are also the most fundamental).

Layer 1 describes the basic electrical standards and voltages used to transmit data over a wired or wireless network, such as an Ethernet network.

Layer 2 describes the most basic unit of data used on the network; in an Ethernet network, this is the ‘frame’ containing the electronic data. Ethernet Frames include source and destination MAC addresses to

22 NE T WORK PRIMER

identify the source and destination device for data being transmitted.

Layer 3 adds the IP subnet structure used by all Ethernet networks (and Internet servers) to uniquely identify network devices across the globe, and packages the data being transferred in IP packets.

These are all numbered to ensure that all of the data arrives in the right order and can be accounted for.

Layer 4 adds the ability to check the arrival of these packets has occurred in the correct order, without losses or duplication.

In practical terms, all of the audio networking technologies currently on the

market are either Layer 1, 2 or 3 protocols (and all of the Layer 3 protocols contain Layer 4-style data verification capabilities).

However, it would be misleading to suggest that Layer 1 protocols are the most basic and Layer 3 the most featurerich.

Certainly, Layer 3 protocols conform more closely to the defined standards of Gigabit Ethernet (the most common network standard) than others, including Layer 4-style packet checking spliced into Layer 3-style IP packets. These packets sit in turn within an overall Layer 2 Ethernet Frame structure and adhere to the basic Layer 1 electrical definitions of Gigabit Ethernet.

SOME Technical Background

Layer 3 Protocols Thus the structure of the data in Layer 3 protocols, which include Audinate’s Dante, Ravenna from ALC Networx, Axia’s Livewire and QSC’s Q-LAN, most closely resemble that passing over a standard Gigabit Ethernet network. As a result, they can multicast data to multiple IP addresses simultaneously, as on an office network, and they can pass data via connected Ethernet bridges and routers.

This potentially allows the data to be passed over a wide geographical area and not to remain locked within one Local Area Network (or LAN).

Layer 2 Protocols The data structure of Layer 2 protocols, which include the IEEE’s Audio Video Bridging standard (AVB), Calrec’s original Hydra protocol, Peak Audio’s Cobranet and Digigram’s EtherSound, less closely resemble standard Ethernet data. These protocols dispense with the IP packet structure and thereby lose the ability to be routed to other standard LANs. However, they still use the Ethernet Frame structure and can therefore still be routed within their network via off-the-shelf Ethernet hubs and switches.

Layer 1 Protocols Layer 1 protocols, which include Riedel’s RockNet, Aviom’s A-Net, Gibson’s MaGIC, and Calrec’s Hydra2, have the least in common with IT-style network data. They are geographically limited and also have to use proprietary routing hardware.

However, many Layer 1 audio protocols offer similar routing and real-time verification capabilities as Layer 3 protocols — but they do it by means of self-developed, proprietary means.

Although compatibility with off-the-shelf networking hardware is lost in a Layer 1 protocol, dispensing with the ‘higher-layer’ data structures allows the development of very efficient, robust, high-performance,

CALREC Putting Sound in the Picture

SPECTRUM

low-latency protocols. When coupled with the hardware required to use them, they are arguably better suited to professional broadcast applications (albeit usually more expensive to implement).

To summarize; ‘higher level’ protocols offer far greater compatibility with standard networking formats, and allow the use of standard, affordable networking hardware.

This can make installation more costeffective and usable over a wider area, but it can also mean that these protocols are less efficient and higher in latency.

Moreover, because the data in ‘higherlayer’ networks is usually passed via non-proprietary hardware which is not specifically designed to carry audio data, the reliability of these networks can be lower, and therefore less attractive to broadcasters who need their infrastructure to be as robust as possible.

geographical area, and more interoperable, but with a performance that is entirely dependent on the quality of the hardware and infrastructure being used).

Most Audio over IP protocols or Internet Audio streaming standards would fall on the right side of this diagram, being cheap to implement, but may fall below the standard of reliability required by professional broadcasters.

However, compromises that marry the wider compatibility and greater interoperability of Layer 2 and 3 protocols with further standards designed to improve reliability are under development.

The ‘spectrum’ diagram above is a reasonable summary in graphical form, with Layer 1 protocols at one end (more expensive to implement, more applicationspecific and geographically limited) and Layer 3 protocols at the other (cheaper, with the potential for use over a wider

23

24 NE T WORK PRIMER

CHAPTER THREE Routes to Interoperability

calrec.com

Putting Sound in the Picture

Routes to Interoperability

In Chapter One, we touched on the idea of interoperability — the concept of data being shared freely between video and audio equipment. Over the next few years we expect to see a lot of manufacturers in the broadcast market producing equipment which will interface with common transports, although there is still much work to do. A growing number of international broadcast manufacturers are working together to encourage the development of true interoperability between different systems, but as is often the way when an industry tries to establish standards, there are already several different approaches.

AES-X192 An AES standards task group called SC-02-12-H has been formed to develop an interoperability standard for highperformance professional digital audio IP networking. This project has been designated AES-X192 and is partially inspired by an EBU initiative called N/ ACIP which published interoperability recommendations for audio over widearea IP networks.

The scope of this AES initiative is on higher performing networks which allow high-quality, high-capacity and lowlatency digital audio transport. There are a number of systems shipping and under development which offer the targeted capabilities — AVB, Dante, LiveWire, Q-LAN and Ravenna — and the aim of this initiative is to identify common approaches and protocols and to suggest and standardise a means for interoperability between the systems.

The two organisations leading this charge in broadcasting are the AVnu Alliance and Ravenna.

26 NE T WORK PRIMER

The AVnu Alliance & AVB The AVnu Alliance aims to promote Audio Video Bridging (AVB) as a brand with a view to establishing complete interoperability between manufacturers, and is developing an ecosystem with a clear accreditation scheme (ie. an ‘AVB Approved’ label). Founded by a handful of companies including Harman, Cisco and Intel, the Alliance has members including Avid, Axon, Beyerdynamic, Calrec, Dolby, Focusrite, LabX, Meyer Sound, Riedel, Sennheiser, Shure and Yamaha.

AVB is a layer 2 protocol that supports various channel and latency options on 100MBit or Gigabit Ethernet. The unique innovation of AVB is that it is designed to make use of a number of extensions to the Ethernet standard (referred to collectively as IEEE 802.1), that are designed to support real-time streaming services. This means that bandwidth can be reserved through network paths to lock down switching resources and ensure streaming-friendly packet queuing and forwarding behavior.

AVB is not an ‘audio over IP’ protocol — this is a common misconception. In fact, as a Layer 2 protocol, it uses Etherframes rather than IP packets to transport data.

As explained in the last chapter, this means AVB networks are geographically limited to their local network, and cannot not extend across routers or bridges, unlike Ravenna (of which more in a moment). Furthermore, the benefits of the IEEE 802.1 extensions are only felt if the infrastructure explicitly supports them, which requires specially manufactured AVB switches and hubs to be made available.

The trade-off is the guarantee that what you put in is what you get out, and this reliability and predictability is attractive to broadcasters. Other useful

functions include AVB’s DECC (Discovery, enumeration, connection and control) protocol, which presents a view of all AVB devices on the network as soon as a connection is established to it.

If AVB achieves a commercial critical mass, it promises a convenient technology for connecting various devices from different manufacturers across a common network infrastructure. More fundamentally for broadcast audio, if correctly managed this may be shared with other data services without risk to priority audio services.

Routes to Interoperability

ALC Networx & Ravenna Proposed by ALC Networx at IBC 2010 as “a technology for real-time transport of audio and other media data in IPbased network environments”, Ravenna is an open technology standard without a proprietary licensing policy. As such, it encourages partners to participate in ongoing development.

These companies are developing the existing protocols, and at NAB 2012 proved the validity of this approach, when ALC Networx and Axia demonstrated mutually interoperable modes of Ravenna and Livewire (Axia have been selling a similar network technology, Livewire, since 2003).

The aim of Ravenna’s developers is to adapt standard network protocols for use primarily in the professional broadcast market. It makes use of an internet streaming technology which is controlled

by Internet Engineering Task Force (IETF) protocols such as RTP, SRP and SIP (these are the protocols used by the likes of Spotify, YouTube and internet radio).

Ravenna is an open standard layer 3 protocol. Although intended for an Ethernet infrastructure, its use of IP packets abstracts it from the underlying network fabric, extending its reach beyond LANs to public networks, and even the internet. In other words, there are no geographical limits to this technology — the use of standard protocols makes it possible to make use of existing ITstyle IP infrastructure. This is a clear and obvious benefit. Synchronization is achieved through IEEE 1588-2008 (PTPv2 Precision Time Protocol), another standard protocol which provides the ability to synchronize local clocks to a precision defined by the AES-11 standard.

ALC Networx has attempted to address the issue of interoperability by encouraging the formation of a Ravenna ecosystem, and they have already signed up a healthy collection of well-respected manufacturers as developers, including AEQ, Digigram, Genelec, Lawo, LSB, Merging Technologies, Neumann, Schoeps, Sonifex, Telos and Linear Acoustics.

CALREC Putting Sound in the Picture

27

28 NE T WORK PRIMER

CHAPTER FOUR Calrec’s Hydra2

calrec.com

Putting Sound in the Picture

Calrec’s Hydra2

Over the last few pages, we’ve looked at the most successful industry-wide attempts to create a cross-manufacturer broadcast audio networking standard, including the efforts of the AES-X192 working group, the Ravenna-aligned manufacturers and the AVnu Alliance.

Proprietary protocols like Calrec’s Hydra also exhibit this compromise. The most recent manifestation of Calrec’s standard, Hydra2, is a wholly proprietary Studio 1 Layer 1 protocol that is unable to use Hydra2 I/O industry standard hardware above standard networking cable. As such, all of its routing and control hardware and software has to be specifically made for use with Hydra2, which makes it relatively expensive. However, the advantage is hugely improved reliability, efficiency and H YDR A 24- 8 FAN

PORT1 PORT2

H YDR A 24- 8

48V

1L

SIG

48V

1R

SIG

48V

2L

SIG

48V

2R

SIG

48V

3L

SIG

48V

3R

SIG

48V

4L

SIG

48V

48V

7L

SIG

48V

7R

SIG

48V

8L

SIG

48V

8R

SIG

48V

9L

SIG

48V

9R

SIG

48V

10L

SIG

48V

AN A LOG

PSU

SIG

48V

1R

SIG

48V

2L

SIG

48V

2R

SIG

48V

3L

SIG

48V

3R

SIG

48V

4L

SIG

48V

7L

SIG

48V

7R

SIG

48V

8L

SIG

48V

8R

SIG

48V

9L

SIG

48V

9R

SIG

48V

10L

SIG

48V

48V

1L

SIG

48V

1R

SIG

48V

2L

SIG

48V

2R

SIG

48V

3L

SIG

48V

3R

SIG

48V

4L

SIG

48V

48V

7L

SIG

48V

7R

SIG

48V

8L

SIG

48V

8R

SIG

48V

9L

SIG

48V

9R

SIG

48V

10L

SIG

48V

SIG

48V

5L

SIG

48V

5R

SIG

48V

6L

SIG

48V

10R SIG

4R

48V

11L

SIG

48V

11R

SIG

48V

12L

SIG

48V

SIG

1L

SIG

1R

SIG

2L

SIG

2R

SIG

12R SIG

6R

3L

SIG

3R

SIG

4L

SIG

4R

SIG

SIG

1L

SIG

1R

SIG

2L

SIG

2R

SIG

12R SIG

3L

SIG

3R

SIG

4L

SIG

4R

SIG

H YDR A 24- 8

FAN

PORT1 PORT2

SIG

48V

5L

SIG

48V

5R

SIG

48V

6L

SIG

48V

10R SIG

4R

48V

11L

SIG

48V

11R

SIG

48V

12L

SIG

48V

6R

2

3

4

2

3

4

5

6

7

6

7

1L

SIG

1R

SIG

2L

SIG

2R

SIG

3L

SIG

3R

SIG

4L

SIG

4R

SIG

AN A LOG

PSU

FAN

PORT1 PORT2

SIG

48V

5L

SIG

48V

5R

SIG

48V

6L

SIG

48V

10R SIG

4R

48V

11L

SIG

48V

11R

SIG

48V

12L

SIG

48V

6R

H YDR A 24- 8 FAN

2

3

4

5

RESET

6

7

PORT1 PORT2

1L

SIG

48V

1R

SIG

48V

2L

SIG

48V

2R

SIG

48V

3L

SIG

48V

3R

SIG

48V

4L

SIG

48V

48V

7L

SIG

48V

7R

SIG

48V

8L

SIG

48V

8R

SIG

48V

9L

SIG

48V

9R

SIG

48V

10L

SIG

48V

4R

SIG

Con Act Con Act

STATUS

1

48V

AN A LOG

PSU

Con Act Con Act

RESET

8

8

2

3

4

5

6

7

48V

5L

SIG

48V

5R

SIG

48V

6L

SIG

48V

48V

11L

SIG

48V

11R

SIG

48V

12L

SIG

48V

6R

2

3

4

5

6

7

48V

1L

SIG

48V

1R

SIG

48V

2L

SIG

48V

2R

SIG

48V

3L

SIG

48V

3R

SIG

48V

4L

SIG

48V

7L

SIG

48V

7R

SIG

48V

8L

SIG

48V

8R

SIG

48V

9L

SIG

48V

9R

SIG

48V

10L

SIG

48V

48V

1L

SIG

48V

1R

SIG

48V

2L

SIG

48V

2R

SIG

48V

3L

SIG

48V

3R

SIG

48V

4L

SIG

48V

48V

7L

SIG

48V

7R

SIG

48V

8L

SIG

48V

8R

SIG

48V

9L

SIG

48V

9R

SIG

48V

10L

SIG

48V

SIG

48V

5L

SIG

48V

5R

SIG

48V

6L

SIG

48V

10R SIG

4R

48V

11L

SIG

48V

11R

SIG

48V

12L

SIG

48V

SIG

1L

SIG

1R

SIG

2L

SIG

2R

SIG

12R SIG

6R

3L

SIG

3R

SIG

4L

SIG

4R

SIG

SIG

1L

SIG

1R

SIG

2L

SIG

2R

SIG

12R SIG

3L

SIG

3R

SIG

4L

SIG

4R

SIG

1L

SIG

1R

SIG

2L

SIG

2R

SIG

3L

SIG

3R

SIG

4L

SIG

4R

SIG

AN A LOG

PSU

FAN

PORT1 PORT2

SIG

48V

5L

SIG

48V

5R

SIG

48V

6L

SIG

48V

10R SIG

4R

48V

11L

SIG

48V

11R

SIG

48V

12L

SIG

48V

6R

H YDR A 24- 8

2

3

4

Hydra2 I/O FAN

PORT1 PORT2

48V

1L

SIG

48V

1R

SIG

48V

2L

SIG

48V

2R

SIG

48V

3L

SIG

48V

3R

SIG

48V

4L

SIG

48V

4R

SIG

48V

5L

SIG

48V

5R

SIG

48V

6L

SIG

48V

6R

SIG

1L

SIG

1R

SIG

2L

SIG

2R

6

7

2

3

4

5

6

7

RESET

8

FAN

PORT1 PORT2

1L

SIG

48V

1R

SIG

48V

2L

SIG

48V

2R

SIG

48V

3L

SIG

48V

3R

SIG

48V

4L

SIG

48V

48V

7L

SIG

48V

7R

SIG

48V

8L

SIG

48V

8R

SIG

48V

9L

SIG

48V

9R

SIG

48V

10L

SIG

48V

4R

SIG

48V

5L

SIG

48V

5R

SIG

48V

6L

SIG

48V

10R SIG

48V

11L

SIG

48V

11R

SIG

48V

12L

SIG

48V

6R

SIG

1L

SIG

1R

SIG

2L

SIG

2R

SIG

H YDR A 24- 8 48V

1L

SIG

48V

1R

SIG

48V

2L

SIG

48V

2R

SIG

48V

7L

SIG

48V

7R

SIG

48V

8L

SIG

48V

8R

SIG

AN A LOG

PSU

FAN

PORT1 PORT2

48V

3L

SIG

9L

SIG

48V

3R

SIG

9R

SIG

48V

4L

SIG

10L

SIG

48V

4R

SIG

48V

10R SIG

48V

5L

SIG

11L

SIG

48V

5R

SIG

11R

SIG

48V

6L

SIG

12L

SIG

SIG

1L

SIG

12R SIG

6R

3L

SIG

48V

1R

SIG

3R

SIG

2L

SIG

4L

SIG

H YDR A 24- 8

2R

SIG

4R

SIG

FAN

2

3

4

5

6

7

PORT1 PORT2

7R

SIG

48V

8L

SIG

48V

8R

SIG

48V

9L

SIG

48V

9R

SIG

48V

10L

SIG

48V

1L

SIG

48V

1R

SIG

48V

2L

SIG

48V

2R

SIG

48V

3L

SIG

48V

3R

SIG

48V

4L

SIG

48V

48V

7L

SIG

48V

7R

SIG

48V

8L

SIG

48V

8R

SIG

48V

9L

SIG

48V

9R

SIG

48V

10L

SIG

48V

10R SIG

4R

48V

11L

SIG

48V

11R

SIG

48V

12L

SIG

48V

SIG

48V

5L

SIG

48V

5R

SIG

48V

6L

SIG

48V

10R SIG

48V

11L

SIG

48V

11R

SIG

48V

12L

SIG

48V

12R SIG

6R

3L

SIG

3R

SIG

4L

SIG

4R

12R SIG

3L

SIG

3R

SIG

4L

SIG

4R

SIG

H YDR A 24- 8

RESET

8

H YDR A 24- 8

2

3

4

5

1L

SIG

1R

SIG

2L

SIG

2R

SIG

3L

SIG

3R

SIG

4L

SIG

4R

SIG

PSU

2

3

4

FAN

7

PORT1 PORT2

1L

SIG

48V

1R

SIG

48V

2L

SIG

48V

2R

SIG

48V

3L

SIG

48V

3R

SIG

48V

4L

SIG

48V

48V

7L

SIG

48V

7R

SIG

48V

8L

SIG

48V

8R

SIG

48V

9L

SIG

48V

9R

SIG

48V

10L

SIG

48V

SIG

48V

5L

SIG

48V

5R

SIG

48V

6L

SIG

48V

10R SIG

4R

48V

11L

SIG

48V

11R

SIG

48V

12L

SIG

48V

5

6

7

48V

48V

48V

48V

48V

48V

8

6R

1L

SIG

1R

SIG

2L

SIG

2R

SIG

3L

SIG

3R

SIG

4L

SIG

4R

SIG

2

3

4

5

6

7

48V

1L

SIG

48V

1R

SIG

48V

2L

SIG

48V

2R

SIG

48V

3L

SIG

48V

3R

SIG

48V

4L

SIG

48V

48V

7L

SIG

48V

7R

SIG

48V

8L

SIG

48V

8R

SIG

48V

9L

SIG

48V

9R

SIG

48V

10L

SIG

48V

AN A LOG

PSU

FAN

PORT1 PORT2

SIG

48V

5L

SIG

48V

5R

SIG

48V

6L

SIG

48V

10R SIG

4R

48V

11L

SIG

48V

11R

SIG

48V

12L

SIG

48V

SIG

1L

SIG

1R

SIG

2L

SIG

2R

SIG

12R SIG

6R

3L

SIG

3R

SIG

4L

SIG

4R

SIG

H YDR A 24- 8

RESET

8

PSU

FAN

PORT1 PORT2

STATUS 1

2

3

4

48V

1L

SIG

48V

1R

SIG

48V

2L

SIG

48V

2R

SIG

48V

3L

SIG

48V

3R

SIG

48V

4L

SIG

48V

48V

7L

SIG

48V

7R

SIG

48V

8L

SIG

48V

8R

SIG

48V

9L

SIG

48V

9R

SIG

48V

10L

SIG

48V

AN A LOG

Con Act Con Act

STATUS 1

2

3

4

5

6

7

48V

1R

SIG

48V

2L

SIG

48V

2R

SIG

48V

3L

SIG

48V

3R

SIG

48V

4L

SIG

48V

SIG

48V

7R

SIG

48V

8L

SIG

48V

8R

SIG

48V

9L

SIG

48V

9R

SIG

48V

10L

SIG

48V

SIG

48V

5L

SIG

48V

5R

SIG

48V

6L

SIG

48V

10R SIG

4R

48V

11L

SIG

48V

11R

SIG

48V

12L

SIG

48V

SIG

1L

SIG

1R

SIG

2L

SIG

2R

SIG

12R SIG

6R

3L

SIG

3R

SIG

4L

SIG

4R

SIG

6

7

8

2

3

SIG

48V

5L

SIG

48V

5R

SIG

48V

6L

SIG

48V

10R SIG

4R

48V

11L

SIG

48V

11R

SIG

48V

12L

SIG

48V

6R

2

PORT1 PORT2

3

4

2

3

4

5

6

7

6

7

1L

SIG

48V

1R

SIG

48V

2L

SIG

48V

2R

SIG

48V

3L

SIG

48V

3R

SIG

48V

4L

SIG

48V

48V

7L

SIG

48V

7R

SIG

48V

8L

SIG

48V

8R

SIG

48V

9L

SIG

48V

9R

SIG

48V

10L

SIG

48V

48V

1L

SIG

48V

1R

SIG

48V

2L

SIG

48V

2R

SIG

48V

3L

SIG

48V

3R

SIG

48V

4L

SIG

48V

48V

7L

SIG

48V

7R

SIG

48V

8L

SIG

48V

8R

SIG

48V

9L

SIG

48V

9R

SIG

48V

10L

SIG

48V

SIG

48V

5L

SIG

48V

5R

SIG

48V

6L

SIG

48V

10R SIG

4R

48V

11L

SIG

48V

11R

SIG

48V

12L

SIG

48V

SIG

1L

SIG

1R

SIG

2L

SIG

2R

SIG

12R SIG

6R

3L

SIG

3R

SIG

4L

SIG

4R

SIG

SIG

1L

SIG

1R

SIG

2L

SIG

2R

SIG

12R SIG

3L

SIG

3R

SIG

4L

SIG

4R

SIG

8

H YDR A 24- 8

SIG

1L

SIG

1R

SIG

2L

SIG

2R

SIG

12R SIG

3L

SIG

3R

SIG

4L

SIG

4R

SIG

AN A LOG

PSU

FAN

PORT1 PORT2

SIG

48V

5L

SIG

48V

5R

SIG

48V

6L

SIG

48V

10R SIG

4R

48V

11L

SIG

48V

11R

SIG

48V

12L

SIG

48V

6R

Con Act Con Act

STATUS 1

5

STATUS

RESET

8

1

2

3

4

5

6

7

8

SYNC INPUTS DSP

ROUTER / EXPANDER

ENABLE

FANS

VIDEO 1

AES 3

WORD CLOCK

VIDEO 2

GOOD FAIL

ROUTER 1

CONTROL PROCESSOR 1 PROCESSOR 2

DSP 1

DSP 2

ROUTER 2

EXPANSION 2

PSU 1

PSU 2

RESETS

CONTROL SYSTEM

SYNC IN DSP

ROUTER / EXPANDER

ENABLE

FANS

VIDEO 1

AES 3

GOOD FAIL DSP

ROUTER / EXPANDER ROUTER / EXPANDER

CONTROL PROCESSOR MAC 6

MAC 7

10

10

9

12

9 11 LINKS 13 15

4

3

6

5

8

Control Room A FAN

MADI PORT 1

PORT1 PORT2

CHANNELS 56 64

Con Act Con Act

h y dr a m a di

RESET

STATUS 1

2

3

6

7

CONNECTORS FIBER COAX

CHANNELS 56 64

OK

CONNECTORS FIBER COAX

SRC

2

SIG

SRC

3

SIG

SRC

4

SIG

SRC

5

SIG

SRC

6

SIG

SRC

7

SIG

SRC

8

SIG

SIG

SRC

10

SIG

SRC

11

SIG

SRC

12

SIG

SRC

13

SIG

SRC

14

SIG

SRC

15

SIG

SRC

16

SIG

9

SIG

10

SIG

11

SIG

12

SIG

13

SIG

14

SIG

15

SIG

16

SIG

SIG

SRC

18

SIG

SRC

19

SIG

SRC

20

SIG

SRC

21

SIG

SRC

22

SIG

SRC

23

SIG

SRC

24

SIG

17

SIG

18

SIG

19

SIG

20

SIG

21

SIG

22

SIG

23

SIG

24

SIG

SRC

25

SIG

SRC

26

SIG

SRC

27

SIG

SRC

28

SIG

SRC

29

SIG

SRC

30

SIG

SRC

31

SIG

SRC

32

SIG

25

SIG

26

SIG

27

SIG

28

SIG

29

SIG

30

SIG

31

SIG

32

SIG

POK PRI MOK ST1

KBD

VGA

D0

MA RST NOK ST2

D1 R1

E0

MA RST NOK ST2

E1

POK

MA

PRI MOK ST1 CF

VGA

D0 R0 E0 POK

RST

PRI

NOK

MOK

ST2

ST1

LOW BATT

EXPANSION 1

AC IN

CF

8 D2 D4 D6 D8

D1 D3 D5 D7

2 4 6 8

8

7 1 3 5 LINKS 7

POK PRI MOK ST1

MA RST NOK ST2

POK PRI MOK ST1

MA RST NOK ST2

9 11 LINKS 13 15

2

1 3 5 LINKS 7

USB

CONTROL PROCESSOR

8

MA RST NOK ST2

POK ST1 ST3 ST5

ST0 ST2 ST4 ST6

POK ST1 ST3 ST5

Control Room B

ST0 ST2 ST4 ST6

2

2 4 6 8

5

6

7

8

1 3 5 LINKS 7

Hydra2 Master Router

USB 1

USB 2

D1 D3 D5 D7

MOUSE

KBD

KBD

VGA

VGA

D0

D1

R0

POK PRI MOK ST1

MA RST NOK ST2

POK PRI MOK ST1

D0

R1

E0

MA RST NOK ST2

PRI MOK ST1

3

4

5

6

7

8

2

SIG

3

SIG

4

SIG

h y dr a m a di

RESET

a e s 10 dig ita l

5

SIG

6

SIG

7

SIG

8

SIG

PSU

DIGITAL AUDIO INPUTS

PORT1 PORT2

1L

SIG

48V

1R

SIG

48V

2L

SIG

48V

2R

SIG

48V

3L

SIG

48V

3R

SIG

48V

4L

SIG

48V

48V

7L

SIG

48V

7R

SIG

48V

8L

SIG

48V

8R

SIG

48V

9L

SIG

48V

9R

SIG

48V

10L

SIG

48V

SIG

48V

5L

SIG

48V

5R

SIG

48V

6L

SIG

48V

10R SIG

4R

48V

11L

SIG

48V

11R

SIG

48V

12L

SIG

48V

SIG

1L

SIG

1R

SIG

2L

SIG

2R

SIG

12R SIG

6R

3L

SIG

3R

SIG

4L

SIG

4R

SIG

4

5

6

7

FAN

AE S 3 DIG ITA L

8

Artemis Control Surface

PSU

FAN

1

2

3

4

5

6

7

8

SIG

SRC

2

SIG

SRC

3

SIG

SRC

4

SIG

SRC

5

SIG

SRC

6

SIG

SRC

7

SIG

SRC

8

SIG

9

SIG

SRC

10

SIG

SRC

11

SIG

SRC

12

SIG

SRC

13

SIG

SRC

14

SIG

SRC

15

SIG

SRC

16

SIG

9

SIG

10

SIG

11

SIG

12

SIG

13

SIG

14

SIG

15

SIG

16

SIG

17

SIG

SRC

18

SIG

SRC

19

SIG

SRC

20

SIG

SRC

21

SIG

SRC

22

SIG

SRC

23

SIG

SRC

24

SIG

17

SIG

18

SIG

19

SIG

20

SIG

21

SIG

22

SIG

23

SIG

24

SIG

SRC

25

SIG

SRC

26

SIG

SRC

27

SIG

SRC

28

SIG

SRC

29

SIG

SRC

30

SIG

SRC

31

SIG

SRC

32

SIG

25

SIG

26

SIG

27

SIG

28

SIG

29

SIG

30

SIG

31

SIG

32

SIG

1

SIG

DIGITAL AUDIO INPUTS

ROUTER / EXPANDER

DSP 1

ENABLE

FANS

CONTROL PROCESSOR 1 PROCESSOR 2

VIDEO 1

AES 3

WORD CLOCK

VIDEO 2

ROUTER 2

EXPANSION 2

PSU 1

PSU 2

PSU

FAN

9

10

CONTROL PROCESSOR

11 12

11

13 14

13

16 10 12 14 16

15 16 9 11 LINKS 13 15

2

1

4

3

10 12 14 16

MAC 6

MAC 7

2 4 6 8

5 7 1 3 5 LINKS 7

15

MAC 4

MAC 3

2 4 6 8

USB 1

USB 2

11 13

15 16 9 11 LINKS 13 15

2

USB 1

D1 D3 D5 D7

KBD

VGA

D0 R0

MA RST NOK ST2

E0 POK PRI MOK ST1 CF

VGA

D1

D0

R1

R0

E1 MA

PSU

PSU

FAN

MADI PORT 1

PORT1 PORT2

CHANNELS 56 64

Con Act Con Act

STATUS 1

2

6

7

CHANNELS 56 64

OK

CONNECTORS FIBER COAX

1

2

3

E0 POK

RST

PRI

NOK

MOK

ST2

ST1

LOW BATT

CF

2

SIG

SRC

3

SIG

SRC

4

SIG

SRC

5

SIG

SRC

6

SIG

SRC

7

SIG

SRC

8

SIG

4

5

6

7

8

FAN

MADI PORT 1

PORT1 PORT2

CHANNELS 56 64

STATUS 1

2

3

4

5

6

D1 D3 D5 D7

2 4 6 8

MA RST NOK ST2

POK PRI MOK ST1

2

SIG

SRC

3

SIG

SRC

4

SIG

SRC

5

SIG

SRC

6

SIG

SRC

7

SIG

SRC

8

SIG

1

SIG

2

SIG

3

SIG

4

SIG

5

SIG

6

SIG

7

SIG

8

SIG

SRC

10

SIG

SRC

11

SIG

SRC

12

SIG

SRC

13

SIG

SRC

14

SIG

SRC

15

SIG

SRC

16

SIG

9

SIG

10

SIG

11

SIG

12

SIG

13

SIG

14

SIG

15

SIG

16

SIG

SRC

SIG

SRC

18

SIG

SRC

19

SIG

SRC

20

SIG

SRC

21

SIG

SRC

22

SIG

SRC

23

SIG

SRC

24

SIG

17

SIG

18

SIG

19

SIG

20

SIG

21

SIG

22

SIG

23

SIG

24

SIG

SRC

25

SIG

SRC

26

SIG

SRC

27

SIG

SRC

28

SIG

SRC

29

SIG

SRC

30

SIG

SRC

31

SIG

SRC

32

SIG

25

SIG

26

SIG

27

SIG

28

SIG

29

SIG

30

SIG

31

SIG

32

SIG

SRC

9

SIG

SRC

10

SIG

SRC

11

SIG

SRC

12

SIG

SRC

13

SIG

SRC

14

SIG

SRC

15

SIG

SRC

16

SIG

9

SIG

10

SIG

11

SIG

12

SIG

13

SIG

14

SIG

15

SIG

16

SIG

SRC

17

SIG

SRC

18

SIG

SRC

19

SIG

SRC

20

SIG

SRC

21

SIG

SRC

22

SIG

SRC

23

SIG

SRC

24

SIG

17

SIG

18

SIG

19

SIG

20

SIG

21

SIG

22

SIG

23

SIG

24

SIG

SRC

3

SIG

SRC

4

SIG

SRC

5

SIG

SRC

6

SIG

SRC

7

SIG

SRC

8

SIG

1

SIG

2

SIG

3

SIG

SRC

11

SIG

SRC

12

SIG

SRC

13

SIG

SRC

14

SIG

SRC

15

SIG

SIG

SIG

SIG

SIG

25

SIG

26

SIG

27

SIG

28

SIG

29

SIG

30

SIG

31

SIG

32

SIG

SIG

5

SIG

6

SIG

7

SIG

8

5

6

7

8

SRC

25

SIG

SRC

26

SIG

SRC

27

SIG

SRC

28

SRC

29

SRC

30

SRC

31

SRC

32

48V

1L

SIG

48V

1R

SIG

48V

2L

SIG

48V

2R

SIG

48V

3L

SIG

48V

3R

SIG

48V

4L

SIG

48V

4R

48V

7L

SIG

48V

7R

SIG

48V

8L

SIG

48V

8R

SIG

48V

9L

SIG

48V

9R

SIG

48V

10L

SIG

48V

SIG

48V

5L

SIG

48V

5R

SIG

48V

6L

SIG

48V

10R SIG

48V

11L

SIG

48V

11R

SIG

48V

12L

SIG

48V

6R

2

3

DSP

ST0 ST2 ST4 ST6

H YDR A

1

SIG

SRC

2

SIG

SRC

3

SIG

SRC

4

SIG

SRC

5

SIG

SRC

6

SIG

SRC

7

SIG

SRC

8

SIG

9

SIG

SRC

10

SIG

SRC

11

SIG

SRC

12

SIG

SRC

13

SIG

SRC

14

SIG

SRC

15

SIG

SRC

16

SIG

9 11 LINKS 13 15

SIG

2

SIG

3

SIG

4

SIG

5

SIG

6

SIG

7

SIG

8

SIG

9

SIG

10

SIG

11

SIG

12

SIG

13

SIG

14

SIG

15

SIG

16

SIG

FAN

SRC

4

5

6

7

CONTROL PROCESSOR

CONTROL PROCESSOR

MAC 6

ROUTER 2

DSP

2

3

4

5

6

7

8

SIG

1R

SIG

2L

SIG

2R

SIG

Hydra2 Master Router

12R SIG

3L

SIG

3R

SIG

4L

SIG

4R

SIG

17

SIG

SRC

18

SIG

SRC

19

SIG

SRC

20

SIG

SRC

21

SIG

SRC

22

SIG

SRC

23

SIG

SRC

24

SIG

17

SIG

18

SIG

19

SIG

20

SIG

21

SIG

22

SIG

23

SIG

24

SIG

25

SIG

SRC

26

SIG

SRC

27

SIG

SRC

28

SIG

SRC

29

SIG

SRC

30

SIG

SRC

31

SIG

SRC

32

SIG

25

SIG

26

SIG

27

SIG

28

SIG

29

SIG

30

SIG

31

SIG

32

SIG

DIGITAL AUDIO INPUTS

32-32

FAN

6

7

8

SIG

SRC

16

SIG

9

SIG

10

SIG

11

SIG

SRC

17

SIG

SRC

18

SIG

SRC

19

SIG

SRC

20

SIG

SRC

21

SIG

SRC

22

SIG

SRC

23

SIG

SRC

24

SIG

17

SIG

18

SIG

19

SIG

PSU

FAN

PORT1 PORT2

SIG

SIG

SIG

SRC

31

SIG

SRC

32

SIG

25

SIG

26

SIG

27

SIG

SRC

25

SIG

SRC

26

SIG

SRC

27

SIG

SRC

28

SRC

29

SRC

30

48V

1L

SIG

48V

1R

SIG

48V

2L

SIG

48V

2R

SIG

48V

3L

SIG

48V

3R

SIG

48V

4L

SIG

48V

48V

7L

SIG

48V

7R

SIG

48V

8L

SIG

48V

8R

SIG

48V

9L

SIG

48V

9R

SIG

48V

10L

SIG

48V

SIG

48V

5L

SIG

48V

5R

SIG

48V

6L

SIG

10R SIG

4R

48V

11L

SIG

48V

11R

SIG

48V

12L

SIG

Con Act Con Act

RESET

STATUS 1

2

3

4

5

6

7

8

10

PSU 1

PSU 2

PSU

PSU

9 11

13 14

9 11 LINKS 13 15

2

USB 1

USB 2

10 12 14 16

1

4

3

AC IN

15 9 11 LINKS 13 15

2

1

4

AC IN

13

15 16

10 12 14 16

MAC 5

USB 1

11 12

14 16

MAC 3

MAC 5

MOUSE

10

9

12 MAC 4

MAC 3

USB 2

EXPANSION 2

1 3 5 LINKS 7

POK PRI MOK ST1

3

MOUSE

6 KBD

7

2 4 6 8

D2 D4 D6 D8

1 3 5 LINKS 7

D1 D3 D5 D7

POK PRI MOK ST1

D0

MA RST NOK ST2

POK PRI MOK ST1

2

3

SRC

DIGITAL AUDIO OUTPUTS

1

SIG

SRC

2

SIG

SRC

3

SIG

SRC

4

SIG

SRC

5

SIG

SRC

6

SIG

SRC

7

SIG

SRC

8

SIG

9

SIG

SRC

10

SIG

SRC

11

SIG

SRC

12

SIG

SRC

13

SIG

SRC

14

SIG

SRC

15

SIG

SRC

16

SIG

1

SIG

2

SIG

3

SIG

4

SIG

5

SIG

6

SIG

7

SIG

8

SIG

9

SIG

10

SIG

11

SIG

12

SIG

13

SIG

14

SIG

15

SIG

16

SIG

KBD

VGA

ETHERNET

MA RST NOK ST2

MA RST NOK ST2

R1

E0

E1

D0

MA

PRI ST1

6

5

8 D2 D4 D6 D8

VGA

D1

R0 POK MOK

R1

E0

E1

PRI MOK ST1

D1 D3 D5 D7

1 3 5 LINKS 7

5

SIG

SRC

2

SIG

SRC

3

SIG

SRC

4

SIG

SRC

5

SIG

SRC

6

SIG

SRC

7

SIG

SRC

8

SIG

AE S 3 DIG ITA L PSU

FAN

MA RST NOK ST2

POK PRI MOK ST1

MA RST NOK ST2

1

2

3

SRC

9

SIG

SRC

10

SIG

SRC

11

SIG

SRC

12

SIG

SRC

13

SIG

SRC

14

SIG

SRC

15

SIG

SRC

16

SIG

9

SIG

10

SIG

11

SIG

12

SIG

13

SIG

14

SIG

15

SIG

16

SIG

SRC

17

SIG

SRC

18

SIG

SRC

19

SIG

SRC

20

SIG

SRC

21

SIG

SRC

22

SIG

SRC

23

SIG

SRC

24

SIG

17

SIG

18

SIG

19

SIG

20

SIG

21

SIG

22

SIG

23

SIG

24

SIG

SIG

2

SIG

3

SIG

4

SIG

5

SIG

6

SIG

7

SIG

8

1 3 5 LINKS 7

USB

USB

ETHERNET

POK PRI MOK ST1

MA RST NOK ST2

POK ST1 ST3 ST5

ST0 ST2 ST4 ST6

POK ST1 ST3 ST5

ST0 ST2 ST4 ST6

LOW BATT

4

5

6

7

8

Apollo Processing / DSP / Router PSU

SRC

17

SIG

SRC

18

SIG

SRC

19

SIG

SRC

20

SIG

SRC

21

SIG

SRC

22

SIG

SRC

23

SIG

SRC

24

SIG

17

SIG

18

SIG

19

SIG

20

SIG

21

SIG

22

SIG

23

SIG

24

SIG

SRC

25

SIG

SRC

26

SIG

SRC

27

SIG

SRC

28

SIG

SRC

29

SIG

SRC

30

SIG

SRC

31

SIG

SRC

32

SIG

25

SIG

26

SIG

27

SIG

28

SIG

29

SIG

30

SIG

31

SIG

32

SIG

FAN

MADI PORT 1

PORT1 PORT2

CHANNELS 56 64

Con Act Con Act

h y dr a m a di

RESET

STATUS 1

2

3

6

7

MADI PORT 2

CONNECTORS FIBER COAX

PSU

FAN

2

3

OK

SRC

2

SIG

SRC

3

SIG

SRC

4

SIG

SRC

5

SIG

SRC

6

SIG

SRC

7

SIG

SRC

8

SIG

SIG

SRC

10

SIG

SRC

11

SIG

SRC

12

SIG

SRC

13

SIG

SRC

14

SIG

SRC

15

SIG

SRC

16

SIG

9

SIG

10

SIG

11

SIG

12

SIG

13

SIG

14

SIG

15

SIG

16

SIG

17

SIG

SRC

18

SIG

SRC

19

SIG

SRC

20

SIG

SRC

21

SIG

SRC

22

SIG

SRC

23

SIG

SRC

24

SIG

17

SIG

18

SIG

19

SIG

20

SIG

21

SIG

22

SIG

23

SIG

24

SIG

SRC

25

SIG

SRC

26

SIG

SRC

8

27

SIG

SRC

28

SIG

SRC

29

SIG

SRC

30

SIG

SRC

31

SIG

SRC

32

SIG

25

SIG

26

SIG

27

SIG

28

SIG

29

SIG

30

SIG

31

SIG

32

SIG

DIGITAL AUDIO OUTPUTS

1

2

SIG

3

SIG

4

SIG

SIG

5

SIG

6

SIG

7

SIG

8

SIG

PORT1 PORT2 Con Act Con Act

STATUS 1

CONNECTORS FIBER COAX

5

SIG

9

SRC

SRC

32-32

AE S 3 DIG ITA L

RESET

CHANNELS 56 64

OK

4

1

SRC

a e s 10 dig ita l

H YDR A

4

5

6

7

8

SIG

PORT1 PORT2 Con Act Con Act

STATUS

RESET

1

7

2 4 6 8

ETHERNET

POK PRI MOK ST1

MA RST NOK ST2

CF

8

7

2 4 6 8

D1

R0 POK

RST NOK ST2 LOW BATT

PORT1 PORT2 STATUS

1

Hydra2 I/O

DIGITAL AUDIO OUTPUTS

1

32-32

H YDR A

8

5

MAC 6

MAC 7

MAC 4

1

5

8

7

2 4 6 8

ETHERNET

SRC

SRC

DIGITAL AUDIO INPUTS

1L

4

WORD CLOCK

VIDEO 2

ROUTER / EXPANDER ROUTER / EXPANDER

3

6

5

DSP 2

9

9 11 LINKS 13 15

4

3

6

PORT1 PORT2 STATUS

1

SIG

SIG

VIDEO 1

AES 3

11 13 15

10 12 14 16

2

1

4

1

8

32-32

AE S 3 DIG ITA L

CF

STATUS 1

FANS

CONTROL PROCESSOR 1 PROCESSOR 2

DSP 1

10

11 12 13 14 15 16

10 12 14 16

DIGITAL AUDIO OUTPUTS

2

POK ST1 ST3 ST5

RESET

Con Act Con Act

RESET

ROUTER 1

9

12

ST0 ST2 ST4 ST6

DIGITAL AUDIO INPUTS

PORT1 PORT2

ENABLE

MAC 7

10

USB SRC

POK ST1 ST3 ST5

SRC

AN A LOG

FAN

3

SYNC INPUTS DSP

ROUTER / EXPANDER

PORT1 PORT2

4

H YDR A 24- 8 PSU

EXPANSION 1

14

USB

MA RST NOK ST2

Con Act Con Act

4

SIG

5

SIG

SIG

ETHERNET

POK PRI MOK ST1

PSU

3

SIG

OK

2

10

GOOD FAIL

16

DIGITAL AUDIO INPUTS

7 1 3 5 LINKS 7

2

DIGITAL AUDIO OU

SRC

SRC

Hydra2 I/O RESETS

CONTROL SYSTEM

1

5

2 4 6 8

MA RST NOK ST2

AE S 3 DIG ITA L

3

2

CONNECTORS FIBER COAX

8

SIG

SIG

AN A LOG

Apollo Control Surface

DIGITAL AUDIO OUTPUTS

SRC

SIG

3

6 8

7 1 3 5 LINKS 7 ETHERNET

POK PRI MOK ST1

DIGITAL AUDIO OUTPUTS

SIG

7

1

9

H YDR A 24- 8

9 11 LINKS 13 15

4

3 5

8 D2 D4 D6 D8

D1

8

1

MA RST NOK ST2

SIG

SIG

SRC

5

SRC

Con Act Con Act

2

8

R1 E1 MA RST NOK ST2 LOW BATT

RESET

FAN

STATUS 1

SIG

ROUTER / EXPANDER ROUTER / EXPANDER

H YDR A

PSU

7

AC IN

OK

4

SIG

32-32

AE S 3 DIG ITA L

RESET

SIG

MADI PORT 2

CONNECTORS FIBER COAX

3

1

DIGITAL AUDIO INPUTS

H YDR A

6

9

Con Act Con Act

RESET

ETHERN

POK PRI MOK ST1

PSU

AC IN

PSU

SRC

SIG

15

10 12 14 16

2

1

4 6

D2 D4 D6 D8

POK PRI MOK ST1

5

MOUSE

KBD

7

ETHERNET

MA RST NOK ST2

SIG

1

9

11 12 13 14

10 12 14 16

MAC 5

USB 2

3 5

1 3 5 LINKS 7

10

9

12 14 16

MAC 3

MAC 5

1

4

POK PRI MOK ST1

ROUTER / EXPANDER ROUTER / EXPANDER

10

9 11 LINKS 13 15

2

6 8

ETHERNET

MA RST NOK ST2

Artemis Light Processing / DSP / Router

4

MAC 6

MAC 4

MOUSE

6 8

POK PRI MOK ST1

DSP

CONTROL PROCESSOR

9

12

SIG

PORT1 PORT2 STATUS

RESET DSP

MAC 7

10

14

3

17

32-32

H YDR A

AE S 3 DIG ITA L

DSP 2

Con Act Con Act

ROUTER / EXPANDER ROUTER / EXPANDER

SIG

SYNC INPUTS DSP

GOOD FAIL

ROUTER 1

2

SRC

SRC

RESETS

CONTROL SYSTEM

EXPANSION 1

a e s 10 dig ita l

MA RST NOK ST2

PORT1 PORT2 Con Act Con Act

STATUS

RESET

Hydra2 I/O

h y dr a m a di

POK PRI MOK ST1

PORT1 PORT2 STATUS

1

DIGITAL AUDIO OUTPUTS

1

SRC

32-32

H YDR A

Con Act Con Act

STATUS 3

SRC

SRC

48V

AN A LOG

FAN

2

MA RST NOK ST2

LOW BATT

SRC

Con Act Con Act

1

POK PRI MOK ST1

MA RST NOK ST2

CF

DIGITAL AUDIO INPUTS

RESET

PSU

7 1 3 5 LINKS 7

SRC

32-32

AE S 3 DIG ITA L

RESET

1

3

5

2 4 6 8

SIG

H YDR A

H YDR A 24- 8

8

Apollo Processing / DSP /

DIGITAL AUDIO OUTPUTS

1

6

7

ETHERNET

E1

POK

RST NOK ST2 LOW BATT

9

13

15 9 11 LINKS 13 15

4

5

1 3 5 LINKS 7

R1

E0

MA

PRI ST1

2 4 6 8

D1

R0

E1

POK MOK

D1 D3 D5 D7

2

3

8 D2 D4 D6 D8

10 12 14 16

1

4 MOUSE

6

D2 D4 D6 D8

ETHERNET

MA RST NOK ST2

9 11 LINKS 13 15

2

3

7 1 3 5 LINKS 7

11

13 14 15 16

10 12 14 16

USB 1

USB 2

11 12

14 16

5

2 4 6 8

ETHERNET

POK PRI MOK ST1

MAC 3

MAC 5

10

9

12

1

4

3

6 8

10

PORT1 PORT2 Con Act Con Act

2

EXPANSION 2

ROUTER / EXPANDER ROUTER / EXPANDE

MAC 4

MAC 3

MAC 5

Con Act Con Act

32-32

FAN

STATUS 1

ROUTER 2

DSP

MAC 6

MAC 7

MAC 4

9 11 LINKS 13 15

PSU

DIGITAL AUDIO INPUTS

SRC

PSU

DSP 2

CONTROL PROCESSOR

MAC 6

11 13 15

10 12 14 16

1

4

USB

ETHERNET

POK PRI MOK ST1

DSP

9

11 12 13 14 15 16

10 12 14 16

LOW BATT

10

9

12 14 16

7

2 4 6 8

ETHERNET

D1

CONTROL PROCESSOR 1 PROCESSOR 2

DSP 1

MAC 7

10

1 3 5

R1 E1 MA RST NOK ST2

ROUTER 1

ROUTER / EXPANDER ROUTER / EXPANDER

9 11 LINKS 13 15

4 6

Router Control & Network Administrator GUI

H2 O

5

SIG

9

17

D1 D3 D5 D7

R0

POK PRI MOK ST1

PSU

AC IN

13 15

10 12 14 16

2

1 3 5

CF

OK

4

1

SRC

D2 D4 D6 D8

1 3 5 LINKS 7 ETHERNET

MA RST NOK ST2

PSU

11

13 14 15 16 9 11 LINKS 13 15

4 6

MOUSE

KBD

7

2 4 6 8

Equipment Room

MADI PORT 2

SRC

a e s 10 dig ita l

1 3 5 LINKS 7

ETHERNET

Artemis Light Processing / DSP / Router PSU

8

7

2 4 6 8

10 12 14 16

2

USB 1

9

11 12

14

MAC 5

USB 2

MOUSE

10

9

12

USB 1

USB 2

16

MAC 3

MAC 5

1

3 5

ROUTER / EXPANDER ROUTER / EXPANDER

10

MAC 4

MAC 3

9 11 LINKS 13 15

4 6

POK PRI MOK ST1

DSP

MAC 6

MAC 4

13 15

10 12 14 16

2

1

MAC 7

11

13 14 15 16

10 12 14 16

2

CONTROL PROCESSOR

9

11 12

14 16

AE S 3 DIG ITA L

30 NE T WORK PRIMER

FA

1

Apollo Control Su RESETS

CONTROL SYSTEM

RESET

However, the downside is that predictability — and therefore reliability - may be compromised when data is routed via such industry-standard Internet hardware. And put bluntly, most responsible broadcasters are not prepared to run the risk of their content being delivered with the reliability of a YouTube video.

PSU

RESET

STATUS 1

Con Act Con Act

5

EXPANSION 1

H YDR A

Reliability Vs. Compatibility As explained in Chapter Three, it is both a strength and a potential weakness of the Layer 2 and Layer 3 audio networking protocols that they are able to make use of off-the-shelf hardware. Strengths include the fact that Layer 2 protocols can make use of standard, affordable network cabling and hubs; Layer 3 protocols can use off-the-shelf IP-based routers and bridges, like Internet data traffic, and may therefore be multicast over a wide geographical area.

H YDR

8

Con Act Con Act

RESET

48V

FAN

8

H YDR A 24- 8

SIG

12R SIG

Con Act Con Act

RESET 6

48V

AN A LOG

SIG

12R SIG

STATUS 1

Artemis Control Surface

SIG

7L

STATUS

1

48V

AN A LOG

PSU

STATUS 1

SIG

Con Act Con Act

STATUS 1

48V

48V

AN A LOG

PSU

Con Act Con Act

RESET

SIG

1L

48V

3

Studio 3 RESET

7L

PORT1 PORT2

2

Hydra2 I/O 48V

AN A LOG

PSU

Con Act Con Act

48V

FA

1

Control Ro

Router Control & Network Administrator GUI

H2 O

H YDR A 24- 8 SIG

STATUS 1

FAN

8

Equipment Room

Con Act Con Act

RESET

PSU

RESET

Con Act Con Act

5

Hydra2 I/O AN A LOG

PSU

48V

AN A LOG

PSU

STATUS

1

RESET

10R SIG

Studio 2

H YDR A 24- 8

H YDR

8

H YDR A 24- 8

SIG

12R SIG

RESET

8

Control Room A MULTI-STUDIO BROADCAST NETWORK Studio 1

PORT1 PORT2

STATUS

1

Con Act Con Act

STATUS

1

FAN

Con Act Con Act

RESET

8

H YDR A 24- 8

SIG

12R SIG

STATUS

1

5

48V

AN A LOG

PSU

STATUS

1

Con Act Con Act

Calrec’s Hydra and Hydra2 networks were developed to address specific industry needs and have evolved to meet broadcasters’ rapidly changing requirements. At this point in our exploration of network technologies we will refer to these technologies to illustrate some of the challenges which are singularly characteristic of broadcast infrastructures.

1L

Con Act Con Act

RESET

RESET

However, some proprietary broadcast audio networking standards have already evolved into fully featured protocols, albeit mostly manufacturer-specific ones.

48V

48V

AN A LOG

PSU

predictability, and for many broadcasters this is a worthwhile trade-off. Modern professional broadcast audio networks, such as those installed in a multi-studio Studio 2 3 broadcast centre (below), may be routing Studio Hydra2 I/O Hydra2 I/O tens of thousands of audio channels simultaneously. The ability to do so efficiently and deterministically, without any bandwidth restrictions, whilst keeping latency low and with plenty of scope for swift recovery in the event of component failure, is highly valued.

4

5

6

7

8

Hydra2 I/O

SRC

25

SIG

SRC

26

SIG

SRC

27

SIG

SRC

28

SIG

SRC

29

SIG

SRC

30

SIG

SRC

31

SIG

SRC

32

SIG

25

SIG

26

SIG

27

SIG

28

SIG

29

SIG

30

SIG

31

SIG

32

H YDR A 24- 8 48V

1L

SIG

48V

1R

SIG

48V

2L

SIG

48V

2R

SIG

48V

3L

SIG

48V

3R

SIG

48V

4L

SIG

48V

48V

7L

SIG

48V

7R

SIG

48V

8L

SIG

48V

8R

SIG

48V

9L

SIG

48V

9R

SIG

48V

10L

SIG

48V

AN A LOG

SIG

PSU

FAN

PORT1 PORT2

SIG

48V

5L

SIG

48V

5R

SIG

48V

6L

SIG

48V

10R SIG

4R

48V

11L

SIG

48V

11R

SIG

48V

12L

SIG

48V

SIG

1L

SIG

1R

SIG

2L

SIG

2R

SIG

12R SIG

6R

3L

SIG

3R

SIG

4L

SIG

4R

SIG

Con Act Con Act

RESET

DIGITAL AUDIO INPUTS

SIG

SRC

2

SIG

SRC

3

SIG

SRC

4

SIG

SRC

5

SIG

SRC

6

SIG

SRC

7

SIG

SRC

8

SIG

SRC

9

SIG

SRC

10

SIG

SRC

11

SIG

SRC

12

SIG

SRC

13

SIG

SRC

14

SIG

SRC

15

SIG

SRC

16

SIG

9

SIG

10

SIG

11

SIG

12

SIG

13

SIG

14

SIG

15

SIG

16

SIG

SRC

17

SIG

SRC

18

SIG

SRC

19

SIG

SRC

20

SIG

SRC

21

SIG

SRC

22

SIG

SRC

23

SIG

SRC

24

SIG

17

SIG

18

SIG

19

SIG

20

SIG

21

SIG

22

SIG

23

SIG

24

SIG

SRC

25

SIG

SRC

26

SIG

SRC

27

SIG

SRC

28

SIG

SRC

29

SIG

SRC

30

SIG

SRC

31

SIG

SRC

32

SIG

25

SIG

26

SIG

27

SIG

28

SIG

29

SIG

30

SIG

31

SIG

32

SIG

32-32

H YDR A

AE S 3 DIG ITA L PSU

FAN

1

2

3

SIG

4

5

6

7

8

DIGITAL AUDIO INPUTS

1

SIG

SRC

2

SIG

SRC

9

SIG

SRC

10

SIG

SRC

17

SRC

18

SRC

25

SIG

SRC

26

SIG

SRC

1

SIG

SRC

2

SIG

SRC

3

SIG

SRC

4

SIG

SRC

5

SIG

SRC

9

SIG

SRC

10

SIG

SRC

11

SIG

SRC

12

SIG

SRC

13

SRC

17

SIG

SRC

18

SIG

SRC

19

SIG

SRC

20

SIG

SRC

21

SRC

25

SIG

SRC

26

SIG

SRC

27

SIG

SRC

28

SIG

SRC

29

SRC

H YDR A

32-32

AE S 3 DIG ITA L PSU

FAN

1

2

3

4

5

6

7

8

SIG

32-32

AE S 3 DIG ITA L PSU

FAN

STATUS 1

2

3

SIG

4

SIG

5

SIG

6

SIG

7

SIG

8

6

7

8

SIG

SIG

DIGITAL AUDIO OUTPUTS

SRC

3

SIG

SRC

4

SIG

SRC

5

SIG

SRC

6

SIG

SRC

7

SIG

SRC

8

SIG

SRC

11

SIG

SRC

12

SIG

SRC

13

SIG

SRC

14

SIG

SRC

15

SIG

SRC

16

SIG

9

SIG

SRC

19

SRC

20

SRC

21

SIG

SRC

22

SRC

23

SRC

24

SIG

17

SIG

SRC

27

SRC

28

SRC

29

SIG

SRC

30

SIG

SRC

31

SIG

SRC

32

SIG

25

SIG

SRC

6

SIG

SRC

7

SIG

SRC

8

SIG

1

SIG

SIG

SRC

14

SIG

SRC

15

SIG

SRC

16

SIG

9

SIG

10

SIG

11

SIG

12

SIG

13

SIG

14

SIG

15

SIG

16

SIG

SIG

SRC

22

SIG

SRC

23

SIG

SRC

24

SIG

17

SIG

18

SIG

19

SIG

20

SIG

21

SIG

22

SIG

23

SIG

24

SIG

SIG

SRC

30

SIG

SRC

31

SIG

SRC

32

SIG

25

SIG

26

SIG

27

SIG

28

SIG

29

SIG

30

SIG

31

SIG

32

SIG

SIG

SIG

SIG

SIG

SIG

SIG

1

SIG

2

SIG

3

SIG

4

SIG

5

SIG

6

SIG

7

SIG

8

SIG

10

SIG

11

SIG

12

SIG

13

SIG

14

SIG

15

SIG

16

SIG

18

SIG

19

SIG

20

SIG

21

SIG

22

SIG

23

SIG

24

SIG

SIG

27

SIG

28

SIG

29

SIG

30

SIG

31

SIG

32

SIG

5

SIG

6

SIG

7

SIG

8

SIG

26

DIGITAL AUDIO OUTPUTS

2

SIG

3

SIG

4

SIG

PORT1 PORT2 Con Act Con Act

RESET

3

5

Master Control DIGITAL AUDIO INPUTS

H YDR A

SIG

4

PORT1 PORT2 Con Act Con Act

STATUS

RESET

2

3

PORT1 PORT2 Con Act Con Act

STATUS

RESET

1

2

Hydra2 I/O

DIGITAL AUDIO OUTPUTS

1

SRC

STATUS 1

4

5

6

7

8

Hydra2 I/O

CSCP

3rd Party Remote Control Over Calrec Control Surface

Master Control

Production Automation 3rd Party Remote Control Over Calrec System Control Surface CSCP

Apollo ON-AIR

Artemis ON-AIR

Apollo Apollo Apollo Apollo Source 1 Source 2 Source 3 Source 4

H2 O

Artemis Artemis Artemis Artemis Source 1 Source 2 Source 3 Source 4

AES Mon AES Mon AES Mon AES Mon AES Mon Source 1 Source 2 Source 3 Source 4 Source 5

H2 O

Router Control & Network Administrator SW-P-08 GUI

Router Control & Network Administrator GUI

Hydra2 I/O

3rd Party Router Remote Control Hydra2 I/O

3rd Party Hardware Router Controller Production Automation System

3rd Party Hardware Console Controller

3rd Party Router Remote Control Apollo ON-AIR

Artemis ON-AIR

Apollo Apollo Apollo Apollo Source 1 Source 2 Source 3 Source 4

Artemis Artemis Artemis Artemis Source 1 Source 2 Source 3 Source 4

AES Mon AES Mon AES Mon AES Mon AES Mon Source 1 Source 2 Source 3 Source 4 Source 5

SW-P-08

EMBER

3rd Party Hardware Router Controller

EMBER

3rd Party Hardware Console Controller

Hydra2 Connection (Audio and Control) Hydra2 Connection (Audio and Control)

Calrec Control Interface Connection

Calrec Control Interface Connection

3rd PartyInterface Control Interface Connection 3rd Party Control Connection

3rd Party Router & Console Remote Control

3rd Party Router & Console Remote Control

Calrec Control Surface Sidecar Calrec Control Surface Sidecar

Calrec’s Hydra2

Latency & Redundancy In part the low latency of Hydra2 derives from the data structure chosen for it. As a Layer 1 protocol, its data is not packaged in Ethernet Frames. Instead, audio is sent in 512-sample chunks with no headers, but with some capacity for control data.

This method of data-packing is highly efficient, and because the start of the data is coincident with the leading edge of the audio sample clock, it contains implicit synchronisation information. The predictable arrival times of the data almost completely removes the need for buffering which reduces network latency — Calrec reckons with an 11-sample latency for an AES3 signal passing from input to output across a Hydra2 network.

centre with many control surfaces, one Router Core is always designated the master controller. This avoids unpredictable behaviour when more than one console attempts to use the same network resources. Although attached devices are aware of the entire network, if they wish to make routes through the network fabric, they must apply to the master controller. This will respond by making the routes - or in the case of conflicts, arbitrate in a predictable manner.

The Layer 1 proprietary nature of Hydra means that proprietary routers had to be developed — but again, this has a performance advantage. Each Router Core (as Calrec terms them), has a matrix that works like a synchronous TDM router, and can route one input to all 8192 outputs simultaneously if required.

Redundancy is another important issue for most broadcasters. On Hydra2 networks, it’s achieved by duplicating network hardware. Each element in the router core has a primary and a secondary circuit card, and all of the physical network connections are duplicated too, creating, in effect, two complete networks. Various mechanisms monitor the health of each component and, in the event of a failure, deploy the redundant partner.

This architectural flexibility allows the kind of highly secure operation based around a physically split Router Core located in separate facilities, as described towards the end of Chapter One. When multiple Router Cores are connected, as in a multi-studio broadcast

CALREC Putting Sound in the Picture

31

Calrec’s Hydra2

H2O & Network Management Having central control of the network has further benefits. It provides a single point of contact if, for example, the broadcaster wishes the network to be integrated with an external broadcast control system.

Master controllers which can be accessed through a browser can therefore be managed or edited remotely, such as in Calrec’s browser-based Hydra2 management software, Hydra2 Organiser (H20).

With software like this, the interconnections and routings on the network may be created, assigned and redefined on a channel-by-channel basis. Hydra2 uses graphical constructs called Hydra Patchbays. These are simply virtual routing matrices defined in H2O that determine how signals flow between the hardware connected to the network. Hydra Patchbays are a powerful tool for control room and studio resource management, allowing network administrators to put control rooms ‘on-air’ and to manage the sources available to them.

H2O provides a variety of other network management services, including the management of access rights, which can confer or deny right of access of consoles to selected network resources, and the protection of in-use ports from inadvertent overpatching by other network users.

Both of these are front-line requirements for broadcasters and commercial facilities that may rent out different studios to different (possibly competing) broadcasters.

32 NE T WORK PRIMER

Imagine one studio complex with three studios, which can all be assigned to work together, or divided into three independent studios rented to different clients. In cases like this, the master controller must apportion the network so that the client renting one studio cannot see the other studios, consoles and routers on the network, much less access them. And at the conclusion of the rental period, the network has to be reconfigurable so that the three studios, and their Router Cores and control surfaces, can access one another again. All of this is possible using the network management features of Hydra2 via H20, and was implemented in response to requests from broadcast studio complexes who wanted these facilities.

Broadcasters also contributed to the development of another contingencyrelated network feature in Hydra2 — alias files. The requirement came about in networked multi-studio broadcast complexes where clients suddenly had to move from one studio to another due to unforeseen maintenance requirements or double bookings. Taking the desk settings across to a new studio in the form of a desk memory is easy — the settings files are small enough to be portable on a memory stick — but when the memory is loaded in the new studio, clients would find that all the input and output assignments for the console were wrong, because they had been assigned for the original studio, with an often radically different set of wallboxes, outboard and interconnections.

To make desk memories more portable on a Hydra2 network of connected consoles, Calrec worked with a major European broadcaster to develop the concept of console assignment alias files, whereby I/O assignments are made not to specific network ports but to aliases of ports. Another file, specific to that console, then maps the aliases to the right ports for that desk and studio. This way, if a desk memory is brought in from another studio, or a show is moved from one studio to another, the local console alias file will map the inputs and outputs to correct connections in the relevant studio, irrespective of how the memory has been set up.

Calrec’s Hydra2

Compatibility With Other Standards Ways to interface Hydra2 networks with other network protocols are planned. As mentioned briefly in Chapter One, Hydra2 already passes several hardware control protocols (of which more in the next chapter) and as we have seen, there is a widespread desire amongst broadcasters to make their equipment interoperable.

Responsible manufacturers will all play a role in this. As a manufacturer, Calrec doesn’t view the work of the AES-X192 group, ALC Networx or the AVNU Alliance as replacements for Hydra2 — it is hard to see them having the latency, determinism and capacity of such a purpose-designed protocol as Hydra2. However, they can be regarded as excellent potential companion technologies, and adding a Ravenna or AVB interface to a Hydra2 network could provide a flexible and low cost way of connecting to intercom systems, plant routers, hard disk recorders, speakers and even microphones. Calrec supports these efforts, has recently become a member of the AVnu Alliance, the stakeholder group for AVB development.

CALREC Putting Sound in the Picture

33

34 NE T WORK PRIMER

CHAPTER FIVE Control Protocols & Networking

calrec.com

Putting Sound in the Picture

Control Protocols & Networking

In the course of this Primer so far, we’ve looked at the current efforts to create common standards for interfacing broadcast equipment over a data network, and to provide some measure of interoperability between audio and video equipment.

But recent protocols and standards such as Ravenna, AVB, and X192 are only the latest in a series of efforts that have been made through the decades to get video and audio hardware talking to one another.

Long before the advent of data networks and broadcast facilities connected with CAT5 cable, video switchers were able to exercise basic control over gain settings on some audio consoles, or control source and destination patchings on connected audio routers via simple serial control protocols. Most of these predate the computer networking era, but have survived into the modern age because they are simple to implement and provide basic and convenient interfacing between broadcast audio and video hardware...even if their capabilities are limited compared to the kind of interoperable standards now under development.

Calrec’s current product range, for example, supports the basic Ross Video hardware control protocol (more on this in a moment), as well as the even more venerable but widely supported SW-P-02 and SW-P-08 serial protocols (also known as General Switcher/General Remote), originally designed by ProBel to allow their own products to control switching and routing assignments on their routers, and now used industry-wide.

This approach makes sound commercial sense. By incorporating support for existing control protocols into their audio networking standards, manufacturers that advocate the use of networks ensure that broadcasters can still use the convenient

36 NE T WORK PRIMER

control protocols they’re used to, even after a move to network-based workflows.

For example, for broadcasters used to controlling stand-alone audio routers from their video switchers via protocols like SW-P-08, support in current and future networking standards allows broadcasters to continue directing audio from video hardware in a way familiar to them…even if the stand-alone audio router has been completely dispensed with and audio is now being routed via the network.

Broadcast audio hardware manufacturers currently provide compatibility with audio/ video control protocols in three main ways: 1) By means of existing widely used but rather limited generic protocols (such as SW-P-08/02); 2) By adapting or extending existing control protocols, thus building on existing standards while widening the capabilities on offer (for example, Calrec’s extension of the Ross Audio Protocol (CSCP)); 3) By promoting and becoming actively involved in the development of newer control protocols, such as EMBER, whose abilities are still being extended and defined.

Control Protocols & Networking

SW-P-08/02 & RAP SW-P-08/02 is a great example of a limited control protocol whose use has become widespread because of its simplicity, similar to how MIDI has been survived in use in the world of musical instrument interfacing despite being decades old and thoroughly superannuated in terms of its feature-set.

In truth, the lack of a need to pay to license SW-P-08/02 from ProBel and the low cost of implementing it in hardware probably play also a significant part in its widespread commercial adoption.

However, SW-P-08/02 is distinctly limited, and cannot achieve much beyond allowing a video switcher to direct one input on an audio console’s router to another output; even adjusting the channel gains on a connected mixer is beyond its capabilities.

Whilst many manufacturers support it, the demands of today’s modern broadcast control centres require more than the ProBel protocol has to offer. Ross Video’s audio control protocol, known as RAP, is more fully featured, allowing control of fader levels and a few basic audio parameters.

CALREC Putting Sound in the Picture

CSCP & Automation Calrec supports both of these control protocols in its Hydra2 audio networking standard, which passes RAP and SWP-02/08 data down its connections.

But the company has also extended the RAP protocol to create the Calrec Serial Protocol, or CSCP, which allows control of channel levels, audio channel pan settings, and buss assignments and routings, which is transmitted over Hydra2 networks.

Through collaborations with other video hardware manufacturers such as Grass Valley and Sony, support for CSCP has gradually been extended, allowing broadcast control systems such as Grass Valley’s Ignite, Ross’s Overdrive, or Sony’s ELC to integrate audio consoles into their workflows.

This is attractive to many broadcasters as it offers the kind of automatable integration of video and audio systems that they have been calling for, permitting greater levels of production automation.

However, the list of audio parameters that you can control from video equipment via the Ross or Calrec protocols still falls short of complete interoperability, and remains far from exhaustive.

37

Control Protocols & Networking

EMBER Perhaps the most promising development in the world of control protocols is the kind provided by LSB’s EMBER: a fully-featured, open source protocol whose capabilities closely reflect the requirements of modern broadcasters.

The still-developing EMBER communication protocol was created by the German company LSB, manufacturer of the excellent Virtual Studio Manager broadcast control software, and provides one of the foremost examples of how video and audio integration could proceed in the near future. A proprietary protocol, but one open for use by third-party manufacturers, it’s being supported by leading audio hardware manufacturers such as Lawo, Stagetec, Studer and Calrec, and recognises in its design the fact that broadcasters ideally want to be able to hook video equipment to audio equipment via a network, turn everything on, and simply begin controlling one from the other.

Using a standard client/server model an EMBER server, will first describe all of the equipment on the network it’s connected to, and all of the parameters in that equipment which it can address, and then facilitate communication between the EMBER client in broadcast control software such as VSM and the EMBER server on the broadcast network. When a piece of EMBER-compatible audio equipment is connected to a broadcast network running an EMBER server, the controllable parameters of that device are automatically described and made addressable over the network via the EMBER protocol.

Similarly, if you hook some EMBERenabled broadcast control software to a network containing various types of EMBER-compatible audio and video

38 NE T WORK PRIMER

equipment, the software can begin controlling the equipment over the network without any prior knowledge of the network and its addressable components and parameters.

The list of controllable parameters that are addressable via EMBER is growing as customers request more features and participating manufacturers widen their support accordingly. Unsurprisingly, because the protocol is still being rapidly developed, the limits of EMBER are being tested with modern demands that go way beyond the simple control of gain and pan settings offered by older protocols.

To take a recent example, the ability to control the addition of Dolby metadata into an embedded audio stream has been added to Calrec’s implementation of EMBER.

The Future of Broadcast Networks?

Like all aspects of broadcast audio networking described in this Primer, development of EMBER is still proceeding apace — but even with its capabilities today, it gives a tantalising glimpse of what might be possible in the near future, when interoperable standards are more fully developed. If this Primer has a message, it’s to emphasise that networking technology is on the brink of delivering unparalleled audio and video integration to broadcasters in many areas, even if some aspects still remain just out of reach. Even half a decade ago, such claims would have been dismissed as misty-eyed exaggeration — but today, as we have seen in this book, the scale of developments on all fronts leading to an interoperable future can no longer be denied.

CALREC Putting Sound in the Picture

39

Calrec Audio Ltd Nutclough Mill Hebden Bridge West Yorkshire England UK HX7 8EZ Tel +44 (0)1422 842159 Fax +44 (0)1422 845244 Email Enquiries@calrec.com calrec.com

(926-185 Iss.1)