Showing posts with label AVB. Show all posts
Showing posts with label AVB. Show all posts

Thursday, May 28, 2015

Pixels and Erasable Ink - Could I be wrong?

Those of you who follow my musings on the world of professional AV know that I can be skeptical at times. I'm skeptical about AVB. I was skeptical about video over IP. I'm skeptical about the continued value of HDBaseT. What I try not to be is cynical; it's good to start off questioning new assumptions, but it's equally important to balance those questions with an open mind. Technology, after all, is not a static thing. What made sense yesterday might be pure folly tomorrow. With that in mind, I'd like to tell you about two points on which I might be wrong.

AVB - Is it dead yet?
This is a question one of my colleagues asked me last year at the Infocomm trade show. The question had a pleading tone, as if wishing for what increasingly looks like a zombie technology to be put out of its misery. We'd all seen the same proof-of-concept video-over-AVB streaming demo two years running at that point. We saw one major DSP manufacturer choose an audio transport system based on AVB while nearly everyone else chose Audinate's Dante protocol. We saw the major manufacturers of network switches decline to support AVB year after year. In short, we saw a very promising technology losing a format war.

Or did we?

After years wandering down the same dead-end path, the AVNu alliance (the people behind the creation of the AVB standard) finally realized their biggest problem. It's a problem unrelated to bandwidth requirements of low-latency AV transport, unrelated to network traffic shaping, unrelated to questions of layer 2 or layer 3 protocols. It's so simple a problem that we can all understand it, and we all should have seen it sooner.

The problem is the name.

The problem is that the name leads to comparisons like the one I just made with Dante which is, to be honest, a poor comparison.

We've all known for years that AVB is not a streaming technology; it is a suite of IEEE 802.1xx standards for bandwidth reservation and time synchonization over networks. Solving the "lip sync" problem for separate audio and video streams is one application of this technology. It is also of vital importance, for example, in syncing control and sensor signals for electronically controlled manufacturing processes. Whatever transport technologies we use today can be enhanced by access to the tools within AVB, not replaced by them. The debate between AVB and Dante is a bit like saying that you don't believe that a series of new high-speed carpool lanes  would make a difference because you're driving a Prius. It's a non-comparison.

The problem is that the name "AVB" for "Audio Video Bridging" sounds like a transport technology and has been, to a very large extent, marketed as one. What does AVB do? It creates a bridge over which one sends audio and video signals.  Audio manufacturers with AVB compliant products don't help this when they describe "audio over AVB" not "network audio taking advantage of AVB's timing protocols".  I know that AVB is a suite of 802.1xx standards, but when I hear the words "Audio Video Bridging" my brain sees a transport protocol. As is often the case, language informs thought.

To solve this problem, AVB has picked up a new name; TSN or "Time Synchronized Networking". This divorces AVB from the "A" and the "V", aligning the language with what the standard actually is.

So will our future AV over IP systems take advantage of these new protocols? Perhaps - if those are the systems we build. Or perhaps there won't be a large enough volume of networks requiring time synchronization for these tools ever to be widely adopted. Time will tell.

For AV transport, there is another option.

HDBaseT - A Bridge to Itself?
I, and many others, have described HDBaseT as a "bridge technology" between yesterday's point-to-point systems and tomorrow's video over IP systems. In an earlier post I spoke about the value of HDBaseT and what advantages and disadvantages it has over IP video. Most of that is absolutely correct today. It might be the opposite of correct tomorrow.
The bridge is a metaphor

I had the pleasure of a terrific conversation with Micha Risling, marketting director of the HDBaseT alliance. Mr. Risling pointed me to part of the HDBaseT 2.0 specifation I'd admittedly payed too little attention to at the time. Take a moment to look at this image from the HDBaseT alliance website, comparing 1.0 to 2.0.

Does that look familiar to you? It should; it's quite similar to the OSI stack. For years we've thought of HDBaseT as something that looks like an IP network but isn't; it's a point to point transport technology using the same physical topology - but no the same logical topology - as IP.

Or is it?
This layercake looks familiar
(image from HDBaseT.org)

There is, as of the release of the 2.0 spec, no reason that HDBaseT cannot exist in a packet-switched environment similar to any other network, using "HDBaseT switches" more akin to the network switches we know and love than the AV matrix switches of today. Such switches would use an internal addressing scheme, signals would be routable between switches, and the overall scalability problems of current HDBaseT systems would be a thing of the past. The HDBaseT alliance sees their dedicated video network as a better solution than a "converged" network for AV transport. Bandwidth requirements for uncompressed video - especially at resolutions of 4K or beyond - could be, at the very least, challenging to implement on a larger network. HDBaseT is purpose-built for video transport with, they claim, better cross-network optimization than the IP we know and love.

Will all of this come to fruition? I don't know; what I DO know is that the chipset for such an "HDBaseT switch" is in development today, and that we might not be that far from seeing HDBaseT as a packet-switched technology rather than point-to-point as is currently the case.


If HDBaseT has a "language problem", it's the opposite of the problem AVB has; as HDBaseT sounds enough like "100BaseT" (fast ethernet) and "1000BaseT" (gigabit ethernet) to cause confusion, we've all worked very hard to remind ourselves that it is a very different thing with a different logical topology. That it might not be so different after all is, to say the least, jarring.

Will the benefits of HDBaseT switching balance the challenges of deploying and maintaining parallel but separate networks? Will the demands of video on converged networks push us to separate networks anyway? Many questions remain and the devils are, as always, in the details.

Whatever may come, we'll talk about it when it gets here. You can expect to hear me question it, but with an open mind and open eyes.
Time will tell if my initial guesses are proven right or wrong.

Friday, February 28, 2014

On Language, Juggling, Lunchtime in the Park, AV, and Networks

Quite a few years ago I earned the CTS (Certified Technical Specialist) certification from Infocomm. 
Last year I began studying to take the ICND1 (Interconnected Network Devices) in pursuit of my first-ever Cisco certification. 
Last week I started learning to throw a juggling pattern called a 4,4,1.

What do these three seemingly disparate items have in common? At their core, they are all largely about language.
Bryant Park in Winter

We'll start with the end, at 4,4,1. It's a fairly simple trick with which I'm still trying to convince my hands to cooperate. Throw a ball straight up with the right hand, then straight up with the left hand, then zip the third ball straight across from right to left. Repeat in the other direction. Repeat in the first direction again. It looks pretty nifty, and can lead to other tricks.
Office Juggling Selfie!

The part I didn't get (aside from the accurate catching and throwing, which kept eluding me) was the name. Finally, I asked one of the more experienced of the Bryant Park Jugglers. For those of you who don't know, Bryant Park is a smallish park behind the main branch of the New York Public Library on 42nd Street. It has a lawn in the summer, an ice-skating rink in the winter, a fountain, a carousel, a statue of Gertrude Stein and, of course, jugglers (and ping-pong, and even the occasional super-literate topless women).  The answer was simple: a "one" throw is that quick lateral pass, and a "2" is the ball held in hand for a beat. After that, the numbers sync up with the number of balls one would be juggling: a three is a lob from side to side as if it were part of a three ball cascade. A straight up and down toss caught by the same hand that threw it is a "four" because that's what you throw when juggling four balls. A double-height three is a five because the standard five-ball patter is like a three only higher. Etc.
Bryant Park in Summertime

Why is this exciting to me, and why is it important? For the same reason that the CTS was important, and the same reason that a basic understanding of routing and switching is important. I've described the most important part of the CTS as learning the language of AV; someone who passes might not know enough to install, test, commission, or design an AV system, but they would know enough to talk about it. Knowing the names of various connector types, what various signal formats are called, and other technical terms is the first step to being able to learn more. Before newcomers to the industry for example, can learn about various methods of EDID management and emulation they need to know what EDID is in the first place. To give instructions on wiring, testing, routing, and patching a video-edit system without the assumption that ones audience will understand the terms "SDI", "BNC", "Router", "Patch-panel", or "coax" is  an exercise in frustration; it would be like having to describe what a steering wheel, a tire, or a road is before giving someone directions to your house.

This goes a long way to explaining why I'm approaching network certifications. Not only are modern AV systems are increasingly dependent on data networks in order to function, but future AV systems might actually be components of a larger converged network. Systems being designed and installed today might use network-based protocols such as Dante or  AVB for audio transport, video streams encoded as H.264 or similar, and centralized IP-based control systems. From a system design perspective, different protocols and systems have differing network requirements as well as final AV requirements. This adds another step in evaluating varying technologies 

What was once a simple matter of needing a network port now becomes a more complicated discussion in which ports are needed on separate VLANs, in which a layer 3 switch may be required, in which certain devices need to communicate across networks, in which switches need to be configured with various services or protocols. Suddenly "give me a data port" isn't enough. 

This is different than mere jargon; the phrase "layer three switch" or "balanced audio" or "four-four-one" aren't simply fancy words: they stand for concepts that, absent the language for them, we might not even realize exist. It's important to be able to communicate network or AV requirements in a manner which is understandable and professional. It is vitally important to see these concepts in the first place and to internalize them to the point that they become part of how we think about our jobs and the world around us. For this we need to learn the language. 

I'll have more details on this later (including my impressions on some current technology on the market). For the nonce, I'll leave you to reflect on the importance of language.

And if you happen to be in my city, drop by the park around lunchtime. You might find me there, and we just might have a ball.



Not my good set of juggling balls

Tuesday, December 24, 2013

A Pixel and Ink Stained Year in Review

IT's the end of the year as we know it. This year in review and its companion peek into my pixel and ink-stained crystal ball at the year coming up will be largely "pixel" posts in that I'll talk about commercial AV. Perhaps one or two literary mentions to round things out. And more on the Year-to-Come post later. This is a very quick highlight of just a few AV trends from the past year. There is, of course, more. There's always more. For now, in no particular reason are some thoughts that stuck in my mind from 2013. 

My look forward at 2014 will come as part of the SMW team on our ExpresShen's blog. You'll still see me here, but I'll also be spending some time there along with some of my very bright and talented colleagues, not only in the AV discipline but our data, security, medical planning, and acoustics disciplines as well. That should be an exciting part of the new year and something in which I am greatly looking forward to participating.

2013 was the year....


....that the HDBaseT "standard" hit a saturation point and stopped being interesting. 

Crestron, AMX, Extron, Kramer, Aurora, Purelink, Lightware, Muxlabs, and probably a half dozen others I'm not thinking of at the moment all have what is, for all intents and purposes, the same digital videl ecosystem: modular card-frame based switcher, smallish form-factor standalone transmitter/receiver units, 2-gang wall plate transmitters, etc. Some added an array of input and output formats (3G-SDI, VGA and other analog formats, etc), most have single- and multi-mode fiber options, and if you squint just a bit it's hard to tell which one you're looking at. I kinda flew through the "HDBaseT Pavillion" at Infocomm without too much catching my eye. 

This is part of the reason I'll not post on "switcher wars" anymore; so many of the decisions are so project-specific that it's almost impossible to compare various manufacturers in a vacuum. Do you need SDI outputs to feed a production switcher or capture appliance? Multi-format inputs for a variety of legacy devices? SDI inputs for broadcast cameras? A smaller form-factor and lower heat load because you're stuffing it into a credenza? Does it need to fit with some existing asset management infrastructure? Projects aren't one-size fits all, and we've gotten to the point at which we look at subtle details rather than "this one is good. That one is bad." 

....but some manufacturers have found ways to step out of the box

I'll list two that surprised me a bit. One is the Altinex Muse, technically not quite HDBaseT, but similar technology and interesting nonetheless. Their innovation (shown off in a pretty popular booth at Infocomm) is 150W of AC power right at the receiver. This means that you can plug in a smallish flatpanel with nothing but a single Cat5e or Cat6 cable and without an electrician. Highly groovy and a bit surprising.

Another one that caught my eye is Aurora Multimedia's L2 series of receivers. These have a tiny webserver and control processor built into them. This is terrific for very small, one- or two-input rooms with fairly simple control needs. It lets you run the space with a single-gang decora-style keypad *and* monitor it via your favorite building-management solution. I'd rather have a more robust control system for more complex spaces, but this is a thoughtful solution which certainly has its place.

....Dante took the lead in the digital transport battle

No. Not that Dante.
Audinate's Dante and the AVNu Alliance's AVB are the two available choices to replace the aging Cobranet protocol. 2012 saw Audinate introduce Ultimo, a smaller chipset capable of handling two inputs and two outputs. 2013 saw manufacturers such as Atterotech and Stewart Audio release an array of small form-factor amplifiers and breakout boxes, including wall-plates. A virtual sound card is available to bring multiple channels of audio into and out of a PC (for processing, recording, streaming, or any other purpose one can think of), digital mixing consoles have accepted Dante as one of several standards they support, an a variety of DSPs are now using Dante for audio connectivity.

The real surprise for the year  - and the reason I see Dante as taking the lead - is that Audinate announced that once AVB is ratified as a standard it would be possible for Dante-based hardware to become fully AVB compatible. The folk at Audinate tell me that this would be either/or; one could run the hardware as a Dante system using any layer three switch or as part of an AVB network using the added features in AVB-compliant switches. This adds, at the very least, a future-proofing security blanket.

...but not everybody gave up on Cobranet


A speaker with Cobranet
Amplifier built in!
I thought this would finally be the year we stop talking about Cobranet, but that seems to not be the case. Soundtube opened the year with the introduction of IP-addressable speakers using the venerable Cobranet protocol. Their stated reasons for sticking with this over Dante are that the Cobranet chip is small enough to fit into the speaker back-can along with an amplifer.  They also contend that, for many applications, the latency and channel counts available from Cobranet is more than sufficient. I have my usual level of skepticism, and am concerned about the extra layer of complexity conversion to Cobranet will add in systems which are primarily Dante or AVB. That said, there is a somewhat compelling point and it does seem an interesting solution for certain applications.



...we learned to think small

2013 saw quite a few collaborative solutions for small "huddle" type spaces, from Barco's smaller (and cheaper!) clickshare to Vaddio's Groupstation and wired pushbutton collaborative interfaces from FSR, Extron, and others. This fits not only with different ways in which people are working, but also with the growing prevalence of software-based communications tools as either a supplement to or sometimes a replacement for appliance-based enterprise videoconference systems. Many of us have some combination of Skype, Google Chat, or Apple Facetime either at home or on a personal device. Some of use  Microsoft Lync, Cisco's WebEx or similar on our desktop machines. We become familiar with these technologies, comfortable with them, and look for ways to expand them to use in room systems. Sometimes this sacrifices quality, but especially for small spaces can give a measure of functionality at a fraction of the price of hardwares solutions.

...The blackbirds roosted in the pomegranate tree

What? I'm sure you were expecting something on streaming (another post) or 4K (another other post!) or the like. Instead, I'll close with a literary note. Almost two-decades ago, American writer Mary Ellen Sanger spent six weeks in a Mexican prison. I met her years later at the home of New York-based author Talia Carner as part of a writers' critique group. This year, she finally published a book telling the stories of her time in prison and the women she met there. There are beautifully written, poetic tales. If you're looking for something thoughtful, interesting, and different to read this holiday season, feel free to pick up a copy in dead-tree or Kindle format. Enjoy!

That's the year past. Stay tuned for the year to come, nestled sometime between Christmas and New Years.

Happy Holidays!
  

Tuesday, June 18, 2013

Infocomm 2013 - Part the Second. Death of the AV System?

Part two of my Infocomm recap, in which I'll talk about the bigger stories. I managed to learn about several things, including classes on various AV networking protocols (present and future) and mass-notification systems and some private chats about large-venue speakers, MS Lync integration, and personal branding. The show floor is an impressive array of glittering toys,  but the level of human talent at the show is even more impressive. I hope that the rest of the attendees got to meet as many brilliant people as I did. Now, on to a few things that caught my attention in a big-story way.

I know that the "Death of the AV System" is a provocative title, and I don't really expect our business to completely vanish anytime soon. What I do see changing is the existence of an AV system as an entity separate from the larger information technology infrastructure. One word I kept hearing is "convergence". We're quickly approaching a point at which room systems, unified communications, paging, emergency notification, and the larger world of IT are no longer separated by bright lines. Further, there is increasing availability of software-based solutions to needs formerly fulfilled by dedicated appliances. What did I see that fit this mold?

Barco AV over IP Demo
One exciting group to visit was the AVNu alliance pavillion. They're pushing hard for the adoption of the AVB standard, and by now have a fairly impressive array of manufacturers involved, including Biamp, Meyer Sound, Renkhus-Heinz, Yamaha, and Barco. Barco was especially interesting in that they had a demo of video transport over an AVB network. The unit they were showing is only a trade-show demo, but a brief chat with them was enough to whet my appetite for further news. For those few of you not keeping up, most AVB solutions rely on the IEEE 1722 protocol for transport, which is a level 2  protocol inoperable without an AVB-compliant switch. Barco's unit uses a similar level three protocol which will send real-time uncompressed video over any standard switch (with, I assume, the same caveats the folks at Audinate gave about Dante; it needs sufficient bandwidth, needs certain QoS features, etc). Add to this less bandwidth-intensive solutions like SVSI's JPEG2000 encrypted video and another vendor with even lower bandwidth proprietary JPEG2000 variant and there are suddenly a suite of choices for what looks like full-matrix switching without an actual matrix switcher!

This is part of what I mean about the death of the AV system. One of my colleagues went so far to say that I was wrong to frame it as a virtualized matrix switch; that the better way to look at it is the transformation of sources, displays,  microphones, and speakers from elements of standalone systems to a suite of tools usable by software running on the PC, which is already moving into a central position in the AV system. It means that the traditional topology of a system (inputs --> Matrix switch --> outputs) might be ready to fade away.

In a similar vein on the unified communications front was one of the new exhibitors about whom I'd heard some pre-show buzz: the forgettably-named but memorably-trousered industry veterans at Pexip. Their founding members were a good part of the brainpower behind former videoconference giant Tandberg, and they're back with a completely software based approach to conferencing. Pexip's virtual MCU can live on any standard server, can easily be scaled up or down in number of licenses, and allows impressively high-quality conferencing among multiple platforms. Traditional hardware-based endpoints, software clients, an even SIP-based audio calls fit together seamlessly. Those without either a hard or soft endpoint can connect through WebRTC, an HTML5 browser-based Codec which doesn't require downloads, plug-ins, or any other special effort to set up.  Bob Romano of VCA has a three-part interview with them in which they discuss their origins, the software-MCU concept, and how their approach answers concerns regarding bandwidth and security. They had a nice demo in which they showed both interoperability and how the system seamlessly handles network disruptions, losing only those callers  Pexip is impressive, but are far from alone. Vidyo and newcomer Starleaf offer cloud-based MCUs, as does the venerable Polycom.  Lifesize gives you the option of virtualizing their MCU. These approaches and the various products involved all have enough pluses and minuses that a substantive post can be written about just those.  For the nonce, let is suffice to say that it's an interesting time in which the hardware and software can be more easily separated than ever before.

What else can be virtualized? How about a control system? Relative newcomers HRS Control  have an architecture which fits on a Windows or Linux server. Is this going to be a Crestron or AMX-killer? Doubtful; I've not seen it up close yet, but it doesn't look as if it has the breadth of support and level of sophistication that the best commercial control systems currently have. Could this mean, within the next years, that control companies might move to software the way VTC companies have? Time shall tell.

What about Crestron and AMX? Crestron made a strong move to embrace chance with the introduction of its Airmedia video-over-wifi device as well as a Lync Room System (RL). Airmedia is a nice product in that it's simple and, at an MSRP of $1600, relatively inexpensive. This is one place where I break with Gary Kayye who included the Wow Vision Collab8 on his top-ten tour. I agree with Gary that the Collab8 is an impressive piece of hardware with more capability than the Crestron device, but it also sports a $5000+ price tag. Gary's theme was collaboration - the ability to bring people together through technology. I am looking more at convergence - the melding of AV systems and the PC-based office infrastructure. From that point of view, I find it hard to justify such a high-cost appliance with a single use profile. These items are competing not only with Barco clickshare, but also with a standard room-PC running a WebEx session. Smaller might be better. The Room Lync system didn't seem interesting at first blush; Microsoft has put enough restrictions on these that it's hard for vendors to offer much differentiation. Crestron is offering a mindful solution in that they've taken steps to address issues with handling logins and with the ability to tie into a Crestron infrastructure or not. Years ago, Crestron was in the forefront of the move to digital video transport. I'm not sure where this year's offerings will take them, but they clearly are attempting to continue to look forward.

AMX took a different tack; rather than embrace the PC in a room environment, they're looking to replace it with their Enzo device. This is a small network device which can handle cloud access, integrate with existing dropbox accounts, run some applications, and provide basic room control. It's a very different approach to Crestron's, and one which offers an ease-of-use and integration which is arguable higher than that of a PC-based system. I'm not sure that it is as forward-looking, however. The future looks like it will embrace the PC, not replace it. Once again, time shall tell.