Motu M4 review

With measurements and Linux notes

I updated my computer 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 offer superb sound quality in a nice package. I wanted a device that is class-compliant and bus-powered, and the M4 fit 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 find out. In this review I skip microphone recording tests, as there are already many review videos on YouTube addressing that specific area. This review is more about the outputs and Linux compatibility.

The Motu M4 front panel. All the knobs feel really nice and sturdy.

Specifications and notes

Here are some specifications I haven't found anywhere else online, but which I've checked from the manufacturer:

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 official Motu site.

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 affordable.

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 fixed 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 fixed 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 fixed 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.

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.

Setup

ARTA calibration — The calibration was done using a voltmeter between the balanced connection tip and sleeve.

For a first-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 final, 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 different 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.

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.

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 figure of the balanced loopback measurement but then I realized I was using 16-bit Dither Level. Selecting 20-bit dithering and raising the signal level to -1 dBFS from the 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 effect on the sound quality.

Frequency response

While measuring the frequency response I had the unbalanced RCA monitor outputs connected to the line inputs. The frequency response was extremely flat.

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 difference. If the signal level is anything greater than about -60 dbFS, the frequency response stays practically flat, 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 % difference could be distinguished.

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 and Audacity. I chose the best values I deemed stable with 96000 Hz sampling rate: 64 frames per period, 6 periods per buffer. 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 I then played out via the line out and looped it back into the line in.

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 buffer 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 buffer. 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 different settings, any smaller latency and JACK would just output XRuns (buffer 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 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. It uses the Cirrus Logic CS-4398 DAC chip, which has very good specifications, 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 figures 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 amplifier I have at the moment. I also did an extra loopback run so that the signal first 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 different day and room temperature. That's how clean the M4 is.

Linux setup and notes

All my audio config files are available in my dotfiles repository at GitHub, but I've linked them here as they currently are. I use a generic, abstract ALSA config along with another, system-specific config file, which defines the actual devices and hence also contains the M4 definitions. 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 define 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 fire 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 config 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, the niceness has no effect 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, but I have no idea whether it has any effect 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 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 different, 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 first I thought my USB port was going to sleep after some time, but the usbcore.autosuspend=0 kernel option didn't help. It took a few seconds 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 fly, 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 five 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 difference 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 amplifier, as it's now hissing a bit even if it otherwise sounds really nice.

The headphone output is very different 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 amplifier I used the CME Matrix X, a device with very good specifications. 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 floor 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 find 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 first 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 amplifier to match for that perfect sound, so your mileage may vary.

Conclusion

I've been super satisfied with the new computer I assembled. The one part that felt troublesome to find was a new, affordable 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 specifications.
The specifications also deliver in practice.
The potentiometers affect 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 find. 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 fixing commit.

If you need an audio interface, just buy the Motu M4 or M2.

Sunset — This Moroccan sunset has nothing to do with anything, I just wanted a separator for the article update. 😁

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 five seconds when switching sampling rate. To find out whether this was just a Linux-specific problem, I tried to reproduce the effect 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 that is 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 fixing commit. 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 that 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 differently. The Linux audio stack always was a bit of a mystery and I've seen random stuff 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 firmware 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 M4/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 affects 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 fixing commit on GitHub.

I tested the Motu M4 using two different laptops with the following configurations:

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 first, 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 fine. Some people say, to work at all, the Motu M4 needs some kind of patch. 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 different systems and I haven't noticed any difference 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):

Disable PulseAudio from autostart. It's probably a systemd service nowadays.
Install JACK.
Install PulseAudio module for JACK: $ sudo apt install pulseaudio-module-jack

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

Restart your system.
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 configs which I uploaded to GitHub. They include a convenience script for firing 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 files, 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 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 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 file 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 stuff realtime. After fixing 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:

install linux-headers-..._all.deb (in terminal: sudo dpkg -i package.deb)
install generic headers
install generic modules
install generic image
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 fine. 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.

2020-12-21	Add Ubuntu 20.04.1 LTS and RT audio info; some tidying up.
2020-08-31	Add note about fixed 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.