Posted: 2020-02-02 | Tags: Linux (blog/tags/Linux), audio (blog/tags/audio), hardware (blog/tags/hardware), review (blog/tags/review),

software (blog/tags/software)
Updates:
• 2020-12-21 Add Ubuntu 20.04.1 LTS and RT audio info; some tidying up.
• 2020-08-31 Add note about xed duplex sound support.
• 2020-06-06 Add note about systemd and realtime audio.
• 2020-04-13 Add more Linux compatibility tests and notes.
• 2020-03-31 Add note about switching the sample rate.

Motu M4 review
With measurements and Linux notes
I updated my computer (site/posts/2020-02-02_motu_m4/../../../posts/2021-04-05_updating_pc)
at the end of year 2019. As new motherboards don't have a PCI bus anymore, I had to give up my
ESI Juli@ and look for a replacement. Motu had just released the M2 and M4 USB audio interfaces
in November. They seemed to o er superb sound quality in a nice package. I wanted a device
which is class-compliant and bus-powered, and the M4 t the bill nicely. It took quite a few weeks
for the device to arrive, as apparently it's been hugely popular. No wonder why, as you'll soon nd
out. In this review I skip microphone recording tests, as there are already many review videos on
YouTube addressing that speci c area. This review is more about the outputs and Linux
compatibility.

The Motu M4 front panel. All the knobs feel really nice and sturdy.
(site/posts/2020-02-02_motu_m4/motu_m4.jpg)

Speci cations and notes

Here are some speci cations I haven't found anywhere else online, but which I've checked from the
manufacturer:
DAC: ES9016 SABRE32 Ultra DAC
(http://www.esstech.com/ les/3614/4095/2153/ES9016S_PB_rev_1.7_140916.pdf)
ADC: AKM AK5554VN (https://www.akm.com/kr/ko/products/audio/audio-adc/ak5554vn/)
(AKM AK5552VN (https://www.akm.com/kr/ko/products/audio/audio-adc/ak5552vn/) for
M2)
Preamp: THAT Corp 6263 preampli er
(http://www.thatcorp.com/626x_Dual_Programmable_Preamp_ICs.shtml)
The chips are of superb quality. For example, the ESS DAC has a THD+N of -110 dB and the AKM
ADC -106 dB respectively. For rest of the M4 specs, see the o cial Motu site (https://motu.com/en-
us/products/m-series/m4/specs/).
The ES9016 is an 8-channel DAC. The M4 has four output channels and I guess two more channels
are used for the headphone output. Not sure if there are 2 unused channels or if they are used
somehow internally. Possibility for a digital input, anyone? The preamp chips are stereo, so for a 4-
channel model there must be multiple of those. Already simply the cost of the high-quality chips
inside the M4 is considerable, even if the M4 itself is considered a ordable.
Some things I've noticed during use and measuring I think are worth mentioning:
Turning on monitoring for an input channel has no impact on the sound quality of the channel.
The input monitor mix potentiometer is only in use when there's something to monitor.
Line out channels 3/4 are xed volume and there's no monitoring out of them, i.e. they are
"DAC only".
The headphone output plays back channels 1/2, which are also the monitor channels.
When the monitor volume is at maximum, quality-wise the monitor line out channels 1/2
produce output identical to the xed DAC channels 3/4.
The main monitor volume potentiometer controls the volume digitally by 1 dB intervals. The
headphone volume potentiometer works similarly.
The input monitor mix potentiometer is also digital. If playing only from playback, from 12:00
o'clock onwards the potentiometer changes the volume in 0.05 dB intervals, until after 3:00
o'clock the interval changes to 0.03 dB. Going counterclockwise from 12:00, the interval is 0.75
dB, then 1.5 dB and eventually 2.5 dB and more. In any case, it is very accurate for all intents
and purposes.
As a class-compliant device, the M4 is seen as a 4-channel asynchronous device on Linux.
The device has no controls in alsamixer. The loopback feature is only available in
Windows/Mac with the special driver. You can have exclusive access to just the inputs or just
the outputs at the same time, but you have to use all 4 channels at a time. Update 2020-08-31:
with kernels older than 5.8, full-duplex (simultaneous input/output) requires the use of JACK;
pure ALSA and PulseAudio will not work in full-duplex mode. The issue is xed with newer
kernels.
Windows couldn't seem to use the device without the special driver. I don't know if Windows
supports 4-channel devices out of the box. After installing the Motu driver, the M4 is seen as
two stereo devices.
You can see the monitor volume potentiometer changing the RMS signal level by 1.0 dB interval in
the video below. For comparison, I also added an analog potentiometer to the signal path.
 0:17 / 0:17

A very nice thing about digitally controlled volume is that the channel balance and frequency
response are not volume-dependent. As my Klipsch RF-63 loudspeakers have a sensitivity of 99 dB
@ 2.83 V / 1 m, it is critical to have a very high-quality volume potentiometer. The Motu M4 provides
one.

Measurements
Even though I use the device almost exclusively in Linux, for measuring I booted my PC to
Microsoft Windows 10 Pro. The measurement software I used was ARTA version 1.9.3 Update 1 by
Artalabs (http://www.artalabs.hr/).

Setup
 The calibration was done using a voltmeter between the balanced
connection tip and sleeve.
(site/posts/2020-02-02_motu_m4/setup_calibration.png)
For a rst-timer in ARTA software, the amount of things hidden behind option dialogs can be a bit
confusing. I checked the voltmeter values from the balanced line out connection between the tip
and sleeve. I didn't calibrate per-channel, but assumed they are identical, as they should be.
In the Audio Devices Setup dialog I selected the 24-bit Wave Format for all the measurements,
unless otherwise mentioned. Note: I was using the WDM drivers as ARTA didn't work correctly with
the special drivers in all situations. I made sure the Windows mixer wasn't doing anything stupid in
the background, though, by setting all the Windows settings to 44100 Hz, 24-bit with volume levels
maxed out.
In the Generator Setup for Continuous Signals dialog I had the default Dither Level of 16-bit and
signal level of -3 dBFS. For the nal, best THD+N measurement I selected 20-bit Dither Level (which
gives results identical to no dither at all) and pumped up the signal level to -1 dBFS.
For other dialog settings I used the defaults. All the main window settings (such as FFT length and
window function) are visible in the screenshots.

Cable setups
I tried a bunch of di erent cables both for balanced and unbalanced connections. For balanced
connection I had one self-made short cable with the Cordial CMK 222, a couple of longer self-
made ones with the Sommercable Goblin, and a couple of cheap sssnakes from Thomann. They all
had similar results and therefore I guess my cables are good enough.
 These three di erent cables yielded practically
identical results.
(site/posts/2020-02-02_motu_m4/interconnect_cables.jpg)

The simplest balanced connection setup, used in

distortion measurements.
(site/posts/2020-02-02_motu_m4/setup_cables_balanced.jpg)

An unbalanced connection setup. The quarter-inch

plugs are of TRS type and the ring is not connected.
(site/posts/2020-02-02_motu_m4/setup_cables_unbalanced.jpg)

Harmonic distortion, noise

I started with the default setting of 16-bit Wave Format, but quickly realized it's probably not what I
want when we are talking about numbers around -100 dB.
(site/posts/2020-02-02_motu_m4/results_bal_out_bal_in_16bit.png)
(site/posts/2020-02-

(site/posts/2020-02-02_motu_m4/results_bal_out_bal_in_16bit.png)
Balanced out to line in. 16-bit Wave Format.

Balanced out to line in. 24-bit Wave Format.

02_motu_m4/results_bal_out_bal_in_24bit.png)
Moving up to 24-bit Wave Format the harmonics become visible from the noise, along with THD+N
dropping from 0.0046 % to 0.0018 %, or -95 dB approximately.
There's only very little quality
loss when using the
unbalanced out, connecting
just the tip and sleeve of the
balanced in TRS connector.
THD+N is about -93.5 dB.
I was wondering about the -95
dB THD+N gure of the
balanced loopback
measurement but then I
realized I was using 16-bit
Dither Level. Selecting 20-bit
Unbalanced RCA out to line in.
dithering and raising the signal
level to -1 dBFS from the (site/posts/2020-02-02_motu_m4/results_rca_out_bal_in.png)
default -3 dBFS, I measured a
THD of 0.00050 % and a THD+N of 0.00069 %. These are roughly equal to -106 dB and -103 dB
respectively. Considering there's both a DAC and an ADC (with a THD+N of -106 dB), the measured
values are very close to the theoretical limits of the specs and thus extremely good.
When monitoring is on, with
the input monitor mix
potentiometer set exactly to
middle (12:00 o'clock), THD+N
rises 1 dB. I think it's safe to say
that monitoring has no e ect
on the sound quality.

Best THD+N gure measured. Balanced out to line in. 24-bit

wave, 20-bit dithering, -1 dBFS signal level.
(site/posts/2020-02-02_motu_m4/results_thdn.png)

Frequency response
While measuring the frequency response I had the unbalanced RCA monitor outputs connected to
the line inputs. The frequency response was extremely at.
(site/posts/2020-02-02_motu_m4/results_fr_max_vol_rca_bal.png)
(site/posts/2020-02-

(site/posts/2020-02-02_motu_m4/results_fr_max_vol_rca_bal.png)
Frequency response is extremely at. Monitor volume set to
max.
 Frequency response stays at with lower volume levels.
Monitor and input mix volumes set to midway (12:00 o'clock).

02_motu_m4/results_fr_mid_vol_rca_bal.png)
I also tested how the frequency response behaved if setting the monitor output levels to something
much lower volume. With both the main monitor volume and input monitor mix volume set at 12:00
o'clock, there was hardly any di erence. If the signal level is anything greater than about -60 dbFS,
the frequency response stays practically at, i.e. easily within +-0.2 dBFS between 10 Hz and 20 kHz.
I also checked the channel balance at low volume levels. It was practically perfect as was
expected, only a 0.25 % di erence could be distinguished.

Channel balance was practically perfect in all situations.

(site/posts/2020-02-02_motu_m4/results_fr_mid_vol_rca_bal_lr.png)

Latency
An important thing for music producers, especially if you are playing any instrument via your PC,
the less latency there is, the better.
I measured latency in Linux using JACK (https://jackaudio.org/) and Audacity
(https://www.audacityteam.org/). I chose the best values I deemed stable with 96000 Hz sampling
rate: 64 frames per period, 6 periods per bu er. In theory, this will yield an input latency of 64/96000
s = 0.67 ms and an output latency six times that, or 4 ms .

I created a short square-wave signal which I then played out via the line out and looped it back into
the line in.
 The delay between playback starting and the rst non-zero recorded value
was 6.49 ms, or approximately 6.5 ms.
(site/posts/2020-02-02_motu_m4/results_latency.png)
Measuring from the recorded result the Round Trip Latency (RTL) at 96 kHz is 6.5 ms, which I think,
for a class-compliant USB audio interface with no special drivers at all, is amazing. This means that
the latency from USB bus and M4 internals combined is around 1.83 ms, which sounds about right
for a USB device.
Now, if we took that 1.83 ms as a reference and added to that twice (for output and input) a bu er of
32 samples at 96 kHz, or 0.33 ms, we'd have an RTL of exactly 2.5 ms. That is the RTL that Motu
advertises when using the special Windows or Mac drivers, and seems very plausible. With JACK
the output latency is always bigger than the input latency and so the RTL is a bit higher also.
For 48 kHz operation, I managed to get a stable 12.5 ms RTL. The smallest latencies I was able to
achieve using JACK, in theory, was at 192000 Hz with 64 frames per period, 7 periods per bu er.
This resulted in an RTL of 4.5 ms at 192 kHz, but I did not test how stable this would be in the long
run. While trying out di erent settings, any smaller latency and JACK would just output XRuns
(bu er overruns or underruns) constantly. Nevertheless, these are extremely small numbers. You
might have 99 problems while recording, but with the M4 latency ain't one.

For comparison
I have an old dedicated DAC which I now keep connected to the monitor inputs of the M4. That way
I can keep the M4 a dedicated soundcard for Hi-Fi use. The device in question is the Pop Pulse
Super Pro 707 24-bit/192kHz DAC (http://www.itemaudio.co.uk/superpro_dac.html). It uses the
Cirrus Logic CS-4398 (https://www.cirrus.com/products/cs4398/) DAC chip, which has very good
speci cations, including a THD+N of -107 dB.
The DAC sounds very good and has hardly any
audible noise. What's funny are the
measurements. First I connected the outputs of
the 707 to the inputs of the M4. The THD+N
gures were orders of magnitude greater
immediately (over -80 dBFS), but there's no way
even these could be heard, at least not with the
noisy ampli er I have at the moment. I also did
an extra loopback run so that the signal rst
went from 707 to M4, then from M4 to itself via
monitoring. The THD rose a mere 0.32 dB, and
THD+N 0.76 dB. Those are such small numbers
I'm pretty sure they might be gone on a
di erent day and room temperature. That's how
clean the M4 is.
(site/posts/2020-02-
02_motu_m4/results_707_out_bal_in.png)
(site/posts/2020-02-
02_motu_m4/results_707_out_bal_in_loop.png)

The Super Pro 707 is a simple, compact DAC.

(site/posts/2020-02-02_motu_m4/superpro.jpg)

(site/posts/2020-02-02_motu_m4/results_707_out_bal_in.png)
Super Pro 707 DAC to M4.

Super Pro 707 DAC to M4, looped back to M4.

Linux setup and notes

All my audio con g les are available in my dot les repository (https://github.com/ohel/dot les) at
GitHub, but I've linked them here as they currently are. I use a generic, abstract ALSA con g
(site/posts/2020-02-02_motu_m4/asound.conf) along with another, system-speci c con g le
(site/posts/2020-02-02_motu_m4/minigun_alsa_devices_m4.conf), which de nes the actual
devices and hence also contains the M4 de nitions. The M4 has no controls in alsamixer. When you
access the input or output, you have to use all 4 channels. This means you might need to de ne
some virtual devices for stereo operation depending on how you access the device.
The current status of realtime audio with Linux is a bit obscure. Back in the days I used to re up the
RT-patched kernel when I needed low-latency audio. Everything worked perfectly. Now, with the
mainline kernel going at version 5.5, the RT kernel is stuck at version 4.19 rendering it unusable with
modern hardware.
How to achieve realtime audio nowadays works by setting up PAM limits for a group or user. For
example, I've put the following con g in /etc/security/limits.d/50-audio-realtime.conf :

@audio - rtprio 70
@audio - memlock 16777216
@audio - nice -10

I've also set up sudoers so that I may renice processes without a password. Now, when my user is
in the audio group, I can start an audio application and renice it to have high priority. Without giving
those security limits for PAM, JACK complains if you try to run it in realtime mode. 2020-06-06 note:
according to JACK documentation (https://jackaudio.org/faq/linux_rt_con g.html), the niceness
has no e ect on realtime audio.
To see processes started by you and having RT priority, use $ ps -LeO rtprio (from the
comments: -L , the show threads switch, is usually needed to see the RT priorities). I am also using
rncbc's rtirq script (https://github.com/rncbc/rtirq), but I have no idea whether it has any e ect
without the RT kernel.
In any case, with the above set up, after starting JACK and renicing it to -10, I get realtime audio
with low latencies. I try to test all setups for XRuns before actually using them. Take for example the
setup I got the 96000 Hz low-latency result with. I left it running overnight, with mhWaveEdit
(https://github.com/magnush/mhwaveedit) listening to inputs, and an ALSA/JACK bridge routing
music from a media player to the outputs. In a real recording situation the loads might be very
di erent, but at least there was some data moving.
I've tested these three JACK setups and
they work very nicely:

Duplex 48000 Hz, output latency 8 ms

Frames/Period: 128
Periods/Buffer: 3

Duplex 96000 Hz, output latency 4 ms

Frames/Period: 64
Periods/Buffer: 6

Playback 44100 Hz, output latency 2.9 ms

Frames/Period: 32
Periods/Buffer: 4

2020-03-31 note: At rst I thought my USB

port was going to sleep after some time, To test stability for XRuns, a JACK setup was left
but the usbcore.autosuspend=0 kernel running overnight with some audio load.
option didn't help. It took a few seconds (site/posts/2020-02-02_motu_m4/setup_linux.jpg)
for the audio to "wake up". I realized that
the "USB going to sleep" is actually the device just resetting the sample rate. If I change the sample
rate on the y, it takes a few seconds for the Motu M4 to start playing audio with the new setting.
There are usually no weird cracks or pops, but there might be one right after you initiate the switch
if you have some audio playing. After that the audio is muted for around ve seconds. Then the
volume is ramped up back to normal, so no pops will occur this time. This is good to keep in mind if
you are for some reason going to switch the sample rate all the time.

How does it sound?

I haven't noticed any great di erence with my loudspeakers compared to all my previous Hi-Fi
setups. I guess that means the sound is very transparent and neutral, as is expected from the
measurement results. I probably will appreciate the absence of noise more when I have time to
upgrade my temporary power ampli er, as it's now hissing a bit even if it otherwise sounds really
nice.
The headphone output is very di erent to what I'm used to, though. I've been playing electric
drums for a few months now, and I was accustomed to how they sounded. I played with the KZ
ZST Colorful earbuds. As the headphone ampli er I used the CME Matrix X, a device with very
good speci cations. Both my AKG K701 and KZ ZST sounded very nice from the CME.
Now, when I switched to the Motu M4, I had to tweak my drum sounds. The bass was so loud it was
almost painful to play the kick drum or oor tom. With the KZ ZST the bass department is much
stronger than anything I've heard. I was intrigued whether the AKG K701 would receive a similar
boost to its bass, as it can be just a tad lacking. However, I was surprised to nd out the answer is no
- in fact, it might be exactly the opposite, but that might be just placebo. The KZ ZST supposedly
has a slightly stronger than average bass response, but this was the rst time it became evident
and I've had them over a year.
In short, the headphone output will probably sound really good, but it seems you need both the
headphones and the ampli er to match for that perfect sound, so your mileage may vary.

Conclusion
I've been super satis ed with the new computer I assembled. The one part that felt troublesome to
nd was a new, a ordable audio interface. Luckily Motu had just released the M4. The only thing I
would love to have is a digital input. Other than that, I couldn't wish for more from the M4.
Pros:
Feels well-built.
Class-compliant operation, so works in Linux.
Powered by USB bus.
Extremely good speci cations.
The speci cations also deliver in practice.
The potentiometers a ect digitally so there's no quality loss, but they have analog knobs so
they still feel nice.
Very low latency for a USB device.
Cons:
Any chance of adding a digital input?
Would be nice to have two stereo devices instead of one 4-channel device, but I'm not sure if
it would be class-compliant anymore.
 Manufacturer apparently has little history with Linux, so some details are kind of hard to nd. I
hope this review article clears things out for other Linux users out there.
Update 2020-08-31: Full-duplex with Linux requires JACK before kernel 5.8, but works
normally nowadays. See the xing commit
(https://github.com/torvalds/linux/commit/10ce77e4817fef99e1166be7e6685a80c63bf77f#di -
aba21fac395f457b2f223b8f36e4bde1).
If you need an audio interface, just buy the Motu M4 or M2.

This Moroccan sunset has nothing to do with anything, I just wanted a separator for the article
update. 😁
(site/posts/2020-02-02_motu_m4/sunset_silhouette.jpg)

2020-04-13 update: more Linux compatibility testing

Thanks to the comments section it was brought to my attention that the M4 (and M2) might not
actually be very compatible with current Linux systems. There are three things I'd like to discuss:
the sampling rate switching delay, the implicit feedback thing preventing full-duplex operation, and
compatibility with older systems.

Sampling rate switching delay

In my last update I explained there is a delay of about ve seconds when switching sampling rate.
To nd out whether this was just a Linux-speci c problem, I tried to reproduce the e ect in
Microsoft Windows 10.
In ARTA - the measurement software I used - when using the device in exclusive mode (by
selecting the device directly as output and not through WDM), if I change the sampling rate there
will be the same 5 second muted delay. In fact, ARTA will crash right after changing the sampling
rate, but if you have two instances running, you can observe the 5 second delay with the other
instance. This I think implies that the 5 second delay is indeed a hardware feature and the "default"
behaviour.
However, in the Windows audio device properties dialog there is the Advanced tab, where the
Default Format setting resides. It controls the sampling rate of the system mixer. After selecting a
new sampling rate and clicking Apply, the change seems quite immediate without the 5 second
delay, but all audio must be stopped when doing the change. This hints that there is a feature in the
Windows drivers which are able to set the new sampling rate without the delay, or with only a little
delay. So, all the unicorns at MOTU, please reveal the open source community your secrets!

Full-duplex operation not working (for kernels older than 5.8)

Note 2020-08-31: with kernels from 5.8 onwards (anything from August 2020 or newer) the full-
duplex mode works as intended; see the xing commit
(https://github.com/torvalds/linux/commit/10ce77e4817fef99e1166be7e6685a80c63bf77f#di -
aba21fac395f457b2f223b8f36e4bde1). This section thus only concerns systems with older kernels.
Keywords: motu m4 m2 no output sound linux
This one came to me as a total surprise, but it is true in most cases. Trying to play back audio and
recording at the same time will fail - it will also probably mute the output of the Motu M4, resulting
in the assumption the device is not working at all. What's more, you don't even have to try the
playback and recording explicitly: it is enough to run a default (Ubuntu) installation of PulseAudio
server to jam the device!
I never stumbled upon the issue during my review since I don't use PulseAudio. If I do recording, I
use JACK. I tried directly with ALSA, and I get the same issue as with PulseAudio. So the problem is,
according to forums on the Internet, that the device needs something called implicit feedback - a
feature which ALSA does not support, at least not yet. What's funny is that JACK obviously uses
ALSA to access the hardware and it works perfectly. Apparently it somehow opens the device
di erently. The Linux audio stack always was a bit of a mystery and I've seen random stu happen
with ALSA in the past, so I guess I'm not that surprised. Although, I have to say: the device didn't
work in Windows without the drivers, so maybe the device rmware is missing something even if it
is supposedly class-compliant?
If you are trying to use the M4/M2 just once in duplex mode using PulseAudio, it might mute the
output for good until restart. And, if you have PulseAudio running by default, it will jam the output
automatically. A very brute force test for this is to do as follows - you may also just disable the
PulseAudio service, but this is bomb-proof:

$ sudo mv /usr/bin/pulseaudio /usr/bin/pulseaudio_disabled

$ sudo shutdown -r now # Reboot the computer and open the terminal when you're logged back in. Reconnect the M
4/M2.
$ speaker-test -D hw:M4 -r 44100 -c 4 -F S32_LE

Assuming you don't have any other sound server running, you should have test tones playing via
your device. So the device works, but full-duplex doesn't. The solution is to use JACK for duplex
mode. See the next section.
Also note that, even though you might not be getting any output at all, the input does work all the
time. You can even see the input level monitor in PulseAudio volume control working normally.
This might also explain why I wasn't able to get ARTA working without the WDM driver during my
initial tests. It might well be that the same thing that's preventing full-duplex mode from working in
Linux actually also a ects Windows when the device is in exclusive mode without WDM driver, but
I can't tell for sure.

Compatibility with older systems and kernels

Note 2020-08-31: with kernels from 5.8 onwards (in practice anything from August 2020 or newer)
the full-duplex mode works as intended and thus also PulseAudio works; see the xing commit on
GitHub
(https://github.com/torvalds/linux/commit/10ce77e4817fef99e1166be7e6685a80c63bf77f#di -
aba21fac395f457b2f223b8f36e4bde1).
I tested the Motu M4 using two di erent laptops with the following con gurations:
 Xubuntu 19.04 with kernel 5.0.0-38-generic. Laptop: Asus UX305CA (about 4½ years old).
Xubuntu 18.04.4 LTS with kernel 4.15.0-96-generic. Laptop: Lenovo T480 (about 1½ years old).
The results were identical with them. At rst, the audio wouldn't work. I disabled PulseAudio as I
instructed in the previous section and the audio worked. So, for basic operation, even the older
kernel versions seem to be ne. Some people say, to work at all, the Motu M4 needs some kind of
patch (https://mailman.alsa-project.org/pipermail/alsa-devel/2020-January/161264.html). This
boot quirk patch was applied in kernel 5.6, and also backported to older versions, apparently at
least starting from 5.4.22. I've now tested the Motu M4 with three di erent systems and I haven't
noticed any di erence between kernels ranging from version 4.15.0 to version 5.6.3, but your
mileage may vary. Also granted, I haven't tested but a few minutes with the laptops.
As a workaround for now, to get both the input and output working simultaneously using
PulseAudio, I suggest doing the following (instructions are for Ubuntu):
1. Disable PulseAudio from autostart. It's probably a systemd service nowadays.
2. Install JACK.
3. Install PulseAudio module for JACK: $ sudo apt install pulseaudio-module-jack
4. Edit /etc/pulse/default.pa and add these lines:
.nofail
load-module module-jack-source channels=2
load-module module-jack-sink channels=2
.fail

5. Restart your system.

6. Connect your Motu. Start JACK using the Motu, and start PulseAudio.
This would make audio work as before, but to access the Motu from PulseAudio you'd select the
JACK sink/source. Now also the full-duplex mode works. That example above creates just a stereo
device, tweak the amount of channels if you need to.
I'm not running PulseAudio by default on my main computer, but might still need it for video
conferencing or something, so I created PulseAudio con gs which I uploaded
(https://github.com/ohel/dot les/tree/master/con gs/pulse) to GitHub. They include a
convenience script for ring up both JACK and PulseAudio.
Under the Linux setup and notes section I added an update concerning Ubuntu 20.04, JACK and
systemd. It is relevant to compatibility with current systems.

2020-12-21 update: Ubuntu 20.04.1 LTS, full-duplex and

realtime audio
Originally, I wrote the following in 2020-06-06 update: Ubuntu 20.04, systemd and realtime audio.
 I recently updated my laptops to Xubuntu 20.04 LTS and tried to use JACK with them. Turns out
that systemd no longer respects the limits set in /etc/security/limits.conf . Instead, it is
supposedly using user.conf and system.conf located in /etc/systemd . However, even after
setting the RTPRIO and MEMLOCK limits to those les, JACK fails to lock memory or use
realtime scheduling.

Searching a bit I found similar reports and debugging instructions, none of which helped. Then I
came across this Fedora bug report (https://bugzilla.redhat.com/show_bug.cgi?id=1364332)
about systemd not respecting the security limits. The bug report is already almost four years old,
starting with Fedora 26. At the end of the discussion there's a link to a similar report for Fedora
29, and in that report the latest post at the moment is some guy wondering about how things
still don't work with Fedora 32. One person suggested creating a systemd service
(https://bugzilla.redhat.com/show_bug.cgi?id=1364332#c43) for JACK and setting the limits
there. I tried - it didn't work. Even if this would work with you, it would prevent a lot of audio-
related scripting.

I've always had trouble with systemd. That's one of the reasons I still use Gentoo on my main rig:
it uses OpenRC which feels very stable and adheres to the Unix philosophy. If you're having
trouble with realtime audio and other things (*cough*snap*cough*) with newer Ubuntus or other
systemd-based distros, maybe give an OpenRC-based distro a try.

Now, in December, I took another look on why the realtime audio wasn't working with my Xubuntu.
Turns out the error was quite silly: at some point I (or a script, but it was probably me) had made a
typo in my groups le and my user was not in the audio group anymore. In limits.conf I am giving
realtime rights to people in audio group, and hence couldn't run stu realtime. After xing it,
everything works - systemd was not the culprit. I also tested full-duplex (and PulseAudio) quickly
with a newer kernel, and it works.
To get full-duplex audio working on Ubuntu 20.04.1 LTS, get a kernel release newer than 5.8, e.g.
5.9.12 (https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.9.12/):
1. install linux-headers-..._all.deb (in terminal: sudo dpkg -i package.deb)
2. install generic headers
3. install generic modules
4. install generic image
5. run in terminal: sudo update-grub (this will add the new kernel to your boot options)
Note: for realtime audio, the low-latency kernel is not required, the generic one works ne. After
rebooting, typing ulimit -r in terminal should show the realtime priority limit set in limits.conf .
Also a word of warning: new kernels might always lead to strange problems. On my old laptop the
system refused to boot unless I disabled microcode loading with kernel parameter dis_ucode_ldr .

Previous (posts/2019-08-31_uupumus/) Next (posts/2020-04-12_life_and_love/)

▲
(https://www.facebook.com/sharer/sharer.php?u=https://panther.kapsi. /posts/2020-02-
02_motu_m4&t=) (https://twitter.com/intent/tweet?source=https://panther.kapsi. /posts/2020-
02-02_motu_m4&text=:%20https://panther.kapsi. /posts/2020-02-02_motu_m4)
(http://wordpress.com/press-this.php?u=https://panther.kapsi. /posts/2020-02-
 p p p p p p p p p
02_motu_m4&t=&s=) (mailto:?subject=&body=https://panther.kapsi. /posts/2020-02-
02_motu_m4)

Send me email (mailto:olli.helin@iki. ) or comment below:

(Please note: comments with direct links to commercial sites might not be published.)

ALSO ON PANTHERIN GAINIT

4 review: With measurements an for the AKG K701 headphones: and LDAC

a year ago • 38 comments 2 years ago • 4 comments 2 years a

Motu M4 review: Detachable Bluet
With cable and in Lin
measurements wireless mod for and …

Comments Community 🔒 Privacy Policy 

1 Login

 Recommend 1 t Tweet f Share Sort by Newest

Join the discussion…

LOG IN WITH
OR SIGN UP WITH DISQUS ?

Name

Chris Schafer • 2 days ago

I went for it and got the m4 to try it out. Testing with
Ubuntu 21.04 I got fine working audio out bound
showing all 4 channels. Ubuntu decided it was front and
rear stereo and showed it all in the gui. The mic didn't
show up. In audacity and in zoom it was there and
worked great. Great interface. Headphone output
sounded clean. Line level output reveal the DAC in this
unit is very cool to nuetral. So much so I didn't like the
way it sounded with my Vantoo T0 speakers compared
to the on board DAC. My headphones tend towards the
warm side so they likely made up for it. In the end it was
a little too much money for a DAC sound I am not
particularly in love with. I really wanted to use it for my
desktop but in the end it was a more precise tool then I
am looking for. Super happy it works out of the box with
Linux. Would have loved a little more support so it
wasn't such a shot in the dark. Deciding I can get by
with a Qudelix 5K or maybe a Schiit Hel 2 we will see
with a Qudelix 5K or maybe a Schiit Hel 2 we will see.
△ ▽ • Reply • Share ›

Jasper • 4 days ago

I had problems with a M4 (Firmware version 2) on both
5.4 and 5.8, giving intermittent 'bitcrusher' / chorus /
distortion effects on audio. Bumping to 5.11 has fixed it.

It seems MOTU introduced a startup delay in the

Windows drivers before sending audio, this behavior
was mimicked in an ALSA patch
(snd_usb_motu_m_series_boot_quirk). There also was
a patch for the 'implicit feedback' thing which other
interfaces (SSL 2, Steinberg UR22C and others) had
issues with as well. For the Motu this was removed as
the current audio driver should be able to handle this by
itself now. Not sure if this goes for other interfaces, too.

It's almost as if the newer XMOS-based platforms all

had problems up until really fresh (5.11+) kernels. I
hope these changes get backported for those stuck on
kernels supplied with LTS distro's.

The boot quirk for the Motu is still in place. It would be

nice if Motu could fix this in firmware instead so the
quirk is no longer needed (and a full class-compliant
device, i.e. no Windows drivers needed, would be rather
nice as well). Here's hoping, as the sound quality is
stellar.
△ ▽ • Reply • Share ›

Voodooyam Ladyland • a month ago

many thanks! for sharing your info about the motu
interface it is on my list and also the audient id14 mk2 .
△ ▽ • Reply • Share ›

David Aliaga • 5 months ago

HI,, thanks for this review, i have a akg k701 the volume
is enought? I plan to use it with sonarworks to mixing,
sonarworks, decrease volume over dynamic range, It
will be enough?
Thanks!!
△ ▽ • Reply • Share ›

Olli Helin Mod > David Aliaga • 5 months ago

Hi!

If I play Infected Mushroom's Dancing With

Kadafi from 3:12 onwards with full volume, I can
hear tiny cracks. Lowering the volume even a
decibel gets rid of those. The amp might be on
its limits. The volume is very loud, though, but
still tolerable for testing. I'm not sure if it's the
AKG or Motu hitting its limits or something else,
and unfortunately I don't have the hardware to
figure out which one is it.

If I use an equalizer such that by default

everything is -10 dB, but from around 100 Hz
downwards boosted so that there's a -0 dB peak
 p
at 30 Hz, music sounds rich and great, and
there's no distortion at full volume. But, there's
hardly any leeway, either. It'd definitely be loud
enough for me, but I do kind of feel weird
knowing that there'd be nothing more in the
reserve, either.

As the K701 is such an "analytical" headphone, I

would imagine the volume levels aren't going to
be extreme while mixing?
△ ▽ • Reply • Share ›

Raul Trifan • 6 months ago • edited

Hi, great review indeed, congrats!

There should be one single AK5554 ADC chips inside

and not two AK5552. There's a clear picture here:
https://prosound.ixbt.com/i... and more technical details
here as well: https://prosound.ixbt.com/i....

I got one M4 myself too and I'm testing it these days,

quite a decent audio interface.

Thanks again for the very detailed review and the tricks
about the Linux settings.
△ ▽ • Reply • Share ›

Olli Helin Mod > Raul Trifan • 6 months ago

Thanks!
Interesting note about the AK5554 ADC chip, not
surprisingly it seems to be identical to AK5552
but with 4 channels. The technical people at
Motu probably said the AK5552 by accident.
△ ▽ • Reply • Share ›

Alex > Olli Helin • 2 months ago

The Motu M2 has a single AK5552 ADC
chip ;)
△ ▽ • Reply • Share ›

QuidProQuo • 10 months ago

Follow-up to my comment re: PA & remixing:

cat daemon.conf

resample-method = src-sinc-best-quality; possible CPU

performance spike; keep cpu-limit enabled
cpu-limit = yes
[ ... ]
default-sample-format = s24le
default-sample-rate = 48000
; alternate-sample-rate = 96000
default-sample-channels = 2
default-channel-map = front-left,front-right

△ ▽ • Reply • Share ›

Olli Helin Mod > QuidProQuo • 10 months ago

This is how to set mixer properties for
PulseAudio, but it's irrelevant concerning what
the article is about.
△ ▽ • Reply • Share ›

QuidProQuo > Olli Helin

• 10 months ago
I shall attempt to be more clear: using PA
with a strict sampling rate makes it much
more trivial to use other software which
handles resampling 'on the fly.' This will
negate your issue of the sample rate
switching delay. Again: I listen to 96kHz
FLACs & 44.1kHz mp3s/podcasts when
PA & JACK is set to those mis-matched
rates without issue (eg: Quod Libet).

No timeouts, pops, clicks, glitches,

distortion, xruns experienced at all.
△ ▽ • Reply • Share ›

Olli Helin Mod > QuidProQuo

• 10 months ago
I did not quite understand what
you mean by a "strict" sampling
rate or other software handling
resampling on the fly. Can't also
remember having had problems
with "mis-matching rates", all the
software I use seem to have their
own resamplers if needed for
JACK. And if I'm using just ALSA,
in addition to bad quality linear
interpolation, noawadays there
are high-quality speexrate and
libsamplerate converters, so again
no need for PulseAudio there.

PA is convenient in setups where

you switch between multiple
devices and/or Bluetooth
headsets, but that's pretty much
all I think it is for - convenience.
Also there are some applications
that need it, but those are quite
rare luckily. Nowadays PA doesn't
seem to have terrible latency -
which, back in the days was my
reason for not using it in the first
place. Having audio/video
desynced was intolerable.
△ ▽ • Reply • Share ›

QuidProQuo > Olli Helin

• 10 months ago
s/strict/default

Can't also remember having

had problems with "mis-
matching rates" [...]
 §Sampling rate switching delay .
Why even bother switching when
one can just resample in real
time?:

Match PA's rate to JACK's, then

use PA to resample if some
application doesn't have an
included resampler DSP plugin.
PA has about a dozen different
methods including a couple of
speex. If you've personally
already got it sorted with a suite of
various applications, great; if not,
PA can take up that task if
immediacy is an issue in that use
case. YMMV.

See my next comment re: PA

uses, rarity... & I disagree; PA is
still trash for latency but in my
experience the desync issue is
next to negligible for video
playback these days but there's
still no way I'd use it during
editing. It's not even worth trying
to use for live monitoring when
tracking vocals.
△ ▽ • Reply • Share ›

QuidProQuo • 10 months ago

2020-06-06 note: according to JACK documentation,
the niceness has no effect on realtime audio.

Niceness can absolutely have an indirect effect on RTIO

as lower priority/'niceness' values clear more cpu time
for higher niceness (eg: pulseaudio -14 (very high),
firefox 5 (low), evolution-calendar-factory 19 (very low)).
One has to first disable the kernel from autogrouping
(eg: Ubuntu):

#!/bin/bash
[ "root" != "$USER" ] && exec sudo $0 "$@"

# disable nice autogrouping

#
https://www.reddit.com/r/linux/comments/d7hx2c/why_nice_l
if ! [[ $( / / /k l/ h d bl d)
see more

△ ▽ • Reply • Share ›

Olli Helin Mod > QuidProQuo • 10 months ago

Yes, that is how niceness works. But as the
JACK developers said, it doesn't affect the
realtime priority apparently. Which sounds quite
plausible actually: realtime is realtime, and then
you'd set the regular scheduling priorities with
niceness
niceness.

That -L (show threads) switch did the trick for the

ps command indeed, now I can see the realtime
priorities of JACK for example.

I still do not recommend PulseAudio, let alone

with resampling, let alone with that specific
sampling rate. You are losing quality, here :)
△ ▽ • Reply • Share ›

QuidProQuo > Olli Helin

• 10 months ago
I did state it was an indirect effect... but a
very important one. Try something like
renicing jackdbus or jmcore below Xorg
or firefox and watch the xruns tally.

Nobody recommends PA but it's next to

impossible to get away from it. Have you
ever tried using Firefox complied with
JACK support? Every time a new page
tries to access the sound stack, it trips
xruns. That's unacceptable for a
multitude of use cases but obviously
YMMV.

You don't "lose quality" when down

sampling an already mixed track. The
average human ear can only hear
between ~20Hz--20kHz. DVDs are only
mixed to 48kHz, still being 4kHz above
the threshold for Nyquist–Shannon
sampling theorem... never mind getting
into the whole 'DSD v PCM' so-called
'debate.'

I use 48 kHz as I've experienced that

interface's DSPs track 48, 96, better than
44.1, 88.2. I don't care to use additional
HDD space those higher sample rates
require. Again, YMMV.
△ ▽ • Reply • Share ›

Olli Helin Mod > QuidProQuo

• 10 months ago
Well, I actually tried renicing
jackd. I'm not using the jackdbus.
Zero effect. I was running JACK
with 1.45 ms latencies in duplex
mode while playing back music
and recording in stereo and
running 24 threads of CPU burn at
the same time. The only thing that
had a very clear effect was
whether I was running jackd in
realtime or not. It is quite hard to
reproduce the xruns when
needed, it seems :D Actually, I
think the drivers must've improved
or something since while writing
 g g
the article I could only do 192 kHz
with 64 frames per period, 7
periods per buffer. Now even
using just 2 periods per buffer
doesn't cause a flood of xruns!

Also I don't know why you keep

saying it's next to impossible to
get away from PA. I've been
running my system happily
without it for the past 13 years.

I do know the sampling theorem,

no need to get into that. What I
can also tell is that resampling
may have quite an audible effect
on sound quality. The very reason
I started digging into ALSA
configuration was because of bad
resampling quality back in the
days. Done correctly, software
resampling has practically zero
audible effect, that's true.
PulseAudio probably is using very
high-quality resampling
nowadays.
△ ▽ • Reply • Share ›

QuidProQuo > Olli Helin

• 10 months ago
It curious that you've chosen jackd
over jackdbus; only the latter is
SMP-aware.

I could only do 192 kHz with 64

frames per period, 7 periods
per buffer. Now even using just
2 periods per buffer doesn't
cause a flood of xruns!

192/2/64 = ( 64 / 192000 ) * 2 *
1000 == 0.6666666667ms . I want
to believe it but the math doesn't
work; that'd be directly out
preforming RME's 900USD PCI-E
cards (0.7ms/buffer) and omitting
the USB2.0 stack requires
125 / k tf l ti
see more

△ ▽ • Reply • Share ›

Olli Helin Mod > QuidProQuo

• 10 months ago
Well, can't say about
VoIP/WebRTC apps and JACK - I
don't bother using JACK unless
I'm recording something proper. I
just use ALSA if chatting. And in
case I need PulseAudio, I can fire
 ,
it up as a bridge to ALSA or
JACK; so far haven't needed it, so
no problems here.

It curious that you've chosen

jackd over jackdbus; only the
latter is SMP-aware.

I don't find it that curious at all.

JACK1 is simple to use and is
equivalent to JACK2 except for
the SMP. It would add latency
anyway according to the docs,
and it's not like I'm running out of
processing power without SMP
anyway, so why bother.

I implore you check your testing

methodology. man jack_iodelay

No need to check. I know the

numbers and I've measured them,
and they are easily within the
limits. You did read the article and
what the manufacturer is
promising, right? That'd imply a
value of 0.33ms. Why are you
bringing USB specifications here
when we're just talking about
jackd settings? Well I know why,
but I'll end this here as this is
going nowhere. -_-
△ ▽ • Reply • Share ›

Olli Helin Mod > Olli Helin

• 10 months ago • edited
As it turns out, I should've
remembered the old proverb:
don't feed the troll. I'll save the
general public from the
embarrassment that is their last
message. Remember to keep it
cool and factual when discussing
things, thank you. :)
△ ▽ • Reply • Share ›

AudioGuy • a year ago

Thanks for this awesome guide for us Linux users! The
MOTU is working perfectly on my Manjaro KDE system.

I would like to add a workaround regarding the boot

quirk patch. Yes, if you are running kernel 5.7, the patch
will fix the bug. However, even if you aren't running 5.7,
I have found an easy way to fix the bug, if you use KDE.
The bug occurs when you connect the MOTU to an
already running Linux system, causing the MOTU to
freeze. You can fix this by going to KDE's Audio Volume
tool in the System Tray, and then selecting a different
 y y, g
"Default Device" for audio output, and then selecting the
MOTU again as the "Default Device". This cycle gets
the MOTU working again.
△ ▽ • Reply • Share ›

To1ne • a year ago

This article is awesome, thank you so much. It's so hard
to find good information about this on the net.

I've been thinking about getting a Motu M2 for a while.

But instead I bought myself
https://evo.audio/products/.... It's also a very nice
device, but I'm having one issue. The device has audio
loopback, just as the Motu M2 has. But on my device, I
don't have separate input channels for: loopback, input
1, and input 2. It only has one input channel which is
both inputs of the device, combined with the loopback
audio. So if I want to use my mic connected to this
device for video calls, people will hear themselves.

So I was wondering if the Motu M2/M4 has similar

issues? Or did you change configuration to overcome
this? Do you have any tips how I can dive into this
issue? If you're interested, I've dumped my ALSA
information to http://alsa-project.org/db/...

▲
If everything is working as expected with the Motu I

(http://creativecommons.org/licenses/by/4.0/) This article by Olli Helin is licensed

under the Creative Commons Attribution 4.0 International License
(http://creativecommons.org/licenses/by/4.0/)

Powered by GainCMS (https://github.com/ohel/gaincms)