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@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
