You also need synchronization to mix sources (common in any production) without incurring the latency and resampling of asynchronous sample rate conversion.

There’s also AES70, or OCA (https://news.ycombinator.com/item?id=46934318). More popular in audio than video, something of a competitor to NMOS (although there are parts of NMOS that were very much inspired by OCA). There are open source C++, Python, JavaScript and Swift implementations as well as some commercial ones.

IOKit was designed to support CoreAudio from the start, cc gvdl.

That is a beautiful piece of industrial design.

XMOS is still keeping the Inmos dream alive, more or less!

This is also my recollection.

Small nitpick: malloc is not a system call.

Good catch! We will fix this in the next version and change it to brk/sbrk or mmap

That jumped out at me too. It stood out amid the (excellent) performance model validation.

And Mach 3 vs 2.5. And a 4.4BSD (well, *BSD) user land, although in fairness the original, never released NEXTSTEP 4.0 also had this.

Another approach is swift-java, which uses Swift macros and also supports Panama.

https://github.com/swiftlang/swift-java

Panama will probably never make it to Android, given Google's behaviour on updating Java support.

That’s sad. One of the first pieces of (serious) software I wrote was licensed by HP for bundling with it. Didn’t use HP-UX a lot but it’s a pity we’re asymptoting towards a Unix monoculture.