USB Audio interface for measurement

Traded up from M2 to the M4, its very sweet (BH Photo).
Nice line out/in and the motu driver is perfect. I looking at new software as my old RTA is now defunct and no longer supported.
On w10 testing now the Visual Analyzer from Italy.
So far looking good. M4 basic thd 0.0004 and thd+n 0.0009
Visual Analyser details

You can find several measurements of the MOTU M4 on this web page:
MOTU M4 Loopback Measurements | Audio Science Review (ASR) Forum
Along with measurements of some other good quality sound cards.

I just bought two M4s to use under Linux for DSP crossover work. Currently not supported by the kernel until version 5.6.x which has not even been released yet. You have to patch the kernel and recompile to get it to work at all (but then it works perfectly). Info on the patch here:
[alsa-devel] [PATCH] ALSA: usb-audio: Add boot quirk for MOTU M Series
 
Yes I follow ASR, the manual for m2 and m4 mentions 'ring' if grounded on rear bal 1/4" will have high dist vs true balanced connection.
A balanced line in -> line give rock steady 0.0004 %thd.
Unbalanced on same with ring open gives 0.001-0008 % thd.
Grounded ring as when using a mono plug can go as high as 0.002%
Does not apply to front panel 1/4" input.

That's why I made special cables for unbalanced tests.
 
Measured the M4 max outputs RMS levels, seems some confusion on the ASR tests.
Going frum - to + on balanced line out I measure 5.2VRMS and 15V PP.

The unbalanced outputs are slightly less than 50% of the bal output. ie 2.4VRMS 7.2 PP

Here is a stereo pic testing a real tube amplifier, different skin playing with colors.
I don't have the spectrum cal scale figured out yet. The measured voltages are correct.
-
 

Attachments

  • m4-ipad-skin2.JPG
    m4-ipad-skin2.JPG
    348.3 KB · Views: 782
I just bought two M4s to use under Linux for DSP crossover work. Currently not supported by the kernel until version 5.6.x which has not even been released yet. You have to patch the kernel and recompile to get it to work at all (but then it works perfectly). Info on the patch here:
[alsa-devel] [PATCH] ALSA: usb-audio: Add boot quirk for MOTU M Series

Hi,

how did your M4 malfunction? I just wrote a Linux user review of the Motu M4 with some distortion and latency measurements (link to review, my own blog) and I haven't noticed anything weird. I'm running the 5.4.15 kernel.

The only thing that I do think is a bit weird, which I mentioned in the article also, is that apparently my USB port goes to sleep if idle for too long, and it takes a couple of seconds for the audio to "wake up" again when starting to play. I was thinking if this had something to do with that boot quirk thing, but that's far from "to work at all", so I guess it's not the same thing.
 
It's a timing thing, therefore it is possible on your setup it works OK. There must be a reason the windows driver implements the delay. Perhaps the delay of two secs could in fact be just a few millisecs. The patch author's (and Charlie's) system sent the packets faster than yours, got stuck and the author used the 2 secs from the windows driver, did not study how long delay would be sufficient.
 
Hi,

how did your M4 malfunction? I just wrote a Linux user review of the Motu M4 with some distortion and latency measurements (link to review, my own blog) and I haven't noticed anything weird. I'm running the 5.4.15 kernel.

I've been posting my experiences with a Motu M2 under Linux, over at Linux Musicians. Just in terms of basic DAC playback functionality, this is what I discovered:
Mint, 5.0.0-37 kernel - doesn't work.
Mint, 5.3.0.28 kernel - doesn't work.
Arch, 5.4.6 kernel - works.
Mint, manually upgraded to 5.5.2 kernel - works.

I've no doubt that the referenced patches to be shipped in 5.6 will be valuable on some systems, but some other change in 5.4 seems to have addressed fundamental functionality issues. So it may not be necessary for folks to wait until 5.6 ships to make use of the M2 and M4.

Thanks for the detailed review minigun!
 
Its a processor mips thing. I kept having issue with intermittent buffer and visible jitter.
So after trying all of my old laptops (most have AMD) went to blue bigbox and bought HP with Core i3, 8Gb and 1Tb - Tag said $399 but upon checking out said $349..
*no* more problems. I needed an updated laptop anyway.
Also using M4 96khz now.

On Visual Analyzer, use the 2014 release. Works perfect, the 2019 beta has too many bugs.
http://www.sillanumsoft.org/Download/SetupVA2014.02.exe
 

Attachments

  • laptop.jpg
    laptop.jpg
    229.6 KB · Views: 601
The weaker the CPU, the larger buffers are needed to avoid buffer underruns. Fewer context switches, larger sample batches processed in one run, it all contributes to throughput. Of course up to the point when the CPU does not keep up with the analyzing task...

Unfortunately many OS/software stacks do not allow configuring the soundcard/chain buffers.

VA 2014 did not run OK in linux/wine, while the 2019 seems to run fine. I did not do any extensive tests though. It can handle 1.5MHz samplerate without any modifications, the only one from the windows bunch https://www.diyaudio.com/forums/equipment-and-tools/349239-support-samplerates-sw-analyzers.htm While a few minor bugs arose during the test, its multithreading fared surprisingly well (at load over 150% CPU core for the VA process it was still quite responsive).
 
The M4-2 Definitely need processor HP. It's well worth it, now I'm sub ppm thd for all testing.
On 2019 va i had bugs when using config save/retrieve and would have to reinstall, floating point error probably due to AMd differences. I tested various buffer sizes and other analyzer software. It just needed fast computer.
 
I thought I would pop back into this thread after discovering that kernel 5.6.x is finally available. Glad to see that the M2/M4 are getting some positive attention. IMO the M4 especially is really nice for the price.

I read through some off-site reviews like these with interest:
Motu M4 review: With measurements and Linux notes
Motu M2 USB Interface on Linux - LinuxMusicians
In the linuxmusicians thread authored by forum member robjordan, one post mentions that the user could not get simultaneous record and playback to function.

I might be able to offer a solution based on some work I was doing today to get a Focusrite 6i6 running in full duplex (simultaneous playback and record on the same unit). It's also a fully async interface under ALSA and I couldn't get it to work initially. I could only get something that sounded like a bad ground - that loud humming at the mains frequency. This is with digital input! Weird. I have experienced this behavior before with a different audio interface, but I thought that it was defective at the time.

Here is how came up with a workaround under Linux (Ubuntu). It might work for the M4. Not sure I would have to test it. I wanted to use the digital input of the 6i6 for audio input (taken from a Cd player), process the audio on the computer (implement a loudspeaker crossover network), and then output 4 channels of analog audio. What I ended up doing was using PulseAudio to get/source the audio, with the device configured in pavucontrol for multichannel input only (no output). I used a separate program (Gstreamer, but could be ecasound or whatever) configured to use the ALSA "pulse" device as the audio source. ALSA's pulse device appears in pavucontrol as a recording device called "ALSA plugin" with its own input volume. I used my Gstreamer app to implement the crossover and sent the output via ALSA to the 6i6. I can control the input level via amixer, because the ALSA device called Pulse has scontrols Master and Capture. Because the 6i6 driver does not include a volume control, I am using the digital input level as volume.

So this might be a way around the non-duplex operation, to split input and output between two different applications. Not sure, maybe worth a try with the M4. I have no idea how this kind of setup influences things like clocks or latency. It's probably not optimal... but it works. I'm not sure why, because Pulse is built on top of ALSA. Why Pulse-in-ALSA-out works but ALSA-in-ALSA-out does not is a mystery to me.

Edit: One reason it took me so long to get the 6i6 up and running was that I had my pulse audio configuration (/etc/pulse/daemon.conf) configured with only 2 channels of audio. I had to edit this file and set the default channels to 6 to match the channel count of my interface.
 
Last edited:
Why Pulse-in-ALSA-out works but ALSA-in-ALSA-out does not is a mystery to me.

Since "-> PA -> alsa ->" is just "-> somehow-configured alsa -> PA -> alsa ->" (exactly as you mention), the PA part definitely can be avoided. You could have a look what capture devices with what params and what amixer controls PA uses and use the same in your alsa capture process (gstreamer?)

Capturing SPDIF means the capture part of the soundcard is clocked by the SPDIF stream. Most soundcards switch their processing clock (i.e. for the playback too) to this clock source, some have to be told to do so by corresponding controls. The cheapest USB cards do not seem to do so but that definitely will not be the case of Motu.

I am sure your chain can be setup to exclude PA.
 
So I have QA400 that I can't get working under Win10 (like everyone else) or a Win7 virtual machine. It connects, but the USB is flaky to say the least... I have plans to reorganize my bench setup and repurpose the laptop that currently runs the QA software, so currently considering other options.

What hardware options with available ASIO drivers (to be able to use 3rd party measurement tools) are recommended?
 
Thanks!

Maybe with some elbow grease it can be upgraded to AK5572?

Interesting! It looks to be pin to pin compatible, although the power consumption is a bit higher for the 5572 chip, so the existing regulator type must to be checked if can support the added power.

Also, the input resistors from the 5572 may need replaced, to match the datasheet.

https://www.akm.com/content/dam/doc.../audio-adc/ak5552vn/ak5552vn-en-datasheet.pdf vs. https://www.akm.com/content/dam/doc.../audio-adc/ak5572en/ak5572en-en-datasheet.pdf

Not willing to test this on my M4...yet. :)