Related to this topic, I would recommend reading through this...!topic/theatre-sound-list/WbysqMHs6iw

AVB isn't dead no, but it certainly isn't close to dominant at this point, at least on my side of the pond.  It may be a different situation on the other side, no idea.  That being said, it has a very uphill battle to displace Dante at this point on my side of the pond and get decent usage professionally.

Then again if AES67 interoperability comes into play, then is may be a moot point as ideally you would be able to communicate between the two protocols.


On Mon, Jun 15, 2015 at 7:05 PM, Len Ovens <> wrote:

Looking at the MOTU AVB endpoints, I see MIDI ports on them. None of the AVB docs I have read (yet) show MIDI transport. Is this then just RTP-MIDI on the same network? It almost seems that the midi is visible to the USB part only.

Motu recommends connecting one of the AVB boxes to the computer via USB or Thunderbolt and streaming all avb channels through that connection. So this would mean that the BOX closest to the computer is the audio interface. With Thunderbolt the maximum channel count is 128 with any mix of i/o from that (example 64/64 i/o).

Connection to the computer via AVB:

shows some limitations:
 - SR can be 48k and multiples but not 44.1k and multiples
 - The Mac will insist on being the master clock
 - The Mac locks each enabled AVB device for exclusive access.
        (The mac can talk to more than one AVB device but they can't
        talk to each over or be connected to each other while the Mac
        has control)
 - Maximum channels is still 128 at least on a late 2013 Mac Pro. earlier
        models should not expect more than 32 total channels (mix of i/o)
 - Motu AVB devices set all streams to 8 channels, no 2 ch streams allowed.
 - Because the AVB network driver on Mac looks like a sound card, Audio SW
        needs to be stopped before changing channel counts. (adding or
        removing IF boxes)

I think that a Linux driver has the potential to do better in at least some cases. I personally would be quite happy with 48k SR only, but I am sure someone will make it better. Linux does not have to be the Master Clock unless it must sync to an internal card that only has some kind of sync out but can't lock to anything (like some of the on board AIs that have a s/pdif out). In the Linux case, the AVB AI may well be the only used AI and the internal AI can't be synced to anyway. With Jack, channels can come and go with no ill effect except a connection vanishes. Channels can be added and removed even within a jack client. This _should_ (logically) be possible in a Jack backend, but maybe not wise. A sync only backend may be better that takes it's media clock from the AVB clock as this would add stability in case of an avb box being disconnected. I do not know if jack backends can deal with 0 or more channels with their number changing, but a client dying because it's remote AI vanished would not crash jack. The problem with using clients for the AI is that auto-connecting APPs look for system/playback_1 and _2. Even more jack aware apps like Ardour would have you looking in "other" for more inputs.

Anyway, getting AVB working with Linux is first (even two channels).

Len Ovens

Linux-audio-dev mailing list