tl;dr: Has anyone figured out a convenient, reliable way to setup MOTU
AVB series interfaces?
Hi, I recently got a MOTU Ultralite AVB to replace my RME Babyface Pro.
RME advertise the Babyface Pro as working with Linux without proprietary
drivers and because all essential functions can be controlled directly
from the device, but that is not true. It is not possible to directly
monitor a mono input on both sides of a stereo output. It is possible to
hack around this with Y splitter cables on the inputs, but that's clunky
and halves the number of available inputs. I contacted RME about this
and pointed out an unused button on the device that could be used for
toggling mono/stereo direct monitoring with a firmware update, but they
did not care. It seems they only care about their own use cases, namely
iOS. Apparently they can't be bothered to make minor changes for Linux
users but are happy to misleadingly advertise Linux compatibility.
So I got a MOTU Ultralite AVB to replace the RME Babyface Pro. The sound
quality is on par with the Babyface Pro but the Ultralite AVB has more
I/O and features for a lower cost (although if recording guitar is
important for you, IMO the Babyface Pro's instrument inputs sound
clearer than the Ultralite AVB -- but keep in mind the direct monitoring
issue). The Babyface Pro has some quirks when using it with GNU/Linux
(which I think are caused by the 2 channel mode it has for iOS), but the
Ultralite AVB has different quirks.
As discussed on this list previously, there are some oddities trying to
set the Ultralite AVB's sample rate. This seems to cause some issues
with PulseAudio. If I start PulseAudio with the Ultralite AVB plugged
in, it works briefly but randomly drops out. When I plug in the
Ultralite AVB after PulseAudio is started, it does not appear as an
output for PulseAudio and I see this in PulseAudio's output:
E: [pulseaudio] module-alsa-card.c: Failed to find a working profile.
E: [pulseaudio] module.c: Failed to load module "module-alsa-card"
(argument: "device_id="1"
name="usb-MOTU_UltraLite_AVB_0001f2fffe005a12-00"
card_name="alsa_card.usb-MOTU_UltraLite_AVB_0001f2fffe005a12-00"
namereg_fail=false tsched=yes fixed_latency_range=no ignore_dB=no
deferred_volume=yes use_ucm=yes
card_properties="module-udev-detect.discovered=1""): initialization failed.
Occasionally I also see this in the output when I start PulseAudio with
it plugged in already. This seems to appear randomly and is not
correlated with PulseAudio output dropping out:
E: [alsa-sink-USB Audio] alsa-sink.c: ALSA woke us up to write new data
to the device, but there was actually nothing to write.
E: [alsa-sink-USB Audio] alsa-sink.c: Most likely this is a bug in the
ALSA driver 'snd_usb_audio'. Please report this issue to the ALSA
developers.
E: [alsa-sink-USB Audio] alsa-sink.c: We were woken up with POLLOUT set
-- however a subsequent snd_pcm_avail() returned 0 or another value <
min_avail.
Sometimes it looks like PulseAudio tries to set the Ultralite AVB to a
different sample rate. I sometimes notice the LCD display on the
Ultralite AVB showing 192 kHz when PulseAudio tries to use it. I tried
setting this in /etc/pulse/daemon.conf:
default-sample-rate = 44100
but it made no difference.
So I have tried using JACK regularly with the PulseAudio to JACK bridge.
Unfortunately this has some quirks too. JACK won't start unless I wait
several seconds after plugging in the Ultralite AVB. If the Ultralite
AVB is plugged in when I boot up and log into KDE, QJackCtl autostarting
JACK doesn't work. I think this is because PulseAudio tries to grab the
device before JACK starts. I have to wait a few seconds and manually
start JACK. If the Ultralite AVB's firmware is set to a different sample
rate than JACK is configured for, JACK won't start.
Has anyone contacted MOTU about the sample rate switching issue? Ideally
they could make it just work when the computer tells the audio interface
to switch sample rates.
Also, has anyone contacted them about possibly changing the firmware so
the web interface is available over USB on Linux? I think if they used
the RNDIS Ethernet-over-USB protocol that Android uses for tethering it
could be plug-and-play with Linux. Or has anyone started working on a
custom driver to make this work? In the meantime I got a cheap little
GL-MT300A router ( http://www.gl-inet.com/mt300a/ ) to use the web
control interface away from my home network. It's neat. :)
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
https://lists.linuxaudio.org/listinfo/linux-audio-user
