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.

Camping Out on the Bridge - is HDBaseT Here to Stay?

Last week I appeared on the AV Powerup podcast to discuss, amongst other things, HDBaseT. Taking the time to listen to myself (this is a sign of responsibility to monitor messaging and personal branding, not at all vanity. Honestly) it seemed that I was quite negative on HDBaseT as a technology - I described it as largely a bridge between the point-to-point systems we build yesterday and the shiny new IP systems we'll be installing tomorrow. (You can hear the entire conversation, with Malissa Dillman of Kramer along Corey Moss and AVPowerup's usual cast of characters - here on rAVe Radio). After sounding what sounded like a death knell for HDBaseT I went to sleep and, the next day, went into the office to work on four projects, two of which will use HDBaseT transport. So... is HDBaseT here to stay? Is it a bridge we're crossing - or have already crossed? What's the place for it today?

Separate Networks and Separate Networks
If one is deploying video over IP, one needs to be careful to assure proper network configurations. This could mean QoS to prioritize latency-sensitive video traffic, IGMP settings for multi-cast streams, and other considerations. This will very often involve a logically separate network and, in some cases,  a physically separate network. A physically separate network consisting of structured cable, endpoints, and a dedicated switch for AV traffic sounds very much like the definition of an HDBaseT system. True, it isn't an IP-addressable system and, as such, there is no equivalent to "switch hops" within an IP-based system which allows a single logical network to be built with many switches. And yes, there is no "routing" equivalent allowing communication between networks. In the majority of AV use cases none of these are issues. In quite a few cases (including several of the projects on which I am now working), AV systems are largely self-contained and if they are to expand it will be via a higher-latency lower-bandwidth compressed signal such as H.264/H.265.

Why is IP the future?
That said I still firmly believe that IP is the future. Why?

First, scalability. It is very, very easy to add endpoints to an IP-based system. All one needs is an open switch-port or, at the very worst, another network switch. Expanding an HDBaseT system will often require shutting the system down to add input or output cards and, past "choke points" (8, 16, 32, 64), an entire system redesign. There's no good way to expand a full 16x16 switch, for example, without throwing it away and starting over again. IP-based systems are easy to grow and don't have the inherent size constraints that HDBaseT systems have.

On a related note, IP-based systems are flexible - not only because any IP video stream can be routed system-wide, but because it creates easy means of manipulating video streams. Adding a transcoder, a windowing processor, recording appliance, or anything else becomes a simple matter of connecting another network device. Manufacturers of network-based systems often create ecosystems including quite a few ways to manipulate the video stream.

There is a universality to using UTP for IP routable endpoints and only IP routable endpoints. One ends up with a single structuted-cable contractor for an entire job and no confusion with cables that look like network cables yet aren't. While this seems like a small issue, it does create an increase in efficiency in terms of both installation labor and infrastructure, as well as simplifying the physical system topography.

Why is HDBaseT Not Going Away
Even as IP is clearly the future and, increasingly, the present, I see new HDBaseT products appearing with some regularity. For AV systems which fit comfortably into a single HDBaseT switch there is a measure of simplicity in using dedicated, purpose-built AV switching hardware. Because we're dealing with a dedicated AV switch rather than a standard network switch, we can get local inputs and outputs for AV devices co-located with the AV switch. Eliminating the need for a transmitter or encoder at each device can, in systems with local sources, decrease overall wiring and count of individual devices.

The innards of an HDBaseT Wallplate

HDBaseT is also present in the "all-in-one" presentation systems which combine video routing, audio routing, audio amplification, and AV control in a single box. A system appropriate for a presentation switch such as this would usually be point-to-point, and gain little if any benefit from IP routing.

A big positive for HDBaseT is that it is a standard with a measure of interoperability; IP video transport is, at present, not. Yes, IP is standard, but different product lines do not allow their streams to be decoded by competitors. This means that, for example, a videowall processor with HDBaseT inputs can take a signal from an HDBaseT transmitter and then send it to HDBaseT embedded displays. An entire pair of transmitters and receivers just vanished! There's not yet the universality to do this yet with IP-based systems. I'm not sure when or if there will be.

So today, is IP better than HDBaseT? The answer is the same as the answer to every AV question:

It depends.

Fun with HDBaseT

HDBaseT has been described as a bridge technology between traditional video transport and IP-based systems, the time for which is rapidly arriving. It's a technology about which I've not been excited for some time; every manufacturer not only uses the same chipset (produced by Valens), but appears to have settled on the same form-factor and product line. There's the standalone transmitter, the standalone receiver (with or without scaling), a 2-gang wall-plate transmitter with VGA and HDMI, a single-gang HDMI-only transmitter, and card-based modular matrix switches in 8x8, 16x16, 32x32, 64x64, and sometimes 128x128 sizes. Are there any innovations to be had in this realm and, more importantly, do they matter? To answer the first question, there are three products I've seen recently which I find interesting. As to whether or not they matter, time will tell. At present there is still enough need for point-to-point transport that HDBaseT types of solutions can have a place either in place of IP-based systems (for small, single-room systems)  or as part of a hybrid system (for larger deployments).

Lightware
I had the pleasure of meeting the Lightware team last month here at Primeview's showroom in New York City. In addition to having the foresight to build their matrix switches with a high enough bandwidth backplane for 4K content, Lightware has a few interesting quirks. One is that their matrix frames each have a single local input and output, sizing them at 9x9, 17x17, etc rather than the traditional 8x8 or 16x16. It's a very minor point, but one that has the possibility to save design headaches in those rare, specific situations in which one has, for example, a ninth input and doesn't want to move up to the next size frame. More practically, because it's a local-only output it creates an easy connection point for a rack-mounted monitor. Nice? Yes. Groundbreaking? Not really.

Lightware ModeX Tx/Rx, matrix switch, and
other goodies

The other item of which they are proud is their Modex line of HDBaseT extenders. This is an interesting mix-and-match concept in that the standalone transmitter and receiver boxes are populated by modules; one for copper or fiber transport, one for audio or video inputs, etc. This allows one to purchase units with exactly the desired connectivity. Sadly, the modules are neither user-swappable nor available for purchase a la carte. If they were, it would be an intriguing way for contractors to create a transport "toolkit" in which they mix-and match modules on the fly for specific purposes. Hopefully this will come someday.

Hubble 
While I tend to think of Hubble as an architectural connectivity company rather than a source of electronics,  they do have an AV division producing active devices, including HDBaseT extension. Their "110 AV" line is interesting in that, unlike other AV over twisted pair transport, they connect via  110 punchdown blocks rather than RJ45 jacks. This is more in line with BICSI wiring standards (as well as common practices by teledata contractors), which indicate that field cable is NOT to be terminated to a male connector. In fact, the only people one is likely to see field-terminating UTP  are audiovisual contractors. This not only creates a potential failure point, but makes packaging AV wiring with the rest of the structured cable contract a challenge.

Speaking of wall plates, they have taken advantage of their line of power receptacles to create what stands out in my mind as the most clever means of locally powering a wallplate device. They've modified one of their standard duplex receptacles with a low-voltage DC pigtail to run into the back of a single-gang wall-plate HDMI transmitter. Both transmitter and receptacle can then be mounted together in a custom 2-gang wallbox with an integrated low-voltage divider. It's a neat way to combine device power with video transport.

Hubble's single-gang transmitter and power, also with
USB charging!

Hubble's weakness here is that they lack the scope of most other participants in this market segment; they have perfectly reasonable point-to-point transmitters and receivers, but lack the matrix switches, scalers, and other units we'd expect from a more AV-centric manufacturer. They've also, as of yet, not done enough homework on interoperability to be able to tell us which display manufacturer's integrated HDBaseT receivers with which their transmitters will work.  This, sadly, limit
s their usefulness.

Crestron
This is the one item I've not physically gotten my hands on, but it's an interesting one. Crestron has, for some time, offered a 2-channel H.264 transmitter as an output card for its modular matrix switches. I have used this, and it does what one would expect it to. The part that I've not played with yet is a corresponding H.264 streaming input card. This is useful for system designs utilizing point-to-point transport within a room and the addition of streaming to share content across spaces. It's the kind of solution that can give HDBaseT longer legs.

The Future?
The folks at Valens tell me that the HDBaseT chipset has capabilities not yet being used, including the ability to divide available video bandwidth into separate video channels. This may or may not be useful; I still see complicated systems as more likely to be handled over IP in the future. 

Why no product reviews? On Shootouts and Demos, with an apology to Extron

About what do AV designers talk? Design certainly, in all of its forms. Past projects and wish lists. Perhaps most of all, we talk about technology. For all of our talk on these things, there are relatively few actual product reviews or comparisons. I'll talk about products here, but stop short of a formal endorsement or non-endorsement. Why is this, and what are the perils of doing so? I can illustrate with two examples and an apology.

First, Infocomm 2013. AV_Phenom Mark Coxon saw the dizzying array of HDMI over structured cable extension systems and decided that an old-fashioned "Shoot out" was in order - he'd take a selection and compare for the benefit of the rest of it in the industry. Right away he ran into problems.

1. Acquiring Appropriate Gear
Manufacturers pretty much universally outwardly agreed that this was a great idea. When it came time to actually get sample products, roadblocks appeared. Their trade-show demos were strapped down to permanent displays. They were missing power supplies. They didn't know if they had the latest firmware updates. Some of these might have been legitimate issues. Some might have been a lack of comfort with the risk of taking part in a showdown under conditions they couldn't control. For whatever reason, it's something manufacturers aren't quite comfortable with. 

 

2. Creating a Fair Test
If you read the original post from last year,  you'll see that at the first try none of the extenders worked. At all. Blank screens all around. Removing the extension system and running sources directly to the display, of course, resulted in a perfectly clear picture. Every element of the test had been proven good except the extension system. Which means that the extenders were bad. Right?

Not right. Replacing an active HDMI cable with a .99cent special made everything work. So the problem is the active HDMI cable. Right?

Not right. Months later I saw the same problem - an active cable not working on the back end of an extender. Replacing it with a seemingly identical cable made the problem go away. What the issue appears to have been is a defective cable. Not quite so defective as to give no picture, but marginal enough to fail with some equipment.

Notes on Digital Video

Side note on digital video: as I'm sure you're aware, a digital signal is just a string of ones and zeros. One way to measure the integrity of such  signal would be with an oscilloscope. Ideally, ones should be very high, zeroes very low, with a clear sharp transition between. This is called an "eye pattern". As the signal attenuates and picks up noise the "eye" will flatten and become less sharply defined. Different receivers have different "eye masks" - their tolerance for imperfect signals. The problem with this kind of test is that, absent some rather costly and complex test equipment, it is impossible to determine where the signal is degrading, how, and to what extent. We're left with the binary "it works/it doesn't work". Which leads to the final issue:

3. They all work
Coxon's result was something I could have told him before he started: all of the extenders were able to pass video.  After all, for a manufacturer to sell a product which simple doesn't do what it is advertised as doing would be rather shocking and result in a short life for that manufacturer. Yes, there are secondary tests he could have performed but didn't. Unplug and reconnect the video source to measure sync time. Unplug and reconnect the power to compare startup time. The larger point is that these kinds of devices have become somewhat commoditized; not only do many have the same function, but they also have similar form-factor and, under the hood, use the same chipsets. It's ultimately a comparison of apples to very slightly different apples.

Are there manufacturers with product lines and ecosystems better suited for one application or another? Yes. Are there some which offer better reliability and better customer service? Also yes. I'm not quite ready to say that digital switching and transport is a pure commodity in which any device is equivalent to any other. What I AM saying is that they're close enough that, absent a great deal of time and equipment, it's quite challenging to make meaningful performance comparisons. 

Which brings me back to the beginning, in which I owe somebody an apology.

Some demo gear. I love demo gear!

A few months ago in my visit to Extron post I commented that their XTP switcher changed sources slowly, especially when switching between unprotected and HDCP protected content. This is true; it was unacceptably slow and much more so than other, similar products. So, when one of my colleagues (SMW senior consultant Joe Gaffney) received some Extron demo gear and saw that it switched very slowly I found myself unsurprised.  Fortunately, this was a test in the comfort of our office and Mr. Gaffney is quite diligent about getting things right. After watching the indicator lights on the front of the unit and making several calls to Extron, he determined that there's a setting to drop the HDCP handshake when non-HDCP sources are selected. If this setting is turned off, it has to initiate a new three-way handshake every time a protected source is selected. Hence the long wait time. Turning it off made the unit behave much more reasonably.

Is this what happened with the XTP demo at Extron's demo facility? Without an actual XTP matrix I can't say for certain, but I must admit that it's a possibility. While a manufacturer always should be sure their demo is configured to show the product in its best light, we need to remember not to take first impressions at face value. 

The moral of the story? Sometimes we all get things wrong. Evaluating products is hard. It's OK to make judgments, but make them carefully and be open to the possibility of revisiting them.

Those morals are a bit more universal than the world of AV, aren't they? Perhaps therein lies another lesson.

HDBaseT Interoperability Follies

Welcome back to any AV followers who faded away last month while I was posting all fiction all the time. The stories and poems won't entirely go away but we'll start moving into a little better balance between pixels and ink for the nonce. Today I'd like to share a moment to discuss everyone's  favorite transport mechanism, HDBaseT.

For those not in the know, the HDBaseT alliance have defined HDBaseT as a technology for transport of video, audio, power, ethernet, and control over standard category cable. As a point-to-point (as opposed to routable) signals, HDBaseT cannot be routed with standard network switches. With offerings branded by major techm manufacturers (ie, Crestron's "Digital Media" and AMX "Enova" it has become a defacto standard for commercial systems.

Or has it?

The idea of a "standard" is that it should be manufacturer-agnostic. The HDMI output on a Sony Blu-ray player, for example, will work on the input of a Sharp LCD panel as well as it would on a Sony. Is that the case with HDBaseT? Is it, in other words, really a "standard"? The HDBaseT website does boast, in a large banner, that it is "The standard of the future", but the remainder of their text is much more cautious, referring to HDBaseT "technology" or "specifications". Can one grab an HDBaseT transmitter from one manufacturer and receiver from another and expect them  to work together? In an ideal world, the answer would be yes. Those of us who have wrestled with HDCP, EDID, or other HDMI-inspired headaches knows one thing for sure: this is not an ideal world.

For the sake of my own curiosity I tried a little experiment. I had access to transmitters from three major manufacturers: Crestron Digital Media, AMX DXLink, and Extron XTP. The latter is not, to the best of my knowledge, HDBaseT certified, so I'd not expect interoperability from it. The others are, so I would. Is that what happened? Not quite.

The AMX receiver gave me a "green screen of doom" when I tried to connect the Crestron or Extron transmitter to it. This is apparently an HDCP handshake error (as opposed to HDCP noncompliance, which would give a red screen of doom. Doom is the consistent part). This possibly has to do with how AMX handles HDCP authentication, which treats the receiver as a source rather than a repeater. This is nifty in that it bypasses the key limit in some sources (in other words you can run a single Blu-ray player to as many displays as you have outputs for, regardless of its key limit), but might make the receiver more picky in what it looks for from the source side.

This was a fairly disappointing result in that it left the non-HDBaseT certified Extron XTP as my only other receiver. IT might not be "certified", but it does use the same technology as HDBaseT transport solutions. Somewhat to my surprise the Crestron and AMX transmitters both sent HDCP protected content to the Extron XTP receiver. So much for certification.

What does this mean in practical terms? Not all that much. What it highlights is just how similar these devices are. Even in terms of form-factor you get a great deal of similarity between product lines; everyone has a standalone receiver about an inch or so deep to fit behind a flatpanel (or in a wall box), a similarly shaped standalone transmitter, a two-gang wall-mount transmitter,  and modular matrix frames sized from 8x8 up to 32x32 or larger. There's no real practical reason to step out of a single manufacturer's ecosystem other than to prove that you can. Now that we've done so, even that is gone.

A selection of transmitters and receivers

So how does one choose? We're the same place we were back when we did "Switcher-Wars" last year. Do you need Crestron's full audio and USB breakaway? AMX's smaller form-factor and better energy efficiency? Does an end-user with limited programming expertise want to be able to make equipment substitutions and other programming changes through Extron's Global Configurator or AMX's Rapid Project Maker? Is there an existing implementation of a remote-control and asset management system (Crestron Fusion, AMX RMS, Extron Global Viewer) into which you'd like your new system to tie? We've reached a point at which not only are the differences more subtle, but many of them won't even appear on a spec sheet.

The real take away here - for those who didn't realize it already - is confirmation  that the technology is very much the same. In fact, it's the same to the point that if one files off the serial numbers one would have a hard time even telling one apart from another. What this really means is that the best manufacturers aren't just selling the technology; they're selling a solution, including an ecosystem to fit around it and the thought they put in to some of the details that one might miss on a spec sheet.

The HDBaseT adventure continues

HDBaseT has been around for a few years now and, to the likely disappointment of the initial HDBaseT consortium, appears to have settled into a role as a midpoint; it still isn't a format likely to be seen as the input or output to a device, but is widely used in distribution and switching. I had the chance to ponder and discuss this with some of my colleagues in the commercial AV industry at AMX's showroom during the two-day certification class for their HDBaseT system: Enova. It's striking to see how far this technology has come, and how different manufacturers can take the same underlying chip set to create very different-feeling solutions.
The idea for HDBaseT is a grand one; to have one and only one cable connected to each display.  That cable, a standard network cable with standard RJ45 connectors, would carry uncompressed high-definition video, audio, control, and even power. Yes, they expect to power your display via the same Cat5 jumper that carries everything else. One cable in this case literally means one cable. In real world applications, that isn't what's happened. For one thing, native HDBaseT inputs and outputs. Even if manufacturers want to use this kind of system, even mid-size displays in the 50 to 65 inch range outdraw HDBaseT's upper power limit by an approximate factor of 10. So, like a phone company  running fiber to the curb before converting to old-fashioned copper, we're left with easily-pulled Cat5e cables to a receiver-box giving way to good old HDMI cables for the proverbial last mile. We're not quite where we someday can be, but it's an improvement. Crestron's Digital Media is an HDBaseT solution, as is Extron's XTP and AMX's DXLink, the heart of its Enova solutions.
How do solutions compare? Not only does Enova have a different feel from Crestron, but AMX's DVX (a family of all-in-one presentation switchers) behaves differently from their DGX (more conventional digital matrix switchers). One thing I hadn't known - because I'm not in the habit of removing the case on expensive pieces of electronics unless I have to - is that while it looks like one seemless piece of hardware, the DVX is, in fact, card-based. My notes include a glimpse at its innards, highlighting the HDMI input cart swappable with a DXLink card for another model. It's a clever design philosophy which allows AMX to inexpensively and reliably use one platform to produce a suite of units with slightly different features. 
So how does Enova compare to Digital Media? At a glance they're similar; each has a presentation-switcher with built-in control processor, audio mixing, and an amplifier. Each line boasts a modular matrix switch capable of handling different video formats. Each has a series of Cat5 transmitters and receivers. Each handles HDCP key authentication, effectively eliminating any risk of running out of keys in large systems. Looking a bit closer, one sees differences.
The first distinction - of  which AMX is justifiably proud - is that each output on an Enova system has a built-in "smart-scaler" which reads the  EDID from a display and scales the image to fit. This means that even in a large system with many different displays each device will get an image at its native resolution. Their contention is that other practices, like choosing "best common", not only leave adjusting resolution to a device's onboard scaler, but fails to take advantage of the higher resolution in the largest display in a system. It adds a certain measure of cost, but AMX feels that they give value for it.
The second distinction is that each AMX matrix switch has a control processor built into it. This makes for a neater and more compact installation, but isn't a tremendous improvement over the inclusion of a standalone processor, and burying it in the switch gives you the new problem of having no local control ports. Unless everything in your system has IP control, you'll have to build out the system with varying add-ons. In all fairness, AMX has a nice suite of IP-based control port expansion modules, and seems to have a philosophy of preferentially using IP-based controls.

What about the distinction within the Enova line? At Enova training in AMX's New York showroom we got a demonstration of both the DVX presentation switcher and DGX matrix switcher.  The performance in switching speed is markedly different, with the DVX switching, I would estimate, twice as fast as its cousin. The difference was explained as a result of different engineering teams working on the two devices, and upcoming firmware updates to let the DGX catch up were hinted at. (it was further explained that the slower switch time - one and a half to two seconds - was a result of the switcher dropping sync when it changed sources. It is very interesting how the same hardware can have different performance given different firmware.
What about venerable switching manufacturer Extron? I don't have much to say about their XTP line; certainly until they start shipping the Cat5 input and output cards for their switcher, they can't be said to have a real solution available. Even given that, they're still behind the curve in not having a DMPS300/DVX style presentation switcher available. They have added power injectors to their XTP line, but it is, at the very least, unclear that these would work with other HDBaseT solutions.
Long story short? It's an exciting time in the commercial AV industry as we finally seem to have the hardware, software, and expertise to start making digital video work closer to the way it should; many of these solutions are, if anything, easier to use and more flexible than old analog solutions.

A side note: my adventure at AVI-SPL has come to an end, so I am open to new opportunities in the AV field. Anyone reading this is welcome to comment or drop me a line with any openings in the New York metropolitan area.

Stay tuned for a book review later this week.