MOTU M4/M2 Driver issues / System process high CPU / MOTUCoreUAC.sys

[bananacry]

Hi there,

I discovered a significant issue with the MOTU M4 driver when using the two lowest buffer settings on any sample rate.

When using my MOTU M4 (made in China, firmware 2.03), I noticed that when using the two lowest buffer sizes on any sample rate (regardless of "use lowest latency safety offsets"), the System process experiences high CPU usage (10%) when playing audio. The culprit of this high CPU usage is MOTUCoreUAC.sys, which I discovered through Process Explorer (open System process -> Threads tab -> sort by CPU).
However, when using any other buffer size, the CPU usage drops below 1%.
With any other than the 2 lowest buffer sizes, the CPU usage of the driver drops way under 1%.



I found the same behaviour under 2 Win machines I own.
Every driver newer than 88030 (4.0.8.8030) (uploaded March 26, 2021) does have this behaviour. (so not the 88030 driver but any newer)

MOTU M4 / Firmware 2.03 / Driver 92462
directly connected via USB-C to USB-A cable

Desktop PC
Win 11 22H2 (22621.1413)
Gigabyte Z490 Gaming X (newest BIOS and Drivers)
Intel i5 10900K @ 4.9 GHz / 32GB @ 3600MHz
Fresco Logic FL1100 USB Controller

Spoiler: bonus about USB Controllers performance with my M4

I found out that any of my 4 USB Controllers
* Intel Z490 Chipset USB 3.2 Gen 2
* NVIDIA USB-C (RTX 2070)
* ASMedia ASM3142 (EZDIY-FAB USB3.1 Gen2 PCIe to USBC Front Panel Expansion Card) ´
* Fresco Logic FL1100 Chipset (Inateck KTU3FR-4P)

The worse one was the ASMedia. very distorted sound on lowest buffersizes + using lowest latency settings on every samplesize. unusable.
Intel and Nvidia both much better but mild constant high pitched clicks in sounds. on lowest settings.
only on the Fresco Logic Controller I can use the lowest setting. (192kHz / 64 / safety offset checked).
Not really 100% free of occasional clicks (every 5 seconds maybe) but significantly better again.

Surface Pro 3
Win 10 19045.2546
i5 4300U / 4GB

Can anyone confirm or deny this behaviour on their M2 / M4? Iam a bit surprised that I did find nothing about this, despite the fact that this issue seems to be present since 2 full years).
So it would be logical that this behaviour is not the standard case for most users.

Spoiler: High CPU System

Spoiler: no problem: 3rd fastest buffer sizes and above

Spoiler: Driver 88030 works

 

[Cbdb2]

The new driver has a "sync windows sample rate" box. Does that make a difference? I have a M4 but haven't updated it, not sure I should now.

 

[phofman]

16 samples (IMO meant as audioframes - a set of 1 sample per each channel) at the 48kHz samplerate means the driver buffers only 333us of samples from the player.

When USB controller starts consuming batch A of microframes, it notifies via IRQ the driver, which must wake up the player to send a new batch B of 16 frames. The USB-audio driver receives a buffer with 16 frames, must split them to USB packets for each USB microframe (taking into account the async feedback rate requested by the device), and pass the usb packets to the usb-core driver which merges them with packets from other device-drivers to form USB microframes and copies the resultant microframes to RAM for the USB controller to read them via DMA. All this must be made within the 333us on average so that the batch B data are processed on time and the USB controller does not get starved out

The USB controller/device consumes 6 audioframes on average each 125us microframe, so the granularity of the IRQ is 6 audioframes. The usb-audio driver requests 16 frames from the player which is not an integer multiple of 6. As a result it must buffer a bit more to cover for the difference - the driver would wake up the player in a mixture of 2 to 3 microframe intervals (12/18 frames) to fit the average to the 16 audioframes received.

This is extremely tight timing, especially on windows. In order to reduce the risk of buffer underruns for the smallest buffer sizes I can imagine the newer driver was changed to use some polling/short waiting in a loop, to avoid the latency introduced by the sleep->wakeup by the controller. Polling in a loop is always significantly more CPU intensive than sleep/wakeup, but has lower latency.

 

[bananacry]

The new driver has a "sync windows sample rate" box. Does that make a difference? I have a M4 but haven't updated it, not sure I should now.

This is driver related not firmware. You can install and test whatever driver you like there are now consequences like you would have with a firmware update.

 

[bananacry]

The new driver has a "sync windows sample rate" box. Does that make a difference? I have a M4 but haven't updated it, not sure I should now.

But no "sync windows sample rate" doesnt have an effect on my observed behaviour

 

[Momomo67890]

Email motu ????

 

[bananacry]

UPDATE: New Firmware 2.04 (Release Date: March 29, 2023) doesn't change the behavior.

 

[Cbdb2]

Thx for the info

 

[nurse_nutmeg]

For anyone that's having issues work through these troubleshooting steps, helped me.