On 05/13/2017 03:38 PM, Moshe Werner wrote:
On Fri, May 12, 2017 at 10:03 PM, Fernando Lopez-Lezcano
<nando@xxxxxxxxxxxxxxxxxx <mailto:nando@xxxxxxxxxxxxxxxxxx>> wrote:
I have never had the time to try to make the whole AVB thing work.
Trying OpenAVB a while back I managed to get the Motu to sync with
the Linux box through AVB, but never went as far as getting
discovery and streaming working (no time). You do need an ethernet
interface that has AVB support (Intel i210, for example).
On the other hand I'm working on a big system that uses (for now)
USB at 44.1/48 with a 64 channel count to interface with computers,
and then the rest of the I/O going through AVB streams to and from
additional boxes (I use either an A16 or 24ai as entry points
because they support 8 i/o AVB streams). Pretty neat with all the
routing matrices shuttling samples back and forth. You have to pay
attention to how many AVB streams each card can handle (they are not
necessarily symmetric).
That's great news that AVB is working on linux too!
Nope, sorry, not yet. Probably doable but I do not know. As I said, I
managed to get linux to see a Motu device - the clock, that is - and
sync to it (or the other way around, I don't remember). I did not do
discovery and streaming... maybe the existing free software could do
that if programmed correctly, I don't know (only 24 hours in each day).
Could you elaborate on the connection scheme of your setup? Are the
different Motu boxes connected via the AVB switches?
The Motu boxes are connected through a Motu AVB switch and AVB streams.
As I do not have OpenAVB working (yet), the connections to and from
Linux are done through USB2. In all cases the main control machine is
connected to a 16A and auxiliary computers through the 24ai (because of
AVB stream count). Everything else connects through the internal routing
matrix and AVB streams, very flexible. All devices slave to one over
AVB. Input and output not to the computer are handled through analog
and/or ADAT I/O.
As the channel count is high 64 channels is a must - I had discarded the
Motu devices because they were limited to 24 channels I/O but then they
issued a firmware update that enabled a configurable tradeof between max
sampling rate and number of channels over USB2. I was looking at a
solution using MADI before, but this was more flexible and cheaper
(limited budgets), but of course very vendor specific. I have
(currently) three use cases for this setup, one is using this as the
core I/O for the GRAIL, our "portable" 3D surround speaker concert
system - tested in two concerts so far. Another is for the control
system of an ongoing upgrade for our concert hall (the Stage) from 16.8
to 48.8 (this is the one that forced me to find a solution). I'm also
testing this to replace the existing audio I/O for our Listening Room
(just testing this last Friday, looks like may be able to run this at
64x2 instead of the current 128x2 with RME and MADI / RayDAT cards).
So far so good... hopefully I will not run into any pitfalls :-)
I had problems with the newer generation of Motu cards that have a
USB3 interface, so beware. Those work fine with USB2 connections but
then the I/O is restricted to 24 channels input and output (in the
older generation and with the latest firmware you can select whether
you have more channels and less sampling rate options or visceversa
- that is not available in these new cards). If you connect to an
USB3 port the USB subsystem in the kernel hangs or gets really
confused. Reboot time :-(
That's not so great news:(
Why get it right just to do it all wrong again...?
I currently do not believe this is a problem with their interface, looks
more likely to be a kernel problem in Linux (but I could be wrong).
-- Fernando
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user
