Successor to HDX hardware?

[LukeHoward]

Originally Posted by Bob Olhsson

These would be closed networks within facilities. AVB would enable great flexibility in the number of seats used in a given room or studio. The routers and interfaces would pay for themselves in reduced labor costs.

The other issue, maybe not for an all-Avid solution per se, but AVB is a royal pain in the rear when it comes to heterogeneous interoperability. I spent a good few hours this afternoon getting my Mac, S3 and MOTU Ultralite AVB talking via AVB. I did get it working eventually, but it involved various hidden OS X utilities and hand-editing some XML files on the S3 itself. Not for the faint of heart!

[Bob Olhsson]

That stuff all predates the final AVB spec. There's every reason to expect software and firmware updates that will solve those problems.

[YYR123]

Originally Posted by Bob Olhsson

There's every reason to expect software and firmware updates that will solve those problems.

What the saying Bob, Expectation in one hand.....

[LukeHoward]

Originally Posted by Bob Olhsson

That stuff all predates the final AVB spec. There's every reason to expect software and firmware updates that will solve those problems.

Hey Bob, just want to say I'm not being deliberately argumentative and I'm enjoying this discussion, and am both interested and invested in AVB and Dante. And I definitely hope there will be software and firmware updates that solve these problems!

So – OS X, the S3 and MOTU all support AVB and AVDECC which is the discovery and configuration protocol. My understanding, which of course could be wrong, is that they do all support the final versions of the specification. The interoperability issues come from a couple of things – first, the classic problem of standards vs proprietary where unless there's a lot of interop testing by all vendors, there will always be some case where an apparently standards-compliant device fails to interoperate (just as there will always be bugs). Particularly with something as complicated as AVB.

Secondly, one of the specific issues with AVB results from the trade off between traffic and patching flexibility, in terms of how many channels are bundled into an AVB stream. Less channels per stream means more flexibility (as listeners and talkers are connected at the stream level) but my understanding is that it creates more metadata traffic on the network, so all other things being equal it's better to increase the stream channel width if possible. Streams of different channel widths cannot be patched, and the S3 in particular has an unusual input stream width of 6 channels (because of its individually addressable headphone output). Anyway, the MOTU software is very flexible in adapting to this, but it's nonetheless quite fiddly to configure on the OS X and S3 side, and it's confusing to an end-user who expects to be able to patch channel-by-channel. (Also, so far I haven't had any success in making AVDECC connections persist after a reboot.) All of these things are interoperability pain points.

An S3-specific issue is that it by default insists on being the AVB clock master, which isn't very friendly in an environment with a house clock. This is fixable though, but requires a bit of XML-fu. (It's quite nice that Avid left open the FTP and telnet ports on the S3, thanks Avid!)

Anyway, let's contrast this with Dante, a completely proprietary solution (OK, it does use Bonjour and RTP, but the consolidation of the protocols is proprietary). Disadvantage, of course, it's proprietary – there's only one implementation, and it's from Audinate (regardless of whether you have a soft IP core license or are buying chips from them). This disadvantage is also its advantage – it just works. There's a lot of thought that's gone into things that makes things like patching and following sample rate changes, with some exceptions, a lot easier than AVB. It's also a lot clearer, at least to me, what the latency trade offs are (I'm not sure if AVB provides unified presentation times in the same way)

Which brings us to AES67 which is either the best or worst of both worlds. It's an open standard, ostensibly interoperable and can even use components of AVB for synchronization (of course, that creates an interoperability problem between those that do and don't support this). But it also has the classic problem that happens when vendors get together to make a standard and want to throw in all their favorite features so their existing implementations can be "standards compliant" with a minimum of work or customer impact. In the case of AES67, this manifests as discovery being left out of the spec (several are supported such as Bonjour, SAP, etc). So you end up with putatively standards compliant devices not being able to interoperate, or only at a basic level (e.g. patching by IP address). Dante's AES67 support for example presently only supports multicast discovery, which have higher latency than unicast streams, which make it less useful for music production. And obviously Audinate are not incentivized to make their AES67 implementation too good, at least not until they've moved sufficiently up the stack.

Anyway, that turned into a massive rant. I worked for years in network protocols in the computer industry here and what we are seeing here is a textbook example of open vs proprietary standards playing out in the market. Check back in five years and let's see!

[Bob Olhsson]

I can't imagine they support the final SMPTE AVB format yet. There has been a general format the SMPTE is a subset of but that is way too general for broadcast and post facilities. Dante and AES67 don't support video. SMPTE AVB does. Yes, the routers will be very expensive. Broadcast is Avid's main market.

[LukeHoward]

Originally Posted by Bob Olhsson

I can't imagine they support the final SMPTE AVB format yet. There has been a general format the SMPTE is a subset of but that is way too general for broadcast and post facilities.

AFAIK AVB is an IEEE standard, the SMPTE standard you might be thinking over is SMPTE 2022 (which is a Layer 3 rather than 2 protocol and is not interoperable with AVB). "SMPTE AVB" I couldn't find any references to.

This presentation compares the two. It does actually point out a bunch of advantages of AVTP (video over AVB) over SMPTE, but it's also a few years old. If you look at Axon, the vendor mentioned in the presentation, it seems they've now moved away from AVB to SMPTE 2022 and now TR03/04, which I just read about then. (Learning a lot here!) Funnily enough that seems to be (roughly) uncompressed video over RTP, with AES67 for audio. So it appears that the video industry, as well as audio, is converging on a Layer 3 IP-based solution (although I should add I really know nothing about the video world).

I think if AVB has any future it is within vendor-specific networks where the end-user has limited control over configuration and interoperability with other products (so it might have a future with Avid, although the fact the MTRX does not support it yet doesn't seem too promising). Beyond that, my gut feeling is that the performance advantages of Layer 2 over 3 alluded to in the paper above will vanish with Moore's law and IP going direct into the silicon.

[YYR123]

You guys are so far over my head it's crazy

But I would not put it past any company to make it blatantly more difficult to interact with another....

Luke don't you work for waves?

[LukeHoward]

Originally Posted by YYR123

You guys are so far over my head it's crazy

But I would not put it past any company to make it blatantly more difficult to interact with another....

Luke don't you work for waves?

Nope, just a muso interested in network audio

[guitardom]

Originally Posted by YYR123

You guys are so far over my head it's crazy

Layer 2 is Data link layer and forwards data based off cam/mac address tables. Think switches. Layer 2 cant cross networks though without the help of a router (layer 3). Data is referred to as frames.

Layer 3 is IP and routes based off of ip addresses and routing tables. Typically layer 3 works via routers. Necessary for jumping network to network. Data at this layer is called Packets.

So now that you are caught up.....

[IrelandM]

Originally Posted by LukeHoward

AFAIK AVB is an IEEE standard, the SMPTE standard you might be thinking over is SMPTE 2022 (which is a Layer 3 rather than 2 protocol and is not interoperable with AVB). "SMPTE AVB" I couldn't find any references to.

This presentation compares the two. It does actually point out a bunch of advantages of AVTP (video over AVB) over SMPTE, but it's also a few years old. If you look at Axon, the vendor mentioned in the presentation, it seems they've now moved away from AVB to SMPTE 2022 and now TR03/04, which I just read about then. (Learning a lot here!) Funnily enough that seems to be (roughly) uncompressed video over RTP, with AES67 for audio. So it appears that the video industry, as well as audio, is converging on a Layer 3 IP-based solution (although I should add I really know nothing about the video world).

I think if AVB has any future it is within vendor-specific networks where the end-user has limited control over configuration and interoperability with other products (so it might have a future with Avid, although the fact the MTRX does not support it yet doesn't seem too promising). Beyond that, my gut feeling is that the performance advantages of Layer 2 over 3 alluded to in the paper above will vanish with Moore's law and IP going direct into the silicon.

''Has anyone found a suitable AVB switch that could be incorporated with the Avid S3 also AES67 Genelec 8340AIP monitors over Bonjour. I am currently looking at Cisco SG 300 series ethernet switches but they don't support AVB bridging as standard to connect these monitors into my system.


Regards