The Truth Is: SDVoE-based Products Are Interoperable. No Testing Needed.

Like SDVoE, other de facto standards in AV have made claims about interoperability. But historically, these other alliances and standards have not always made interoperability easy. All the certification tests in the world don’t amount to much when you’re on a job site, and two manufacturers are pointing at each other, saying “it’s his fault!”

SDVoE is different. SDVoE’s interoperability is really baked right in, so it’s much easier to guarantee even without a certification lab. To understand all aspects of SDVoE interoperability, and why it is so straightforward, it helps to break SDVoE down into three layers of communication:

• Endpoint to endpoint – information (including audio and video) exchanged between endpoints
• Endpoint to API – instructions passed between the central API and the endpoints
• API to control software – the user’s wishes and feedback translated into system-level instructions

Endpoint to Endpoint Communication Uses Global Standards

Our endpoints communicate with one another through IEEE-standard 10Gb Ethernet, and a few higher layer standard protocols (such as IGMP multicast). These are global standards that can easily be tested against, without reference to SDVoE. Meaning, if you want to test your Ethernet subsystem, you buy an Ethernet tester, and check it. There is no need to compare to another SDVoE device (because that device will also have been tested for Ethernet compatibility). This happens at the physical layer and the protocol layer.

Comparing this to HDBaseT, they invented their own physical layer specification, so they are required to provide standardized testing around that interface – because no other test exists!

Endpoint to API Provides Interoperability

This is the simplest area for interoperability because this is all controlled by SDVoE. All SDVoE devices are powered by a family of similar chips, which all work with the SDVoE API. It is this software API layer that actually guarantees our interoperability because the endpoint manufacturer ultimately is not in control of the communication between the chipsets and the API. That communication never changes, and there is no way for a manufacturer to modify it.

Contrast this to HDBaseT (which has no software standard), they gave manufacturers too much flexibility here.  For example, early HDBaseT chips contained a set of 8 general-purpose input/output (“GPIO”) pins. Pin 1 on the TX will wiggle when pin 1 on the RX wiggles. And so on. Want to implement IR? Simply choose a GPIO pin and send your IR comms down the wire. But what if two manufacturers chose different pins? Well, they would not have compatible products! There are no such ambiguities in SDVoE hardware or software.

API to Control Software Connects All SDVoE-based Devices

Here interoperability simply means that all devices use the same API. That way, any software built to control SDVoE devices speaks to the SDVoE API, and the API will speak to whatever hardware devices are found.  Interoperability comes from the standardized software interface. SDVoE API is now freely available to all programmers or interested parties via the SDVoE Academy.

Notably, it is possible to build software that will only speak to certain brands of hardware – this is the software manufacturer’s choice. However, it is NOT possible to build hardware that will only speak to certain software. This is how we ensure the ecosystem stays open to all who want to develop on the SDVoE software platform.

For all of these reasons, it is simply not a technical requirement to do interoperability testing for SDVoE devices.  We didn’t make up any new ways to communicate, and we control the most critical interfaces between endpoints and users. SDVoE interoperability is real – and it’s that easy!

Hear more about SDVoE interoperability on a recent episode of Rants & rAVes with Gary Kayye.