Re: [LAD] AVB not so dead after all

Related to this topic, I would recommend reading through this...

https://groups.google.com/forum/#!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.

        Seablade

On Mon, Jun 15, 2015 at 7:05 PM, Len Ovens <len@email-addr-hidden> 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:
>
> http://www.motu.com/avb/using-your-motu-avb-device-as-a-mac-audio-interface-over-avb-ethernet/
>
> 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
> www.ovenwerks.net
>
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev@email-addr-hidden
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
>

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Wed Jul 22 00:15:02 2015