• Welcome to ASR. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!

MOTU UltraLite-mk5 Review (Audio Interface)

I use a Python script in combination with a TP-Link Tapo smart plug / scheduled tasks on Windows to turn my interface on when my PC boots up and off at shutdown. Seems to work quiet well although can't really understand why they don't offer an option to power the device down when it loses the USB C connection.

Hate leaving things turned on for no reason.

by doing that you are in popping city
 
I use the device as a digital mixer, without a computer, pre setting up. Sometimes with raspberrie pi5.
I never listened to the device to clap when turning on/off
 
How can I do what you did tho
Do you have TP-Link Kasa or Tapo smart plugs and Windows 11 Pro? Kasa is the plug I've worked with but Tapo would probably be easy to get working too.

If so, all you need to do is install Python, install a single Python module, assign a static IP address for the plug on your router and have one script run on startup with task scheduler and another run on shutdown with group policy.

I can share the scripts / tasks without issue.

If you don't have Windows 11 Pro it's slightly less efficient in how you check for system shutdown as you can't assign a group policy shutdown script and have to continuously check the event log for a shutdown event ID.
 
If you don't have Windows 11 Pro
you may set up a custom event filter in Task Scheduler.
Triggers > New > Custom > Edit Event > XML
and paste the code:
<QueryList>
<Query Id="0" Path="System">
<Select Path="System">
*[System[Provider[@Name='User32'] and (Level=4 or Level=0) and (EventID=1074)]]
and
*[EventData[Data[@Name='param5'] and (Data='power off')]]
</Select>
</Query>
</QueryList>

This will filter out the power off event only.
 
you may set up a custom event filter in Task Scheduler.
Triggers > New > Custom > Edit Event > XML
and paste the code:
<QueryList>
<Query Id="0" Path="System">
<Select Path="System">
*[System[Provider[@Name='User32'] and (Level=4 or Level=0) and (EventID=1074)]]
and
*[EventData[Data[@Name='param5'] and (Data='power off')]]
</Select>
</Query>
</QueryList>

This will filter out the power off event only.
Yes - This is pretty identical to what I was doing myself but it's inefficient as you are constantly parsing the log file (even if the filters do narrow it down somewhat).

The far more efficient approach is to use shutdown scripts as part of a Local Group Policy (Computer Configuration -> Windows Settings -> Scripts -> Shutdown

These scripts are specifically run prior to shutdown so you don't have to worry about the race condition where your script has to successfully execute before Windows closes everything down or the fact that you're constantly scanning the event log in the background when it's not necessary to.

The only downside to this is that I believe you need a "Pro" version of Windows to access Local Group Policies.

You can use something like the following PowerShell to only shut off the device when your PC is shutting down (and not restarting):

Code:
$lastShutdownEvent = Get-WinEvent -LogName System -MaxEvents 1 -Oldest:$false -FilterXPath "*[System[Provider[@Name='User32'] and (EventID=1074)]] and *[EventData[Data[@Name='param5'] and Data[@Name='param5'] != '']]" -ErrorAction SilentlyContinue

if ($lastShutdownEvent) {
    $eventDetails = $lastShutdownEvent | Select-Object -First 1 -ExpandProperty Properties
    if ($eventDetails.Count -ge 5) {
        if ($eventDetails[4].PSOBject.Properties.Name -eq "Value") {
            switch ($eventDetails[4].Value) {
                {$_ -in @("shutdown", "power off")} {
                    Write-Output "Running command: $KASA_PATH $($KASA_ARGS -join ' ')"
                    # Shutdown Motu
                    & $KASA_PATH $KASA_ARGS
                }
                Default {exit}
            }
        }
    }
}
 
Local shop told me this product is discontinued

Mk6 coming?

Or shop has it wrong?
No way to know. It is available from many sellers and still on their website. It isn't that old, but they may plan a mk 6.
 
Local shop told me this product is discontinued

Mk6 coming?

Or shop has it wrong?
I hope it's true! I wonder what improvements it would bring other than the likely obvious that most of us don't use. :)
 
Has anyone with the MK5 noticed a fluctuating clock behavior?
I was doing some tests on Mac and I noticed this strange phenomenon through the CoreAudio clock drift compensation function.
Basically, I created an aggregate device in CoreAudio consisting of the MK5 plus the BlackHole loopback driver. Since BlackHole works with Mac clock, the drift with respect to MK5 is inevitable, so assuming that the Motu clock is reliable I set this as a clock source and activated the drift correction for BlackHole. In this way CoreAudio asynchronously resamples the audio flow of BlackHole.
Then I made a measurement with REW by setting BlackHole as the output device (the original driver, not the aggregate) and as the input the aggregate device on the corresponding loopback channel.
I used a 1khz tone on the generator and the RTA window with the clock drift shown, so I can see the delta clock between output (following Mac' clock) and input (resampled async. according to MK5 clock).
The result was a continuously fluctuating drift value between 31.1 and 32.0 ppm, even after 5 minutes of playback.
This behavior is undoubtedly due to the MK5 clock because if I create a different aggregate device with built-in speaker the drift I observe is 5 ppm fixed, not fluctuating.
I have no possibility of verifying the behavior of other professional audio interfaces but the fluctuating behavior compared to the perfectly static one of built-in speakers puzzles me. The clock should be a strong point of any audio interface...

Can anyone verify his Mk5 how does it behave?
 
Last edited:
This looks like a controversial experiment... Are you sure this is Motu's problem? CoreAudio is a bit sloppy (((
 
This looks like a controversial experiment... Are you sure this is Motu's problem? CoreAudio is a bit sloppy (((
It doesn't seem like the maximum of the measurement setup, but in theory it correctly reflects the difference between the Mac clock and the Motu clock.
REW seems to apply a filtering to the calculation so the indicated fluctuation could be smoother than real one, but the fact that it fluctuates remains (I am coding a script in C to measure outside of REW however).
I checked the Blackhole source code and it works with mach_absolute_time that is the most accurate timer in Mac. Furthermore it does not seem to make some dynamic adjustments in the request for samples. In any case, even if it were, the fluctuation would also appear with the built-in speaker, but no.
On the other hand, the way Motu handles USB timing is unknown. It is not taken for granted that it directly corresponds with the clock of AD/DA stages.
But if this were not the case, the Core Audio Clock Drift Correction principle would be slightly flawed. Or rather, it would not be recommended to opt for the MK5 clock source in this case.
We will clearly not distinguish a few ppm of drift in an audio signal, jitter audibility threshold should be 20ns (but depends on jitter type) and here I have about 0,01ns if I calculate correctly... so that's irrelevant.
But technically it leaves me perplexed.
I can't determine which is the most reliable configuration this way... I would need a good level adc like cosmos (I don't know the phase noise it has however) or oscilloscope to verify with greater certainty. But it seems too strange to me that the Mac's built-in speaker clock is more stable than the Motu.
Maybe @mdsimon2 can do a check?
 
Last edited:
I have yet to see a comparison between this Motu and RME Fireface UCX 2 at $1700

The RME fanboys will spew hundreds of excuses as to why is worth $1700 yet I can bet in real playback and recording the difference is probably ZERO if anything it seems the Motu has better DAC

The Motus DAC is superior to the one in this RME

Motu's DAC is ES9026PRO which is equivalent to the AK4490 in some Denons. Both of these DACs are superior to the AK4458 in the RME

I made a topic about this and the RME fanboys exploded, saying is the experience, the support, the DAC chip is only one SMALL part of the equation, is build quality, etc

That doesn't change the fact it has an inferior DAC

You're paying for the brand and whatever else you believe it makes it worth it.

At $1700 it should come with a similar DAC if not better than Motu Ultralite MK5

They make it seem as if DAC is irrelevant, as if, is literally one of the most important aspects that separates a good unit from a cheap one
 
Last edited:
I have yet to see a comparison between this Motu and RME Fireface UCX 2 at $1700

The RME fanboys will spew hundreds of excuses as to why is worth $1700 yet I can bet in real playback and recording the difference is probably ZERO if anything it seems the Motu has better DAC

The Motus DAC is superior to the one in this RME

Motu's DAC is ES9026PRO which is equivalent to the AK4490 in some Denons. Both of these DACs are superior to the AK4458 in the RME

I made a topic about this and the RME fanboys exploded, saying is the experience, the support, the DAC chip is only one SMALL part of the equation, is build quality, etc

That doesn't change the fact it has an inferior DAC

You're paying for the brand and whatever else you believe it makes it worth it.

At $1700 it should come with a similar DAC if not better than Motu Ultralite MK5

They make it seem as if DAC is irrelevant, as if, is literally one of the most important aspects that separates a good unit from a cheap one
Sorry I didn't understand if this has anything to do with my previous post.
Anyway, RME offers some more features, like RoomEQ, loopback on each output, adjustable output level between 4/13/19dBu, world clock.
Then I don't know what else honestly... but I agree that the price difference is unjustified.
 
Back
Top Bottom