11 May
2017
11 May
'17
9:17 p.m.
Hi Folks,
after a long period of being distracted from doing sound work I'm getting
back into business. I needed a solid solution for Audio Interface, so I
started researching.
I must say that from my perspective a lot has happened in the past three
four years.
More class compliant interfaces enter the market and the horizon widens
regarding hardware in Linux.
I came across the new Motu AVB devices and could'nt believe that they would
be the solution to my hardware problems.
The point is, my old studio and travelling interfaces are RME HDSP9652 and
TC Impact twin, respectively.
The RME always just worked. Pretty low latencies and with the right
configuration zero xruns.
The TC has a little bit higher latency but also pretty solid.
But... they are old interfaces and the time will shortly come when I will
not be able to buy a new PC/laptop with PCI or Firwire ports.
So I looked for other options...
Rme new stuff is mostly class compliant but has proprietary drivers and
that means no control over certain features.
So I got a pretty good deal on a Motu 1248 and went for it.
Here are my first impressions from half a day of testing.
First and foremost, the interface just works! Out of the box. I plugged it
in configured Jack and got sound. Great... and non trivial for Linux.
After a bit of fiddling around with my Network settings I got the control
software to work, and I must say it's just amazing to have a piece of
equipment that I can fully use under Linux.
There is a full featured mixer in the DSP that's also a nice addition, but
the main thing for me was the routing matrix, which is pretty cool to have.
Latency - The latency in CC mode is better than my Firewire interface, but
still a bit worse than the rme. For now I succeded to run a medium session
(25 Channels with processing and fx) at 64 frames buffer size with 3
buffers.
Certainly not bad. While playing guitar and singing I didn't feel any of
this annoying delay that you sometimes get when the latency is bad.
Sound quality - Pretty good. I have nothing to complain about... Though I
can't really hear the supposedly amazing ESS converters stand out from the
other professional DAC crowd...
To be honest in the Studio I'm working happily with the old Alesis HD24xr
AD/DC to make 1/0 out of my precious electrons...
The Preamps are pretty clean sounding from my firswt impression, but I
really didn't have enough time to toy with them.
The channel count is huge for my terms. 64 in and out... That should be
enough for me. Though I didn't get around to check if the AVB connection
does really work on Linux.
To summarize I'm feeling that we are moving in the right direction here...
I hope other manufacturers will follow and make Interfaces and software
that work with Linux...
Cheers
Moshe
12 May
12 May
1:33 a.m.
On Thu, 11 May 2017 21:17:23 +0200
Moshe Werner <moshwe(a)gmail.com> wrote:
To summarize I'm feeling that we are moving in the
right direction
here... I hope other manufacturers will follow and make Interfaces
and software that work with Linux...
Thanks for your review. It's always useful to know about other sources
of audio interfaces. Do you happen to know if all MOTU interfaces
follows the same compatibility design, or is the 1248 innovating in
this ?
Cheers.
5:08 p.m.
On Thu, 11 May 2017, jonetsu wrote:
On Thu, 11 May 2017 21:17:23 +0200
Moshe Werner <moshwe(a)gmail.com> wrote:
I think it is just the AVB line. To control the internal mixer you need to
AVB port anyway. I do not think they redesigned their older but still in
production devices.
--
Len Ovens
www.ovenwerks.net
To summarize I'm feeling that we are moving
in the right direction
here... I hope other manufacturers will follow and make Interfaces
and software that work with Linux...
Thanks for your review. It's always useful to know about other sources
of audio interfaces. Do you happen to know if all MOTU interfaces
follows the same compatibility design, or is the 1248 innovating in
this ? 
9:42 a.m.
Hi,
Thanks for this review, it is always useful and interesting to get
hands-on experiences with hardware on Linux...
On 11/05/2017 21:17, Moshe Werner wrote:
[...]
After a bit of fiddling around with my Network settings I got the
control software to work, and I must say it's just amazing to have a
piece of equipment that I can fully use under Linux.
There is a full featured mixer in the DSP that's also a nice addition,
but the main thing for me was the routing matrix, which is pretty cool
to have.
[...]
To summarize I'm feeling that we are moving in the
right direction here...
I hope other manufacturers will follow and make Interfaces and software
that work with Linux...
Yes I agree. On the MOTU website I even read: "MOTU AVB audio interfaces
can be remotely controlled from a hardware controller or software
interface using either OSC or HTTP."
And yes hopefully manufacturers will continue with class compliant open
APIs, web-apps etc. for control software...
Lorenzo.
12:16 p.m.
This is awesome news. I've been interested in MOTU interfaces for a long
time, but avoided them given their lack of cooperation with the Linux
community.
Which interface did you use? Does it work with thunderbolt, USB or both? If
you've tried both did you notice any differences in performance between
the two?
Thanks for sharing your experiences.
--
Bearcat M. Şándor
Feline Soul Systems LLC
Voice: 872.CAT.SOUL (872.228.7685)
Fax: 406.235.7070
On May 12, 2017 01:42, "Lorenzo Sutton" <lorenzofsutton(a)gmail.com> wrote:
Hi,
Thanks for this review, it is always useful and interesting to get
hands-on experiences with hardware on Linux...
On 11/05/2017 21:17, Moshe Werner wrote:
[...]
After a bit of fiddling around with my Network settings I got the
control software to work, and I must say it's just amazing to have a
piece of equipment that I can fully use under Linux.
There is a full featured mixer in the DSP that's also a nice addition,
but the main thing for me was the routing matrix, which is pretty cool
to have.
[...]
To summarize I'm feeling that we are moving
in the right direction here...
I hope other manufacturers will follow and make Interfaces and software
that work with Linux...
Yes I agree. On the MOTU website I even read: "MOTU AVB audio interfaces
can be remotely controlled from a hardware controller or software interface
using either OSC or HTTP."
And yes hopefully manufacturers will continue with class compliant open
APIs, web-apps etc. for control software...
Lorenzo.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
5:06 p.m.
On May 12, 2017 12:17, "Bearcat Şándor" <bearcatsandor(a)gmail.com> wrote:
This is awesome news. I've been interested in MOTU interfaces for a long
time, but avoided them given their lack of cooperation with the Linux
community.
Which interface did you use? Does it work with thunderbolt, USB or both? If
you've tried both did you notice any differences in performance between
the two?
Thanks for sharing your experiences.
--
Bearcat M. Şándor
Feline Soul Systems LLC
Voice: 872.CAT.SOUL (872.228.7685 <(872)%20228-7685>)
Fax: 406.235.7070 <(406)%20235-7070>
Actually Motu are not cooperating so much with Linux, it's more that we
profit from IOs users wanting to use audio interfaces...
I'm using the 1248, and as I said the m8 and A16 should work too because
it's basically the same interface with a different analogue front end.
I did not try thunderbolt, this requires drivers and they are not available
for Linux.
Class compliant USB works out of the box.
The control over the software is done via Ethernet.
Cheers
6:09 p.m.
On Fri, May 12, 2017 at 9:06 AM Moshe Werner <moshwe(a)gmail.com> wrote:
On May 12, 2017 12:17, "Bearcat Şándor" <bearcatsandor(a)gmail.com> wrote:
This is awesome news. I've been interested in MOTU interfaces for a long
time, but avoided them given their lack of cooperation with the Linux
community.
Which interface did you use? Does it work with thunderbolt, USB or both?
If you've tried both did you notice any differences in performance between
the two?
Thanks for sharing your experiences.
--
Bearcat M. Şándor
Feline Soul Systems LLC
Voice: 872.CAT.SOUL (872.228.7685 <(872)%20228-7685>)
Fax: 406.235.7070 <(406)%20235-7070>
Actually Motu are not cooperating so much with Linux, it's more that we
profit from IOs users wanting to use audio interfaces...
I'm using the 1248, and as I said the m8 and A16 should work too because
it's basically the same interface with a different analogue front end.
I did not try thunderbolt, this requires drivers and they are not
available for Linux.
Class compliant USB works out of the box.
The control over the software is done via Ethernet.
Cheers
Unless i'm missing something, Thunderbolt (which is version 3) is
available
under "Device Drivers" in my kernel version 4.10.13. I'm not
sure at what kernel version it became available, but it looks like it was
put in sometime last year.
--
Bearcat M. Şándor, CEO
Feline Soul Systems LLC
Voice: 872.CAT.SOUL (872.228.7685)
Fax: 406.235.7070
6:16 p.m.
On May 12, 2017 18:09, "Bearcat Şándor" <bearcatsandor(a)gmail.com> wrote:
On Fri, May 12, 2017 at 9:06 AM Moshe Werner <moshwe(a)gmail.com> wrote:
On May 12, 2017 12:17, "Bearcat Şándor" <bearcatsandor(a)gmail.com> wrote:
This is awesome news. I've been interested in MOTU interfaces for a long
time, but avoided them given their lack of cooperation with the Linux
community.
Which interface did you use? Does it work with thunderbolt, USB or both?
If you've tried both did you notice any differences in performance between
the two?
Thanks for sharing your experiences.
--
Bearcat M. Şándor
Feline Soul Systems LLC
Voice: 872.CAT.SOUL (872.228.7685 <(872)%20228-7685>)
Fax: 406.235.7070 <(406)%20235-7070>
Actually Motu are not cooperating so much with Linux, it's more that we
profit from IOs users wanting to use audio interfaces...
I'm using the 1248, and as I said the m8 and A16 should work too because
it's basically the same interface with a different analogue front end.
I did not try thunderbolt, this requires drivers and they are not
available for Linux.
Class compliant USB works out of the box.
The control over the software is done via Ethernet.
Cheers
Unless i'm missing something, Thunderbolt (which is version 3) is
available
under "Device Drivers" in my kernel version 4.10.13. I'm not
sure at what kernel version it became available, but it looks like it was
put in sometime last
But there is no class compliant audio driver for TB.
The interface works with USB because you don't have to install a driver,
it's class compliant.
For TB audio to work you do need a proprietary driver, which, to my best
understanding, there is none for Linux.
I would love to be proven wrong.
6:20 p.m.
On Fri, 12 May 2017, Bearcat Şándor wrote:
On Fri, May 12, 2017 at 9:06 AM Moshe Werner
<moshwe(a)gmail.com> wrote:
Not knowing thumderbolt at all, the next question in my mind is, being
able to talk thunderbolt is one thing, but being able to talk to any one
device at the end of a thunderbolt interface may be a different thing. It
there a thunderbolt audio device standard yet? Does Linux support it?
--
Len Ovens
www.ovenwerks.net
I did not try thunderbolt, this requires drivers
and they are not
available for Linux.
Unless i'm missing something, Thunderbolt (which is version 3) is available under
"Device Drivers" in my kernel version 4.10.13. I'm not sure at what
kernel
version it became available, but it looks like it was put in sometime last year. 
10:03 p.m.
On 05/11/2017 12:17 PM, Moshe Werner wrote:
Hi Folks,
...
So I got a pretty good deal on a Motu 1248 and went
for it.
Here are my first impressions from half a day of testing.
First and foremost, the interface just works! Out of the box. I plugged
it in configured Jack and got sound. Great... and non trivial for Linux.
After a bit of fiddling around with my Network settings I got the
control software to work, and I must say it's just amazing to have a
piece of equipment that I can fully use under Linux.
There is a full featured mixer in the DSP that's also a nice addition,
but the main thing for me was the routing matrix, which is pretty cool
to have.
Yes, this is very nice and gives access to all the configuration switches.
Latency - The latency in CC mode is better than my
Firewire interface,
but still a bit worse than the rme. For now I succeded to run a medium
session (25 Channels with processing and fx) at 64 frames buffer size
with 3 buffers.
Certainly not bad. While playing guitar and singing I didn't feel any of
this annoying delay that you sometimes get when the latency is bad.
Make sure you are running threaded irq's and that the irq that handles
the usb connection is running with "soundcard priority". That helps a
lot (maybe you are already using rtirq and is doing that for you). And,
if you can, make that the only device that is attached to that
particular usb hub.
Sound quality - Pretty good. I have nothing to
complain about... Though
I can't really hear the supposedly amazing ESS converters stand out from
the other professional DAC crowd...
To be honest in the Studio I'm working happily with the old Alesis
HD24xr AD/DC to make 1/0 out of my precious electrons...
The Preamps are pretty clean sounding from my firswt impression, but I
really didn't have enough time to toy with them.
The channel count is huge for my terms. 64 in and out... That should be
enough for me. Though I didn't get around to check if the AVB connection
does really work on Linux.
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).
To summarize I'm feeling that we are moving in the
right direction here...
I hope other manufacturers will follow and make Interfaces and software
that work with Linux...
I found one issue when using Jack. When you use the interface for the
first time, or when changing sampling rates, the interface takes up to 7
seconds to actually change sampling rate and get in sync with others or
itself. During that time Jack will not start successfully ("cannot set
hardware params"). The trick so far is to be patient, wait the required
time, try again and things just work.
The A16 works, as well as the 24ai and 24ao.
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 :-(
-- Fernando
14 May
14 May
12:38 a.m.
On Fri, May 12, 2017 at 10:03 PM, Fernando Lopez-Lezcano <
nando(a)ccrma.stanford.edu> wrote:
On 05/11/2017 12:17 PM, Moshe Werner wrote:
Latency - The latency in CC mode is better than my Firewire interface,
Thanks for the tips. I just got the interface last week and am still
learning it and how it works with my laptop.
but still a bit worse than the rme. For now I
succeded to run a medium
session (25 Channels with processing and fx) at 64 frames buffer size
with 3 buffers.
Certainly not bad. While playing guitar and singing I didn't feel any of
this annoying delay that you sometimes get when the latency is bad.
Make sure you are running threaded irq's and that the irq that handles the
usb connection is running with "soundcard priority". That helps a lot
(maybe you are already using rtirq and is doing that for you). And, if you
can, make that the only device that is attached to that particular usb hub. The channel count is huge for my terms. 64 in and
out... That should be
That's great news that AVB is working on linux too!
Could you elaborate on the connection scheme of your setup? Are the
different Motu boxes connected via the AVB switches?
enough for me. Though I didn't get around to
check if the AVB connection
does really work on Linux.
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).
To summarize I'm feeling that we are moving in the right direction here...
Had the same issue! Thanks for pointing that out.
Basically I couldn't explain why at first Jack doesn't launch and then
suddenly everything is ok:)
I hope other manufacturers will follow and make
Interfaces and software
that work with Linux...
I found one issue when using Jack. When you use the interface for the
first time, or when changing sampling rates, the interface takes up to 7
seconds to actually change sampling rate and get in sync with others or
itself. During that time Jack will not start successfully ("cannot set
hardware params"). The trick so far is to be patient, wait the required
time, try again and things just work.
The A16 works, as well as the 24ai and 24ao.
That's also great news!
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...?
15 May
15 May
8:17 a.m.
On 05/13/2017 03:38 PM, Moshe Werner wrote:
On Fri, May 12, 2017 at 10:03 PM, Fernando Lopez-Lezcano
<nando(a)ccrma.stanford.edu <mailto:nando@ccrma.stanford.edu>> 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
10:56 a.m.
Could you elaborate on the connection scheme of your
setup? Are the
Thanks!
So the computer is connected to the switch too i guess? Or how do you
control the routing?
Cheers
Moshe
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 :-)
5:11 p.m.
On Mon, 15 May 2017, Moshe Werner wrote:
So the computer is connected to the switch too i
guess? Or how do you control the
routing?
The motu switch has one non-AVB port to connect to "the rest or the
network".
--
Len Ovens
www.ovenwerks.net
7:13 p.m.
On 05/15/2017 01:56 AM, Moshe Werner wrote:
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.
...
So far so good... hopefully I will not run into
any pitfalls :-)
So the computer is connected to the switch too i guess? Or how do you
control the routing?
I'm also connecting the computer to the switch to be able to control the
routing matrix, actually I'm connected to one of the AVB enabled ports.
The computer has an i210 Intel ethernet adapter that is AVB compatible
although I'm not running AVB on it yet (hopefully at some point in the
future I will be able to do away with the USB connection).
-- Fernando
7:27 p.m.
On May 15, 2017 19:13, "Fernando Lopez-Lezcano"
<nando(a)ccrma.stanford.edu>
wrote:
On 05/15/2017 01:56 AM, Moshe Werner wrote:
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.
...
So far so good... hopefully I will not run into
any pitfalls :-)
So the computer is connected to the switch too i guess? Or how do you
control the routing?
I'm also connecting the computer to the switch to be able to control the
routing matrix, actually I'm connected to one of the AVB enabled ports. The
computer has an i210 Intel ethernet adapter that is AVB compatible although
I'm not running AVB on it yet (hopefully at some point in the future I will
be able to do away with the USB connection).
-- Fernando
Amen to that!
12:44 p.m.
* Fernando Lopez-Lezcano <nando(a)ccrma.Stanford.EDU> [2017-05-12 22:03]:
[...]
I found one issue when using Jack. When you use the
interface for the first
time, or when changing sampling rates, the interface takes up to 7 seconds
to actually change sampling rate and get in sync with others or itself.
During that time Jack will not start successfully ("cannot set hardware
params"). The trick so far is to be patient, wait the required time, try
again and things just work.
I just found out that dmesg prints
[57372.087388] usb 1-1.1: clock source 1 is not valid, cannot use
when connecting the interface via usb to my computer, and a second
[57439.743840] usb 1-1.1: clock source 1 is not valid, cannot use
when I try to start jackd the first time (which causes the same error as
you have)
and the seconds attempt works without further dmesg lines.
There are various bug reports for "clock source N is not valid" findable
on line, but I haven't found the time to check them yet.
P
12 May
12 May
10:06 p.m.
Hello.
Thank you for your report on this 1248.
I've made the report on the ULTRALITE AVB in march.
[http://lists.linuxaudio.org/pipermail/linux-audio-user/2017-March/107629.ht…]
I've finally bought one, and since 1 month, it runs without any
troubles.
I think it's safe to say that the AVB serie (1248 / 624 / ULTRALITE) is
working for Gnu/Linux.
I'm maybe missed it, but which distro are you running this card on ?
Did you register your product on MOTU web site, and add a comment that
you running it with Gnu/Linux. I like to believe that each voice
count :)
Le Thu, 11 May 2017 21:17:23 +0200,
Moshe Werner <moshwe(a)gmail.com> a écrit :
While playing guitar and singing I didn't feel
any
of this annoying delay that you sometimes get when the latency is bad.
You surely see that, but you can, thanks to the routing matrix, have
near 0 latency on hardware monitoring while recording (guitar/vocal)
nothing goes through the computer. You also have to set the option in
your DAW to use hardware monitoring.
To summarize I'm feeling that we are moving in the
right direction
here... I hope other manufacturers will follow and make Interfaces
and software that work with Linux...
Yeah ! But like Len Ovens said on the ULTRALITE report, it's more «side
effect» of IOS...than a real Gnu/Linux support. They just repected USB
CLASS audio «standard» [lot of other brands claim to be Class
compliant, but you do not have the softwares to control the card, so
useless ] and embedded the usually softwares they ship for Win/Mac
inside the card. Anyway it work !
Cheers
Moshe
All the best !
13 May
13 May
1:48 p.m.
Hello All !
Le Fri, 12 May 2017 22:09:26 +0200,
list <list(a)contacte.xyz> a écrit :
I think it's safe to say that the AVB serie (1248 / 624 / ULTRALITE)
is working for Gnu/Linux.
Hmm according to Fernando's message :
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 :-(
The MOTU 624 might have troubles, as the USB port is a USB3 one.
I really have to find one to test.
Fernando : Have you had a chance to tweak/test the bios settings
related to USB : hands off / legacy and others options that motherboard
sometimes offers ?
All the best.
2:09 p.m.
On Sat, 13 May 2017 13:50:40 +0200, list wrote:
Le Fri, 12 May 2017 22:09:26 +0200, list a écrit :
Don't waste your limited life span with such questions and possible
workarounds, since it's not worse the effort, assuming making music
should be your aim. Get a class compliant USB device and ignore all
those special offers, just use a modern PC + the audio interface as a
class compliant audio interface and don't use the audio devices hardware
monitoring and any additional features. _Simply_ use a mixing console
for the monitoring or use software monitoring with less latency. You
need to weighing up your "available lifetime" with "computer geek
trendy" vs "the passion to make music".
I think it's safe to say that the AVB serie
(1248 / 624 / ULTRALITE)
is working for Gnu/Linux.
Hmm according to Fernando's message :
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
Fernando : Have you had a chance to tweak/test the bios settings
related to USB : hands off / legacy and others options that
motherboard sometimes offers ?
2:37 p.m.
Le Sat, 13 May 2017 14:09:02 +0200,
Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> a écrit :
Got my answer :)
philosophical way
Don't waste your limited life span with such questions and possible
workarounds, since it's not worse the effort, assuming making music
should be your aim. Get a class compliant USB device and ignore all
those special offers, just use a modern PC + the audio interface as a
class compliant audio interface and don't use the audio devices
hardware monitoring and any additional features. _Simply_ use a
mixing console for the monitoring or use software monitoring with
less latency. You need to weighing up your "available lifetime" with
"computer geek trendy" vs "the passion to make music".
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
15 May
15 May
7:42 a.m.
On 05/13/2017 05:09 AM, Ralf Mardorf wrote:
On Sat, 13 May 2017 13:50:40 +0200, list wrote:
In case you did not notice this is, AFAIK, a class compliant device. It
works fine over USB2 as a class compliant device but the channel count
is limited (which might be fine, it depends on the application).
When using the USB3 transport layer (ie: connected to a USB3 port
instead of USB2), the Linux kernel has problems with the interface. I
have not had time to look at this further - I selected and I'm using the
older devices that work fine for my needs using USB2.
Le Fri, 12 May 2017 22:09:26 +0200, list a écrit
:
Don't waste your limited life span with such questions and possible
workarounds, since it's not worse the effort, assuming making music
should be your aim. Get a class compliant USB device and ignore all
those special offers, just use a modern PC + the audio interface as a
class compliant audio interface and don't use the audio devices hardware
monitoring and any additional features. I think it's safe to say that the AVB serie
(1248 / 624 / ULTRALITE)
is working for Gnu/Linux.
Hmm according to Fernando's message :
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
Fernando : Have you had a chance to tweak/test the bios settings
related to USB : hands off / legacy and others options that
motherboard sometimes offers ? _Simply_ use a mixing console
for the monitoring or use software monitoring with less latency.
As usual it depends. Sometimes that is just not an option.
You need to weighing up your "available
lifetime" with "computer geek
trendy" vs "the passion to make music".
Thanks for the advice. It is, and always has been, a balancing act. I
think I'm doing fine (https://ccrma.stanford.edu/~nando/).
This is (I think) a Linux kernel problem. If nobody spent time trying to
hunt down weird problems like this one we would not have Linux or this
list.
-- Fernando
13 May
13 May
2:21 p.m.
PS:
In this case ask yourself, if you need more than 24 I/O channels. If
you should need more 24 I/O channels, consider if it's a wise decision
to use any fish tweaks, instead of thinking about a professional
solution. I seriously doubt that amateurs and semi-professional users
often tend to need > 24 I/O. A professional should take into account if
it's worth the effort to risk something, instead of simply using a
solution that is supported by the interface's vendor(s).
15 May
15 May
7:48 a.m.
On 05/13/2017 04:50 AM, list wrote:
Hello All !
Le Fri, 12 May 2017 22:09:26 +0200,
list <list(a)contacte.xyz> a écrit :
Yes, it looks like that one might be affected, it is probably based on
the same platform. I tested (and still have) an 8A.
I think it's safe to say that the AVB serie (1248 / 624 / ULTRALITE)
is working for Gnu/Linux.
Hmm according to Fernando's message :
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 :-(
The MOTU 624 might have troubles, as the USB port is a USB3 one. I really have to find one to test.
Fernando : Have you had a chance to tweak/test the bios settings
related to USB : hands off / legacy and others options that motherboard
sometimes offers ?
No, sorry, no time to test further. I don't think I saw any options in
the BIOS of the mobo I was testing with. It seemed like a pretty bad
USB3 problem (or interaction with the firmware and/or hardware in the
8A). The interface was recognized fine, but any attempt to use it would
hang the driver and require a reboot. This was perhaps a month ago or
more, maybe there is newer Motu firmware. Also, this was on 4.9.11-rt9,
newer kernels might have this fixed (or might be worse :-)...
Best luck!
-- Fernando
13 May
13 May
9:39 p.m.
I just bought a couple of Ultralite AVBs the other day since I got a really
good offer.
Have not received them yet so I have not tested them.
I have been following for some time the development of the openAVB project
and I really hope this standard is getting more widely spread.
What I cannot understand (well I can understand but not embrace) is the
fact that every vendor except AVB-switch vendors have their own
implementation and by design make their products compatible only with its
own brand. The point with a standard is IMHO to make products able to talk
to each other. Motu apparently enabled talking to some Avid
equipment some time ago with a new firmware but non-Avid brands are not
compatible AFAIK.
I guess this is only marketing trying to protect their own brand more than
a pure technical decision but correct me if I am wrong.
Do you guys think that AVB devices "firmware" easily cold be changed by the
vendor to accept and cooperate with other avb streaming equipment ?
Do you think it is possible to reverse engineer the vendor specific
protocols like for instance the FFADO project has been doing with firewire
to make future openAVB implementations for the linux kernel if one is using
appropriate hardware (intel i210 or similar) ? Or is this already possible ?
Best regards, Anders
2017-05-12 22:09 GMT+02:00 list <list(a)contacte.xyz>yz>:
Hello.
Thank you for your report on this 1248.
I've made the report on the ULTRALITE AVB in march.
[http://lists.linuxaudio.org/pipermail/linux-audio-user/
2017-March/107629.html]
I've finally bought one, and since 1 month, it runs without any
troubles.
I think it's safe to say that the AVB serie (1248 / 624 / ULTRALITE) is
working for Gnu/Linux.
I'm maybe missed it, but which distro are you running this card on ?
Did you register your product on MOTU web site, and add a comment that
you running it with Gnu/Linux. I like to believe that each voice
count :)
Le Thu, 11 May 2017 21:17:23 +0200,
Moshe Werner <moshwe(a)gmail.com> a écrit :
While playing guitar and singing I didn't
feel any
of this annoying delay that you sometimes get when the latency is bad.
You surely see that, but you can, thanks to the routing matrix, have
near 0 latency on hardware monitoring while recording (guitar/vocal)
nothing goes through the computer. You also have to set the option in
your DAW to use hardware monitoring.
To summarize I'm feeling that we are moving
in the right direction
here... I hope other manufacturers will follow and make Interfaces
and software that work with Linux...
Yeah ! But like Len Ovens said on the ULTRALITE report, it's more «side
effect» of IOS...than a real Gnu/Linux support. They just repected USB
CLASS audio «standard» [lot of other brands claim to be Class
compliant, but you do not have the softwares to control the card, so
useless ] and embedded the usually softwares they ship for Win/Mac
inside the card. Anyway it work !
Cheers
Moshe
All the best !
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
14 May
14 May
12:50 a.m.
On Fri, May 12, 2017 at 10:09 PM, list <list(a)contacte.xyz> wrote:
As I said too, that's for sure not Motu suddenly loving Linux:)
But only a few weeks ago I got really frustrated on the lack of pro audio
hardware for Linux, and now I've got a fully functional system, so thanks
Mot and thanks IOS:)
Cheers
Moshe
Hello.
Thank you for your report on this 1248.
I've made the report on the ULTRALITE AVB in march.
[http://lists.linuxaudio.org/pipermail/linux-audio-user/
2017-March/107629.html]
I've finally bought one, and since 1 month, it runs without any
troubles.
So I owe you a big thank you:)
I'm maybe missed it, but which distro are you running this card on ?
I'm running it on a Lenovo W540, KXStudio.
Did you register your product on MOTU web site, and add a comment that
you running it with Gnu/Linux. I like to believe that each voice
count :)
Will do!
Le Thu, 11 May 2017 21:17:23 +0200,
Moshe Werner <moshwe(a)gmail.com> a écrit :
Yeah sure, but I wanted to try it anyway through the ardour monitoring, as
that's how I usually work.
While playing guitar and singing I didn't
feel any
of this annoying delay that you sometimes get when the latency is bad.
You surely see that, but you can, thanks to the routing matrix, have
near 0 latency on hardware monitoring while recording (guitar/vocal)
nothing goes through the computer. You also have to set the option in
your DAW to use hardware monitoring.
To summarize
I'm feeling that we are moving in the right direction
here... I hope other manufacturers will follow and make Interfaces
and software that work with Linux...
Yeah ! But like Len Ovens said on the ULTRALITE report, it's more «side
effect» of IOS...than a real Gnu/Linux support. They just repected USB
CLASS audio «standard» [lot of other brands claim to be Class
compliant, but you do not have the softwares to control the card, so
useless ] and embedded the usually softwares they ship for Win/Mac
inside the card. Anyway it work !
1:11 a.m.
On Sun, 14 May 2017 00:50:09 +0200, Moshe Werner wrote:
and thanks IOS:)
I'm using Linux and iOS, but I suspect class compliant devices are that
much supported regarding Mac OS and not regarding iOS. Both are Apple
operating systems, but during my tests, before I bought a class
compliant device that works with my iPad, as well as with Linux and
getting in contact with audio device vendors, I noticed that they do
_not_ support iOS. Some devices just work with iOS, while some require
an external active USB hub and some even don't work with an active hub,
let alone that some software requires Audiobus + MiMix or AUM (without
Audiobus) to access all I/Os of a class compliant audio interface.
;)
1:34 a.m.
On Sun, 14 May 2017 00:50:09 +0200, Moshe Werner
wrote:
PS: It was easy to get a class compliant audio interface that works
with my Linux PC, but a little bit of work to get one that works with my
iPad, too. In my experiences regarding class compliant audio
compatibility, Linux is much better than iOS.
and thanks IOS:)
I'm using Linux and iOS, but I suspect class compliant devices are that
much supported regarding Mac OS and not regarding iOS. Both are Apple
operating systems, but during my tests, before I bought a class
compliant device that works with my iPad, as well as with Linux and
getting in contact with audio device vendors, I noticed that they do
_not_ support iOS. Some devices just work with iOS, while some require
an external active USB hub and some even don't work with an active hub,
let alone that some software requires Audiobus + MiMix or AUM (without
Audiobus) to access all I/Os of a class compliant audio interface.
;)
10:36 p.m.
* list <list(a)contacte.xyz> [2017-05-12 22:07]:
Hello.
Thank you for your report on this 1248.
I've made the report on the ULTRALITE AVB in march.
[http://lists.linuxaudio.org/pipermail/linux-audio-user/2017-March/107629.ht…]
I've finally bought one, and since 1 month, it runs without any
troubles.
I think it's safe to say that the AVB serie (1248 / 624 / ULTRALITE) is
working for Gnu/Linux.
Same thing here. It works thanks to being a class compliant device. I am
having the same issue as others with the first time jackd is started on
that interface it fails, while the second attempt always is successful.
The soundcard mixer is accessible via a browser and ethernet connection.
Motus drivers for windows and osx permit their users to tunnel this
ethernet connection over USB it seems. I have to run a dedicated
ethernet cable to the device in parallel with the usb cable to access
the mixer.
Asking MOTU how they tunnel ethernet over USB did not get me a useful
answer from their side. Perhaps some of the power users from this list
are able to find out if ethernet over usb could work on Linux too?
best, Peter
11:33 p.m.
On Sun, May 14, 2017 at 08:03:34PM +0200, Peter P. wrote:
Asking MOTU how they tunnel ethernet over USB did not
get me a useful
answer from their side. Perhaps some of the power users from this list
are able to find out if ethernet over usb could work on Linux too?
Does 'ip link' show up any new device when the USB is connected ?
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
15 May
15 May
12:42 p.m.
* Fons Adriaensen <fons(a)linuxaudio.org> [2017-05-14 23:33]:
On Sun, May 14, 2017 at 08:03:34PM +0200, Peter P.
wrote:
No, sadly
not.
Asking MOTU how they tunnel ethernet over USB did
not get me a useful
answer from their side. Perhaps some of the power users from this list
are able to find out if ethernet over usb could work on Linux too?
Does 'ip link' show up any new device when the USB is connected ?
13 May
13 May
3:56 a.m.
On Thu, 11 May 2017 21:17:23 +0200
Moshe Werner <moshwe(a)gmail.com> wrote:
To summarize I'm feeling that we are moving in the
right direction
here... I hope other manufacturers will follow and make Interfaces
and software that work with Linux...
A workflow observation: with such an interface a DAW project directory
would also contain the saved EQ, limiter,etc.. parameters from the MOTU
interface. Loading a project would consist of loading the DAW project
then the MOTU parameters. Just thinking aloud, nothing to worry :)
Cheers.
8:51 a.m.
Hi,
IMO we should get used to USB class compliant devices _even without
access to the hardware mixer_. With my new mobo (elCheapo,as well as
the CPU, it's just an Intel(R) Celeron(R) CPU G1840 @ 2.80GHz) I noticed
that even if IRQs are shared with USB and even if it is impossible to
unbind devices, even if IRQs of some components differ with each
reboot, low latency without xruns is provided.
I've got a RME HDEPe AIO PCIe card and a Focusrite Scarlett 2nd Gen
18i20 USB audio interface and get lower latency at 2 Periods/Buffer
(dunno why some are using 3 Periods/Buffer) for the Focusrite USB, than
I get with the RME PCIe card.
I don't had the money to buy a RME class compliant USB device, but
since I've got a job now, I much likely will replace the Focusrite with
a RME USB device.
Ignoring the approach of using an external mixing console for hardware
monitoring, I guess access to the hardware mixer matrix, as well as to
effects of the audio interface isn't really required, if latency is low
enough.
Those using a mixing console don't need to worry about monitoring
latency and access to the audio interfaces hardware mixer at all and
those not using a mixing console should consider that modern PCs with
tendencies to drop PCI slots, come with improved hardware, higher RAM
speed etc., so much likely software monitoring isn't an issue anymore.
2 Cents,
Ralf
2:34 p.m.
Le Sat, 13 May 2017 08:51:31 +0200,
Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> a écrit :
Hi,
IMO we should get used to USB class compliant devices _even without
access to the hardware mixer_.
USB Class compliant doesnt always mean that you can use the hardware.
Some devices comes with all the routing muted, and without the software
from the brand, that work only with Win/Mac. You just have a 3000 $
piece of hardware silence. Happy to find the USB is detected in the
Kernel log though.
Like this one :
https://www.prismsound.com/music_recording/products_subs/atlas/atlas_home.p…
They claiming «This is a UAC2 (USB Audio Class 2) interface supported
natively in Mac, iPad, Linux and Android, and in Windows via a driver. »
But you need their software to make initial routing/control. Or at
least some «alsa mixer» to control it. Does not exist as far as i know.
So, paying 100 % of the price to have 1% of the functionality....or 0%
(perfect silence...)
Focusrite with his series 2i2, 2i4 ( 1st or 2d generation) have
another way to do it : routing is default to everywhere, and you can
control what you want with switchs/buttons and knobs. Very effective,
but limited cards (compared to some Prismsound or Antelope cards) not
so expensive also.
I don't had the money to buy a RME class compliant
USB device, but
since I've got a job now, I much likely will replace the Focusrite
with a RME USB device.
RME as a very special way to do UAC2 - USB Audio Class 2. More an
«RME-ish USB Audio class as i want to do it». Maybe it's enough for
someone's need.
But it's only from my little experience with RME's cards. Sound Devices
have also this problem (USBPRE 2 card) never fully worked (the card
think Linux is windows without ASIO and fallback to 44100 hz only)
From my (small) understanding & knowledges there is only 3 solutions :
(with UAC2 standard respect we all know)
Brands use hardware controls on the card (like Focusrite did with 2ix
serie)
Brands start to produce code in the Kernel/Alsa to have perfect
interface/control of theirs cards.
Brand start to embedded their control softwares in the card that you can
use with a web browser - as MOTU cleverly did.
We know that since begining of age with routers/modems/switchs
why not in audio ?
Let me quote Ardour's dev page about this : «You can thank the brain
dead morons in the audio technology industry for this situation.»
All the best.
2:53 p.m.
On Sat, 13 May 2017 14:36:45 +0200, list wrote:
USB Class compliant doesnt always mean [...]
Apart from Linux audio I tested an USB class compliant Presonus before
I tested and bought the Focusrite.
The Presonus worked with Linux, but not with iOS, while the Focusrite
worked with Linux and iOS. The first issue with the Presonus is too
much power consumption via USB for iOS, but even with an active USB hub
the Presonus didn't work with iOS. To cut a long story short, if a
vendor claims that the audio interface is class compliant, but actually
it isn't, than in civilised nations, it's easy to return the device and
to get the money back. Indeed iOS devices ignore specifications
regarding power consumption, but Linux doesn't. However, iOS couldn't
use the mentioned Presonus device even after being connected to an
active USB hub.
Résumé
At least for 2 USB class compliant audio interfaces I only noticed an
issue with my iPad 2 (an absolutely outdated iPad) but even not with my
old Linux PC, a mobo and CPU much, much, much older than the iPad 2.
15 May
15 May
7:59 a.m.
On 05/12/2017 11:51 PM, Ralf Mardorf wrote:
Hi,
IMO we should get used to USB class compliant devices _even without
access to the hardware mixer_.
In some cases that is all you need[*].
In the case of the Motu 16A/24Ai/24ao/etc the web interface makes them
usable for my purpose. Without that, you would need to initialize the
interface with a different operating system. And you would not be able
to use the internal routing matrix, and/or multiple devices
interconnected through AVB. So it is not optional and not having access
to the internals would make the device useless.
With my new mobo (elCheapo,as well as
the CPU, it's just an Intel(R) Celeron(R) CPU G1840 @ 2.80GHz) I noticed
that even if IRQs are shared with USB and even if it is impossible to
unbind devices, even if IRQs of some components differ with each
reboot, low latency without xruns is provided.
Good for you. I did not notice any big problems either. But I'm using
this in concert performance situations, with the interfaces driving a
24.8 speaker array for 3D sound. I tried to minimize the chance of
random interactions between peripherals.
Also, I found upping the IRQ priority for the USB subsystem to be
essential for good performance. As the USB priority is very high for the
soundcard I would rather not have the mouse and other stuff running at
that priority.
-- Fernando
[*] and sometimes it is tricky. We got some Tascam 4x4 for four channel
use - the default setup folds over the "back" channels to the front so
that (I guess) monitoring works. Not what we needed. The only way to fix
that was to initialize the setting on a Mac.
13 May
13 May
9:34 p.m.
On Fri, 12 May 2017 21:56:37 -0400
jonetsu <jonetsu(a)teksavvy.com> wrote:
A workflow observation: with such an interface a DAW
project directory
would also contain the saved EQ, limiter,etc.. parameters from the
MOTU interface. Loading a project would consist of loading the DAW
project then the MOTU parameters. Just thinking aloud, nothing to
worry :)
I think I would still mix using Ardour/Mixbus, and in the case of
Mixbus32C which I use, benefit from the Harrison 32C EQ hardware
emulation. The MOTU will add another type of EQ emulation (like a
plugin would) based on British consoles, as well as the LA-2A limiter
(also considered as a 'plugin'). So, for Mixbus32C-based mixing, the
MOTU will add those 'plugin' features. And the initial routing. If a
track feels better with British-based EQ, then so be it. If it feels
better with 32C, so be it. There's also reverb on the MOTU which would
be considered as a 'plugin' also. Use it, or use any other reverb. So
it's an audio interface with audio processing capabilities which may or
may not be used.
Still just thinking aloud ... :)
Cheers.
9:56 p.m.
On Sat, 13 May 2017 15:34:44 -0400, jonetsu wrote:
I think I would still mix using Ardour/Mixbus, and in
the case of
Mixbus32C which I use, benefit from the Harrison 32C EQ hardware
emulation. The MOTU will add another type of EQ emulation (like a
plugin would) based on British consoles, as well as the LA-2A limiter
(also considered as a 'plugin'). So, for Mixbus32C-based mixing, the
MOTU will add those 'plugin' features. And the initial routing. If a
track feels better with British-based EQ, then so be it. If it feels
better with 32C, so be it. There's also reverb on the MOTU which would
be considered as a 'plugin' also. Use it, or use any other reverb. So
it's an audio interface with audio processing capabilities which may or
may not be used.
Still just thinking aloud ... :)
Hi,
it doesn't harm to get everything provided by the audio interface, but
it's luxury we not necessarily need. IMO it's not worth the effort to
waste time with research to get the best supported audio interface, if
it takes less time to ensure that the device works without issues in
class compliant mode, with reasonable latency, even for usage with
software monitoring. More important IMO is to ensure that the
electronics fulfils the required quality standard. IOW a RME audio
interface with the latest and greatest RME hardware mixer software is
welcome, but even without the oldish hdspmixer, IOW without a mixer at
all, a class compliant RME audio interface provides all that is
absolutely necessary, assuming it should work in class compliant mode
without issues. Regarding an EQ I've got no idea what Fons' or Robin's
parametric EQs are missing. Regarding a reverb software indeed is
tricky, even if the quality should be good, it might take to much
system resources, but instead of getting an audio interface with an
integrated reverb, I simply would purchase a separated reverb.
2 Cents,
Ralf
10:11 p.m.
On Sat, 13 May 2017 21:56:37 +0200
Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> wrote:
Gruß,
Regarding an EQ I've got no idea what Fons' or
Robin's
parametric EQs are missing.
Well, this we went on about some time ago. Hardware EQs have
character. Their circuitry 'bends' in one way or the other depending on
the load, perhaps even adding harmonic distortion in any which way. In
Linux world the OvertoneDSP Pulltec emulations are certainly very
different from Robin's x42 EQ (which I also use as a subtractive EQ)
and is even very different from OvertoneDSP's own AFM210 graphical EQ.
Likewise, the Harrison Mixbus32C EQ was modelled after their 32C
consoles. In those times consoles meant something for character. Some
people preferred to mix on a certain type for the characteristics they
can add to a mix, which was not always defined in logical terms. It
was a feeling, a certain warmth. Perhaps much like a fuzzbox for
guitar and another fuzzbox: each has its own way.
Regarding a reverb software indeed is
tricky, even if the quality should be good, it might take to much
system resources, but instead of getting an audio interface with an
integrated reverb, I simply would purchase a separated reverb.
System resources is a good point. Having reverb processing offloaded
to hardware could be beneficial. The same would be valid for the EQ
emulation provided by the MOTU.
10:24 p.m.
On Sat, 13 May 2017 16:11:44 -0400, jonetsu wrote:
Ok, the discussion about emulating discrete analog circuits is
off-topic. I get your point, but I disagree.
On Sat, 13 May 2017 21:56:37 +0200 Ralf Mardorf wrote:
Gruß,
:)
Regarding an
EQ I've got no idea what Fons' or Robin's
parametric EQs are missing.
Well, this we went on about some time ago. Hardware EQs have
character. System resources is a good point. Having reverb
processing offloaded
to hardware could be beneficial. The same would be valid for the EQ
emulation provided by the MOTU.
I guess EQs aren't resource hungry, but maybe emulating unwanted phase
issues and unwanted crackles of dirty potentiometers takes much
resources :p.
Grüße
Ralf
14 May
14 May
12:56 a.m.
On Sat, May 13, 2017 at 9:56 PM, Ralf Mardorf <ralf.mardorf(a)alice-dsl.net>
wrote:
On Sat, 13 May 2017 15:34:44 -0400, jonetsu wrote:
As I tend to agree with you on the fx side of things, the routing on the
1248 is a rather powerful tool that I would not like to miss.
Actually when I needed to decide on whether to go with the fireface 802 or
the Motu this was the feature that made me go for the Motu...
Having the ability to control the device and all of it's features makes
life so much better;)
Best
Moshe
I think I would still mix using Ardour/Mixbus, and
in the case of
Mixbus32C which I use, benefit from the Harrison 32C EQ hardware
emulation. The MOTU will add another type of EQ emulation (like a
plugin would) based on British consoles, as well as the LA-2A limiter
(also considered as a 'plugin'). So, for Mixbus32C-based mixing, the
MOTU will add those 'plugin' features. And the initial routing. If a
track feels better with British-based EQ, then so be it. If it feels
better with 32C, so be it. There's also reverb on the MOTU which would
be considered as a 'plugin' also. Use it, or use any other reverb. So
it's an audio interface with audio processing capabilities which may or
may not be used.
Still just thinking aloud ... :)
Hi,
it doesn't harm to get everything provided by the audio interface, but
it's luxury we not necessarily need. IMO it's not worth the effort to
waste time with research to get the best supported audio interface, if
it takes less time to ensure that the device works without issues in
class compliant mode, with reasonable latency, even for usage with
software monitoring. More important IMO is to ensure that the
electronics fulfils the required quality standard. IOW a RME audio
interface with the latest and greatest RME hardware mixer software is
welcome, but even without the oldish hdspmixer, IOW without a mixer at
all, a class compliant RME audio interface provides all that is
absolutely necessary, assuming it should work in class compliant mode
without issues. Regarding an EQ I've got no idea what Fons' or Robin's
parametric EQs are missing. Regarding a reverb software indeed is
tricky, even if the quality should be good, it might take to much
system resources, but instead of getting an audio interface with an
integrated reverb, I simply would purchase a separated reverb.
2 Cents,
Ralf
2750
days inactive
2754
days old
linux-audio-user@lists.linuxaudio.org
42 comments
11 participants
participants (11)
-
Anders Hellquist -
Bearcat Şándor -
Fernando Lopez-Lezcano -
Fons Adriaensen -
jonetsu -
Len Ovens -
list -
Lorenzo Sutton -
Moshe Werner -
Peter P. -
Ralf Mardorf