30 Mar
2019
30 Mar
'19
1:56 a.m.
Fernando Lopez-Lezcano discussed the pitfalls of using the MOTU AVB
external audio interfaces with Linux in his paper [1] and also in the
keynote at LAC-19.
Let's start another thread around this card.
Fernando mentioned that different firmwares expose different issues, but
downgrading is possible. Issues are:
1. Channels are not persistent and swap around.
2. Total number of channels has been reduced in newer firmwares.
3. An endless card aquisition loop between Jack and Pulseaudio caused by
the long time the card needs to switch sampling rate.
4. Seemingly erratic behavior, opening the device fails, fails again,
again, then works suddenly.
I have a couple of questions and experiences.
Is there a table of the firmware versions somewhere (linuxaudio wiki?)
which tell me which versions has which features (removed)?
Are all the Class Compliant models having the same quirks as listed
above? For example the
MOTU UltraLite AVB versus the MOTU 624 AVB?
Is it possible to use the Thunderbolt port to connect the card to a
Linux computer?
Why can't I tell ALSA to use only the first 2, 4 whatever channels of
the device? I can only open the device if all channels are connected. Is
this always like that or is that a limitation of MOTU's implementation?
On my laptop with only one USB bus, If I connected the MOTU 624 AVB and
then another high speed usb device, the computer could not connect the
later, because the MOTU reserved all the bandwith for itself. Connecting
the other device and then the MOTU worked.
[1] http://lac.linuxaudio.org/2019/doc/lopez.pdf
Max
30 Mar
30 Mar
5:52 a.m.
On Fri, Mar 29, 2019 at 4:57 PM Max <abonnements(a)revolwear.com> wrote:
Fernando Lopez-Lezcano discussed the pitfalls of using
the MOTU AVB
external audio interfaces with Linux in his paper [1] and also in the
keynote at LAC-19.
Let's start another thread around this card.
Fernando mentioned that different firmwares expose different issues, but
downgrading is possible. Issues are:
1. Channels are not persistent and swap around.
2. Total number of channels has been reduced in newer firmwares.
3. An endless card aquisition loop between Jack and Pulseaudio caused by
the long time the card needs to switch sampling rate.
4. Seemingly erratic behavior, opening the device fails, fails again,
again, then works suddenly.
issue 4 is not resolvable via firmware changes. it seems part of the device
design.
I have a couple of questions and experiences.
Is there a table of the firmware versions somewhere (linuxaudio wiki?)
which tell me which versions has which features (removed)?
fernando mentioned a post on "linux musicians" which describes each one.
Are all the Class Compliant models having the same quirks as listed
above? For example the
MOTU UltraLite AVB versus the MOTU 624 AVB?
Is it possible to use the Thunderbolt port to connect the card to a
Linux computer?
Why can't I tell ALSA to use only the first 2, 4 whatever channels of
the device? I can only open the device if all channels are connected. Is
this always like that or is that a limitation of MOTU's implementation?
ALSA doesn't work that way. You open a device. You tell it how many
channels you want to use.
On my laptop with only one USB bus, If I connected the MOTU 624 AVB and
then another high speed usb device, the computer could not connect the
later, because the MOTU reserved all the bandwith for itself. Connecting
the other device and then the MOTU worked.
this is correct, and likely a sensible design choice. others may disagree.
i actually threw away a webcam because i mistakenly believed that it was no
longer working (because of this issue).
10:28 a.m.
On Fri, Mar 29, 2019 at 08:52:04PM -0700, Paul Davis wrote:
At least in mmap mode (which is what Jack uses), this doesn't seem
to be so. snd_pcm_hw_params_set_channels () returns an error for
any number of channels not equal to the actual available number.
It makes sense, access is exclusive anyway. The only consequence
is that apps should probably write zeros to any output channels
they don't want to use.
If an app needs only 2 channels and fails to use a card offering
more, that's a bug in the app, not in ALSA.
Ciao,
--
FA
Why can't
I tell ALSA to use only the first 2, 4 whatever channels of
the device? I can only open the device if all channels are connected. Is
this always like that or is that a limitation of MOTU's implementation?
ALSA doesn't work that way. You open a device. You tell it how many
channels you want to use.
7:43 p.m.
On 30.03.19 09:28, Fons Adriaensen wrote:
On Fri, Mar 29, 2019 at 08:52:04PM -0700, Paul Davis
wrote:
At least in mmap mode (which is what Jack uses), this doesn't seem
to be so. snd_pcm_hw_params_set_channels () returns an error for
any number of channels not equal to the actual available number.
It makes sense, access is exclusive anyway. The only consequence
is that apps should probably write zeros to any output channels
they don't want to use.
If an app needs only 2 channels and fails to use a card offering
more, that's a bug in the app, not in ALSA.
Makes sense. My thinking was that I could possibly get lower latency and
less overhead if I only acquire two or four channels instead of 24 or 64
from which I leave the majority idle... But I understand its just now
how ALSA was designed.
Why
can't I tell ALSA to use only the first 2, 4 whatever channels of
the device? I can only open the device if all channels are connected. Is
this always like that or is that a limitation of MOTU's implementation?
ALSA doesn't work that way. You open a device. You tell it how many
channels you want to use.
8:23 p.m.
On Sat, Mar 30, 2019 at 10:43 AM Max <abonnements(a)revolwear.com> wrote:
Makes sense. My thinking was that I could possibly get lower latency and
less overhead if I only acquire two or four channels instead of 24 or 64
from which I leave the majority idle... But I understand its just now
how ALSA was designed.
Channel count is never going to affect latency unless you are do much
processing that dealing with N times more channels takes you over the edge
of what your CPU can do in a given time interval. While that's not
impossible, it's also not likely.
7:37 p.m.
On 30.03.19 04:52, Paul Davis wrote:
On Fri, Mar 29, 2019 at 4:57 PM Max
<abonnements(a)revolwear.com
<mailto:abonnements@revolwear.com>> wrote:
Fernando Lopez-Lezcano discussed the pitfalls of using the MOTU AVB
external audio interfaces with Linux in his paper [1] and also in the
keynote at LAC-19.
Let's start another thread around this card.
Fernando mentioned that different firmwares expose different issues,
but
downgrading is possible. Issues are:
1. Channels are not persistent and swap around.
2. Total number of channels has been reduced in newer firmwares.
3. An endless card acquisition loop between Jack and Pulseaudio
caused by
the long time the card needs to switch sampling rate.
4. Seemingly erratic behavior, opening the device fails, fails again,
again, then works suddenly.
issue 4 is not resolvable via firmware changes. it seems part of the
device design.
I think 3 and 4 may actually be the same issue.
I have a couple of questions and experiences.
Is there a table of the firmware versions somewhere (linuxaudio wiki?)
which tell me which versions has which features (removed)?
fernando mentioned a post on "linux musicians" which describes each one.
for reference, I guess the thread is this one:
https://www.linuxmusicians.com/viewtopic.php?f=6&t=18046
It's a rather long thread with some interesting tidbits here and there.
Someone even wrote a test program, but one has to be signed in to see
attachments on this forum.
Three takeaways from this thread:
1. AVB might be supported by the kernel at some point, which would allow
to use the AVB interfaces without the USB connection.
See: https://github.com/L-Acoustics/avdecc for a multiplatform
implementation.
2. Firmware 1.2.8. is the last one which provides 64 channels via USB
Class Compliant, downgrade to this version if more then 24 channels are
needed.
The old firmwares are downloadable here:
http://motu.com/techsupport/technotes/firmwarechangelog/
3. There is no way to change the number of channels through ALSA or via
the configuration panel of the web-interface. It's static.
Are all the Class Compliant models having the same
quirks as listed
above? For example the
MOTU UltraLite AVB versus the MOTU 624 AVB?
Is it possible to use the Thunderbolt port to connect the card to a
Linux computer?
Why can't I tell ALSA to use only the first 2, 4 whatever channels of
the device? I can only open the device if all channels are
connected. Is
this always like that or is that a limitation of MOTU's implementation?
ALSA doesn't work that way. You open a device. You tell it how many
channels you want to use.
That's what I thought, but apparently it only succeeds to open an ALSA
device if the number of channels match.
On my laptop with only one USB bus, If I connected
the MOTU 624 AVB
and
then another high speed usb device, the computer could not connect the
later, because the MOTU reserved all the bandwith for itself.
Connecting
the other device and then the MOTU worked.
this is correct, and likely a sensible design choice. others may
disagree. i actually threw away a webcam because i mistakenly believed
that it was no longer working (because of this issue).
That's hilarious. I only stumbled upon this issue by looking at dmesg
output because of something unrelated. Thankfully the dmesg output is
quite verbose and clear about what's going on.
10:59 p.m.
On 3/30/19 10:37 AM, Max wrote:
Yes, that is the one. Emailed to me by Anders Hellquist when he read my
lac paper (thanks!).
On 30.03.19 04:52, Paul Davis wrote:
> On Fri, Mar 29, 2019 at 4:57 PM Max <abonnements(a)revolwear.com
...
fernando
mentioned a post on "linux musicians" which describes each one.
for reference, I guess the thread is this one:
https://www.linuxmusicians.com/viewtopic.php?f=6&t=18046 It's a rather long thread with some interesting
tidbits here and there.
It has a LOT of information!
Someone even wrote a test program, but one has to be
signed in to see
attachments on this forum.
Three takeaways from this thread:
1. AVB might be supported by the kernel at some point, which would allow
to use the AVB interfaces without the USB connection.
That is what I am waiting for... A very long time ago I managed to get
the OpenAVnu code compiled and got a linux machine to recognize and sync
with a Motu's clock - never got further (and that was not particularly
easy).
From the thread it appears that at least one user has working code for
streaming one AVB stream (8 channels) back and forth. Sounds fantastic.
There was also a paper in LAC about syncing jack with an AVB clock so
that is also a step in the right direction.
Still, for systems like the one in our Listening Room and Stage going
the USB way as an interface for end users seems like the best option. I
would probably not want to expose the whole AVB network behind the scenes...
See: https://github.com/L-Acoustics/avdecc for a
multiplatform
implementation.
...
The old firmwares are downloadable here:
http://motu.com/techsupport/technotes/firmwarechangelog/
3. There is no way to change the number of channels through ALSA or via
the configuration panel of the web-interface. It's static.
That is true if you use the ALSA "hw" interface, which is what you want
to do if you use Jack (ie: direct access to the hardware with nothing in
between). The number of channels you open has to match what the hardware
can do.
If you use instead the ALSA "plughw" interface you could open it with
less channels and ALSA would insert stuff in the middle to account for
the discrepancy but you don't want to go down that rabbit hole with
Jack. You want direct access to the hardware.
Other stuff I found in the thread (or in comments from Anders):
With a usb kernel audio driver quirk you can access the proprietary usb
streaming endpoints (not class compliant) of the audio interface, but
that does not seem to help.
Another one is an incantation for switching the interface between
"proprietary mode" and "class compliant mode". That might explain why
sometimes a Linux laptop does not see the interface after a Mac has been
using it and probably also the other way around. When I hit this I never
had time to investigate. I would probably need a GUI exposed button to
fix this...
And probably other juicy stuff, I have to re-read the thread again... I
was busy at the time with other stuff. I have to sign up to be able to
see the patches and other stuff.
Anders emailed me a beta version of the firmware for the UltraLite that
him best performance - I think it did fix problems for someone that was
at LAC...
-- Fernando
Why can't I tell ALSA to use only the
first 2, 4 whatever channels of
the device? I can only open the device if all channels are
connected. Is
this always like that or is that a limitation of MOTU's
implementation?
ALSA doesn't work that way. You open a device. You tell it how many
channels you want to use.
That's what I thought, but apparently it only succeeds to open an ALSA
device if the number of channels match. 
31 Mar
31 Mar
11:27 p.m.
On 2019-03-30 13:58:59 (-0700), Fernando Lopez-Lezcano wrote:
Anders emailed me a beta version of the firmware for
the UltraLite that him
best performance - I think it did fix problems for someone that was at
LAC...
I didn't dare use the MOTU UltraLite AVB because of the bizarre issues
I
had with it during rehearsals (e.g. random channel assignments, extreme
noise/bitcrushing on the outputs after a few minutes). I ended up with
a Focusrite Scarlett 18i20, which works fine and is properly supported
by using e.g. alsamixer or qasmixer.
However, I helped another group of artists use the MOTU interface with a
different firmware (1.3.4+558, instead of 1.3.4+608), which seemed to
have worked out fine for them!
@nando, thanks again for providing the downgrade blob on short notice!
It's pretty sad though, that the firmware produced by MOTU is in such
bad shape and breaks on a build number level. That's not exactly a
selling point...
Best,
David
P.S.: A note on the change of samplerate/ start with JACK on the MOTU
device. The device will display the SR in use, it's apparently just way
too slow to switch on demand and then be used by ALSA (e.g. through
JACK). Well, at least there's a visual indication of what's going on
there.
--
https://sleepmap.de
5 Apr
5 Apr
9:35 p.m.
On 3/31/19 12:27 PM, David Runge wrote:
On 2019-03-30 13:58:59 (-0700), Fernando Lopez-Lezcano
wrote:
Definitely not a selling point. But more and more frequent as products
morph over time due to firmware changes (for better or for worse).
Luckily these audio interfaces do not (yet?) NEED to communicate to the
mothership to be able to move samples around.
Anders emailed me a beta version of the firmware
for the UltraLite that him
best performance - I think it did fix problems for someone that was at
LAC......
However, I helped another group of artists use the MOTU interface with
a
different firmware (1.3.4+558, instead of 1.3.4+608), which seemed to
have worked out fine for them!
@nando, thanks again for providing the downgrade blob on short notice!
It's pretty sad though, that the firmware produced by MOTU is in such
bad shape and breaks on a build number level. That's not exactly a
selling point... P.S.: A note on the change of samplerate/ start with
JACK on the MOTU
device. The device will display the SR in use, it's apparently just way
too slow to switch on demand and then be used by ALSA (e.g. through
JACK). Well, at least there's a visual indication of what's going on
there.
Yes, I have to check the front panel again but I think the sampling rate
indicator flashes while it is not yet locked to the new sampling rate
(at least in the bigger interfaces, I don't remember what it does on the
UltraLite).
-- Fernando
2 Jun
2 Jun
5:40 p.m.
Hi,
I've read through the following threads:
- https://linuxmusicians.com/viewtopic.php?f=6&t=18046
-
http://linux-audio.4202.n7.nabble.com/Hardware-Soundcard-MOTU-624-AVB-Worki…
Especially in the latter thread georgnk replied with the following:
http://linux-audio.4202.n7.nabble.com/Hardware-Soundcard-MOTU-624-AVB-Worki…
I'm curious regarding those period clicks/xruns.
Reason being that I own a Motu 624 AVB and have been troubleshooting xruns
for a couple weeks now.
I've ended up filling a bug report:
https://bugzilla.kernel.org/show_bug.cgi?id=203659
It's basically about xruns happening within suspiciously regular time
intervals depending on
alsa settings.
Various system optimizations do not make a difference. (RT kernel, realtime
priorities, cpu max performance, ...)
The attachment within https://bugzilla.kernel.org/show_bug.cgi?id=203659#c9
shows an analysis of
of a ftrace-trace, which shows a clear pattern in the interaction between
xhci and jackdbus whenever
such an xrun occurs.
By any chance, does someone else experience "sporadic" xruns even while the
system is idle,
that are actually of pretty regular nature?
Easiest way to verify this is to run cadence in verbose mode and have a look
at the message log;
specifically xrun messages and their timestamps.
Running at higher sample rates and low buffer size speeds up the occurrence
of these xruns in my case.
-- Goli4thus
--
Sent from: http://linux-audio.4202.n7.nabble.com/linux-audio-user-f5.html
30 Mar
30 Mar
10:40 p.m.
On 3/29/19 4:56 PM, Max wrote:
Fernando Lopez-Lezcano discussed the pitfalls of using
the MOTU AVB
external audio interfaces with Linux in his paper [1] and also in the
keynote at LAC-19.
(I have to clarify that I have never been a fan of Motu and that Motu
does NOT support linux - we happen to be able to use these cards because
of class compliant driver support, to some degree, and the fact that the
configuration is exposed through a built-in web server)
Let's start another thread around this card.
(I'll add to the other messages as well... I started writing this last
night)
Fernando mentioned that different firmwares expose
different issues, but
downgrading is possible.
At least for now and in my experience. I presume that at some point the
internal hardware might change in such a way that a downgrade is not
possible. I think this has already happened for the UltraLite AVB. The
Motu site lists firmware versions going down to 1.1.4, see:
http://motu.com/techsupport/technotes/firmwarechangelog/
I was not able to downgrade my UltraLite AVB to less than 1.3, a popup
would tell me the firmware and hardware were not compatible.
So while everything described below, including downgrades, seems to be
doable now (or at least the last time I bought an interface), that might
change in the future with no warning.
Issues are:
1. Channels are not persistent and swap around.
I have noted the following behavior on a 1248 with version xxx (sorry, I
would to look this up at ccrma): route input to channel 1 - we see
signal in channel 1, after a few seconds it appears in channel 9, then
in 17 and so on and so forth. Downgrading the firmware cured this
(again, I need to look up the current version running on that card).
2. Total number of channels has been reduced in newer
firmwares.
The initial firmware I played with could only do 24 channels in CC
(Class Compliant) mode, a firmware upgrade (1.2.8+) changed that to a
max of 64 channels when using 44.1 or 48KHz sampling rate - the firmware
adds a popup to the web based configuration to select max number of
channels based on max sampling rate.
A subsequent firmware upgrade (1.2.9+) removed that feature - I filed a
bug with Motu and was eventually told it had been removed because of
unspecified problems. This is on the 16A, 24Ao and 24Ai, and maybe
others of the same generation (8M, etc).
So if you need 64 channels 1.2.8+ is what you should use (based on my
experience). If 24 channels is fine then newer firmware versions might
be better (or worse :-)
If you are playing with that many channels you are probably going to
chain audio interfaces together through AVB like I did, in that case you
should check to see how many AVB streams are supported in the card of
your choice. The 16A which I tend to use as hub supports 16 in 16 out
(so at most 128 channels at one time). Other have less, the UltraLite
can only do 3 at most. The 24Ao and 24Ai are asymmetrical (4 x 8 or
visceversa).
3. An endless card aquisition loop between Jack and
Pulseaudio caused by
the long time the card needs to switch sampling rate.
4. Seemingly erratic behavior, opening the device fails, fails again,
again, then works suddenly.
As pointed out in the thread I believe both 3 and 4 share the same
cause, which is, AFAICT, related to the long time it takes for the clock
to lock when the sampling rate is changed (or when the card is used for
the first time).
ALSA seems to tell jack the card can do what jack requires (in terms of
sampling rate, etc), and when jack tries to actually start it fails if
the internal clock is not locked. Maybe there is no mechanism in ALSA
that could be used to report or control this. I can't think of a way
this could be handled that would work in all cases. What other software
does when working directly with ALSA (Audacity) is to just play even
though the clock is not running - the card will be silent until the
clock locks and starts playing whatever is playing at the moment). Not
optimal but a way around this.
The ALSA interface _sometimes_ (depends on firmware and interface
model?) exposes a lock indicator that can be read from userspace with
amixer. I currently query the interface with http+JSON and wait for the
clock to lock before starting jack - this is on system that boot into a
working diffusion system, not so practical for a stand-alone normal
application (and needs an ethernet connection to the audio interface).
I have a couple of questions and experiences.
Is there a table of the firmware versions somewhere (linuxaudio wiki?)
which tell me which versions has which features (removed)?
Not that I know of. See versions above for a start. I can add a few more
data points when I go back to ccrma on Monday.
Are all the Class Compliant models having the same
quirks as listed
above? For example the
MOTU UltraLite AVB versus the MOTU 624 AVB?
I have used the 16A, 24Ai, 24Ao (these three extensively used), 8M, 1248
and Ultralite AVB. Also the 8A which is a different generation (USB3
interface), this last one used to have problems - tiny clicks when
playing back - but I think it now works fine (newer kernel?)
Is it possible to use the Thunderbolt port to connect
the card to a
Linux computer?
Not as far as I know. I did some research a while back and I remember I
found nothing of the sort. This would require (I think) new drivers in
the Linux kernel.
-- Fernando
Why can't I tell ALSA to use only the first 2, 4
whatever channels of
the device? I can only open the device if all channels are connected. Is
this always like that or is that a limitation of MOTU's implementation?
On my laptop with only one USB bus, If I connected the MOTU 624 AVB and
then another high speed usb device, the computer could not connect the
later, because the MOTU reserved all the bandwith for itself. Connecting
the other device and then the MOTU worked.
[1] http://lac.linuxaudio.org/2019/doc/lopez.pdf
31 Mar
31 Mar
6:53 p.m.
On Sat, 30 Mar 2019, Fernando Lopez-Lezcano wrote:
On 3/29/19 4:56 PM, Max wrote:
> 3. An endless card aquisition loop between Jack and Pulseaudio caused by
> the long time the card needs to switch sampling rate.
> 4. Seemingly erratic behavior, opening the device fails, fails again,
> again, then works suddenly.
Not really related to just the motu devices but when using both pulse and
jack with any device:
1) The device jack uses should have it's pulse profile set to
"Off"
2) Pulse uses 44k1 as default SR if Jack uses 48K there will be
an SR change switching from one to the other. Setting
Pulse's default (and secondary) SR the same as jack
might help. (The internal HDA audio seems to be designed
around 48k anyway and so probably sounds better there)
3) If using the pulse-jack bridge, All device profiles in pulse
should be turned to "Off". Better is to unload the alsa
and udev modules from pulse and use jack as the only
pulse device. This will allow jack to freewheel and
create less xruns.
My comment about AVB and the motu devices is that the HW in these devices
does not seem to be up to the latency AVB requires. One thing the LAC talk
on the AVB jack backend pointed out to me is the 6 sample buffer size/irq
rate. Can these devices be set to run at 12 samples? Or does that drop the
channel count as well due to packet size? (I wouldn't think so as each
stream is up to 8 channals) From what I have read, the motu devices are
just barely AVB compliant and do not allow all the various AVB rates.
There is one that is aes67 compatable with 1ms packets that may work
better for PC (any OS) to AVB network.
Also, for high channel work on the motu devices, I would suggest no
internal audio processing be used aside from routing. The internal mixer
with eq and effects may be what has caused trouble and decided people
fewer channels was a better choice for the firmware.
Sometimes advertizing gets in the way of usablility.
--
Len Ovens
www.ovenwerks.net
10:10 p.m.
Strange that no one mentioned the "stuttering" audio effect with the
latest firmwares. Sound quickly becomes distorded. I have the Motu
828ES, and I had also to download the oldest driver to have it working
correctly. Concerning the other issues, I have also the channel swapping
and the double start needed for jack.
Cheers
Bernard
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-user
1 Apr
1 Apr
4:24 a.m.
On 3/31/19 7:53 AM, Len Ovens wrote:
On Sat, 30 Mar 2019, Fernando Lopez-Lezcano wrote:
...
My comment about AVB and the motu devices is that the
HW in these
devices does not seem to be up to the latency AVB requires.
Or up to USB either. The thread in linuxmusicians suggests that the
internal processing of the interfaces is very sensitive to interruptions
in the USB packet stream. Anything dropping or being delayed messes up
the card.
Before reading that thread I was also pretty sure (but just a guess)
that the processor inside the card was on the edge of not being fast
enough so any glitches would affect sample recovery or processing.
In particular at some point I was running jackd with "-s" (I had enabled
that for other reasons and then forgot about it). With that option it
was rather easy to get the USB interface to introduce weird periodic
glitches (once a second?), high frequency noises and distortion that
would NOT stop and were transmitted through AVB quite nicely - the
recovery of samples in the card seemed to be really messed up which is
to be expected to a degree if jackd does not properly recover from
xruns. I don't know if this happens in other USB interfaces as well or
is a "feature" of the Motus.
One thing
the LAC talk on the AVB jack backend pointed out to me is the 6 sample
buffer size/irq rate. Can these devices be set to run at 12 samples? Or
does that drop the channel count as well due to packet size? (I wouldn't
think so as each stream is up to 8 channals) From what I have read, the
motu devices are just barely AVB compliant and do not allow all the
various AVB rates. There is one that is aes67 compatable with 1ms
packets that may work better for PC (any OS) to AVB network.
Do you know which one? The Motu FAQ still states that the cards are not
aes67 compatible.
In our big system (8 audio interfaces + 3 AVB switches) we have seen,
very occasionally, a few AVB streams drop out, I think always related to
the interface that connects to external laptops (through USB). The AVB
streams blink in the connection gui and cannot be reconnected - only a
reboot of both cards involved seem to fix this.
I have to do a thorough cleanup of overall AVB streams, we may be
running into limits on how many streams the AVB switches can reliably
handle - see below - the system grew "organically" and needs some love
(in short, it is a mess! :-).
There is a very nice list of switches (and their AVB capabilities) here:
https://support.biamp.com/Tesira/AVB/List_of_AVB-capable_Ethernet_switches
Also, for high channel work on the motu devices, I
would suggest no
internal audio processing be used aside from routing. The internal mixer
with eq and effects may be what has caused trouble and decided people
fewer channels was a better choice for the firmware.
Definitely. I turn off anything in the card that is not needed,
including the whole mixer. I don't know if it really helps, but I
presume the main processor will have less stuff to do.
-- Fernando
2029
days inactive
2093
days old
linux-audio-user@lists.linuxaudio.org
13 comments
8 participants
participants (8)
-
bernard -
David Runge -
Fernando Lopez-Lezcano -
Fons Adriaensen -
Goli4thus -
Len Ovens -
Max -
Paul Davis