Understanding the SDVoE API
I came across Mark Coxon‘s article “Is the Future of AVoIP Wide Open?“. As usual, Mark has brought up some thought-provoking points. Since his points are right at the heart of my world – AV-over-IP – I thought I’d take a crack at some commentary and clear up what I see as an important mischaracterization of SDVoE Alliance.
Mark shares a few statements that are inarguably correct regarding single-manufacturer solutions. We agree that proprietary walled gardens of AV-over-IP will not drive the next decade of pro AV. The IT customer will ultimately not buy products that force them into a single provider for their future upgrades, expansions, and maintenance tasks.
I was interested to hear about PlexusAV, too. Like Mark, I’d not heard of the company before. From a quick glance at their website, it certainly seems like their head is in the right place – a belief that interoperability is key for pro AV success.
The waters get a little muddy when Mark refers to the “proven SMPTE 2110 standard.” It’s true that standard has been utilized in broadcast for a handful of years. However, IPMX is not SMPTE 2110. Rather, IPMX is an incomplete proposed standard with little to no mileage in the real world. IPMX is unproven. I am only aware of one manufacturer shipping IPMX products and it is highly unlikely that the early IPMX products will be able to deliver on all of the promises made in the hype around the standard itself. It’s just not technically feasible today. Undoubtedly, IPMX is a very interesting initiative and one that the SDVoE Alliance keeps our eyes on closely.
If “proven standard” is the benchmark, then the SDVoE Alliance is a clear leader today. The SDVoE Alliance’s members provide hundreds of interoperable products available today – and a long-standing history dating to 2017 and earlier. RH Consulting’s “Networked Audio Products 2022” gathers comprehensive data to support this.
Most importantly, I want to address a key point in Mark’s article. He states, “SDVoE products should be cross-compatible between brands. However, some brand’s APIs limit things like endpoint discovery to their own brand, making cross pollinating harder than it should be.”
This needs to be further clarified. First some important background:
Nearly all manufacturers that build SDVoE hardware, build a corresponding software application. Many of those applications focus (not necessarily exclusively) on managing their own hardware for obvious commercial reasons. There are also companies in our ecosystem that focus primarily on software and build that software to be compatible with as many hardware vendors as possible. Examples of this include VuWall and iMAGsystems.
I believe Mark’s use of “API” (an abbreviation for application programming interface) in this case is a misnomer, and he actually is referring to applications. That said, some SDVoE manufacturers include their own API between the SDVoE API and their control application. Most do not. Anyone who does build their own API is probably doing so to enable management of advanced capabilities unique to their hardware – capabilities not included in other vendors’ hardware, and not managed by the SDVoE API. So, of course those APIs would be built exclusively for the hardware they are designed to control. Still, using such an API would never preclude also using the SDVoE API for functions common to all SDVoE devices.
I think Mark was probably referring to the possibility of software applications built by hardware manufacturers who avoid controlling devices that are not their own. This IS possible to do. Just like Mark, I DON’T LIKE IT! Now, you might be thinking about why the president of SDVoE Alliance doesn’t do something about it. Because that’s not my job. It’s yours.
When the SDVoE API discovers hardware devices on a network, each one of those devices reports a unique manufacturer ID code. The code lets the software determine who manufactured the hardware. Sounds reasonable, right? It is. It’s essential to know what kind of hardware is out there, so the software can treat it correctly.
Now, if I’m a software developer, and I don’t want people using my software with someone else’s hardware, I can simply ignore any hardware that doesn’t report my hardware ID. Is this bad behavior? Maybe. Is it allowed? Yes.
Why is this important? An example: vendor A writes awesome software but wants to give it away for free and charge a bit more for their hardware, rather than deal with selling and licensing software. Without filtering by hardware ID, anyone could take vendor A’s software for free and use it with vendor B’s cheaper hardware. This limits the business models available for SDVoE vendors, ultimately stifling creativity and development.
Now, here’s the million dollar question. Why is it your job to manage how these companies write their software? It is because you are the customers! I know that you have been longing for a truly interoperable ecosystem for many years. We built SDVoE to provide you with that! But now that we’ve built the tools, it’s your job to demand that they be used correctly. You don’t like vendor A blocking vendor B’s hardware? Tell them! But also, expect them to start charging you for their great software.
This is the only way we move pro AV to the next step, a truly interoperable hardware and software ecosystem through SDVoE.
Over the last two years, the industry has faced many supply chain disruptions, while SDVoE products have remained reliably available. This has driven record demand for the technology, and as a result we’ve started to finally uncover the interop challenges between software and hardware from different manufacturers. It’s a good thing! Already our members are responding with improved interoperability focus as they hear from you that it’s what you want. If you think IPMX will be a magic bullet, just wait until they have 50 manufacturers with interoperability challenges with software and hardware (an area where SDVoE has full interoperability by design). With enough time, anything can be fixed, but it’s a much longer road than the one SDVoE is traveling.
Today, the SDVoE API is available for anyone to download and develop with. Simply become an SDVoE Certified Developer (for free, and with CTS renewal units), and you get access to build your own fully interoperable software.
And for those of you interested in trying out SDVoE with a native and customizable application built exclusively on the SDVoE API, check out the BlueRiver AV Manager. BlueRiver AV Manager provides manufactures, resellers and users of SDVoE-based equipment a free and easily customizable baseline AV control software that can be repackaged to deliver a wide variety of highly targeted user interface experiences.
If you really want to put your chips on the table, become a certified developer, leverage BlueRiver AV Manager, and start building (and selling!) your own fully interoperable SDVoE killer app. Surely you’ll put anyone who builds a single-hardware-vendor solution out of the software business.