-
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)
- Thread starter amirm
- Start date
mdsimon2
Major Contributor
I am also inclined to blame the Core Audio aggregate device drift correction rather than the Mk5.
When I've measured Core Audio drift correction in the past it seems to match your description, it will stay roughly sync'd but still has some shifting. See scope recording in the post below as an example.
VB Matrix
As requested by some members, starting a new thread on this recently released software called VB Matrix. https://vb-audio.com/Matrix/ Setup guide: https://forum.vb-audio.com/viewtopic.php?t=1807&sid=7b41ab762ce5b5bdcf525e097526e77b
www.audiosciencereview.com
You can also see this when looking at crossovers that use drift corrected aggregate outputs from different devices. They are OK at low frequencies but show variation at higher frequencies.
VB Matrix
After three "10-hour" days with VB Matrix, I have not heard any dropouts/clicks/pops. Listening on the master or on the slave?
www.audiosciencereview.com
What is your use case for Blackhole? It sounds like you are just using it as an input to the Mk5 so I wouldn't expect drifting to really be a concern (unlike a crossover from drift corrected outputs). I imagine you would see similar drifting with any sort of clock domain bridging such as rate adjust in CamillaDSP.
Have you tried the Mk5 internal loopback? In my experience it does not drift, shows 0 ppm in REW and can use rectangular windowing.
Michael
mdsimon2
Major Contributor
Maybe Motu not happy with their ranking here and want to claim top spot
That test is entirely based on frequency response (magnitude / phase). DC roll-off will have a huge impact on the results as shown in the plot below (source = https://gearspace.com/board/showpost.php?p=15781315&postcount=2490).
To prove this point further, I was able to improve the Mk5 null from -46 dB to -86 dB by applying EQ and could probably do better with more optimization.
Michael
I use the aggregate to take Apple Music's 7.1.4 Atmos audio and send it to Reaper to apply DSP before sending it to speakers.
The problem, however, is that Core Audio does ASRC, so clock fluctuations, even if not coming from the mk5 oscillator, introduce signal modulation, i.e. spectral broadening. In fact when I measure in REW a more or less periodic tones broadening is evident below -120/130dBFS (not that I'm concerned about audibility).
The developer of BlackHole seems to want to introduce the hardware clock synchronization function in the paid version, just to get around these problems (even though Core Audio's drift correction works, it's not the best method in fact). But at the moment this version doesn't seem to have a timeline.
I tried to edit the source code of BlackHole, which is open source on GitHub, but I was only able to exploit the "Internal Adjustable" clock function, changing the resolution of its adjustment from 20ppm to 0.1ppm. In this way, in fact, I can bring the drift measured by REW from 31-32ppm to +/- 0,5ppm, with the aforementioned fluctuation.
The problem is that it olny has 2 loopback channels...
However, yes, I tried several times and it is always zero drift, but I don't see how it could be otherwise since the clock between in and out is the same.
Even in a loopback in the analog domain (TRS Out to TRS In) the phase noise of the internal oscillator is practically always the same so the modulation is the same between out and in, canceling itself out in the digital domain (net of the delay due to the DA-AD process).
In any case, if the phase noise of the mk5 oscillator was as bad as the drift fluctuation shown in REW may indicate, it would create a modulation of the signal in the analog domain corresponding to a spectral broadening proportional to the noise density.
Anyway, from the measurements in the analog domain of Amirm there does not seem to be anything relevant.
This does not exclude the existence of defective or degraded units, however...
So, the only way to see the effects of clock fluctuations (regardless of whether they are modulated by Core Audio's correction or by a possibly fluctuating mk5 clock) is to measure the dac output...
If you could measure the effect of Core Audio's correction with the CosmosADC it would be indicative of where things stand.
The fact is that it seems very strange to me that using the mac built-in speaker there is no fluctuation... I don't think it use the same oscillator as the main system.
Last edited:
mdsimon2
Major Contributor
CamillaDSP indicates that pitch control has been implemented in Blackhole since 0.5.0 -> https://github.com/HEnquist/camilladsp/blob/master/backend_coreaudio.md. This feature adjusts the rate of the virtual clock and involves no resampling.
I installed Blackhole-16 on my Mac and pitch control seems to work perfectly. When I start CamillaDSP I get a message saying, "The capture device supports pitch control" and the Blackhole clock source in Audio MIDI setup changes from Internal Fixed to Internal Adjustable.
In CamillaDSP I see slight adjustments to rate adjust factor (0.99999 to 1.00001) and the buffer level seems stable around my target level. With a setup of Blackhole -> CamillaDSP -> Mk5 analog out -> Mk5 analog in, I get 0.0 ppm clock drift in REW and can use rectangular windowing.
Does Reaper have the ability to adjust the Blackhole clock? If not, I might consider switching to CamillaDSP if you want to avoid the Core Audio resampling related to drift correction.
Michael
I installed Blackhole-16 on my Mac and pitch control seems to work perfectly. When I start CamillaDSP I get a message saying, "The capture device supports pitch control" and the Blackhole clock source in Audio MIDI setup changes from Internal Fixed to Internal Adjustable.
In CamillaDSP I see slight adjustments to rate adjust factor (0.99999 to 1.00001) and the buffer level seems stable around my target level. With a setup of Blackhole -> CamillaDSP -> Mk5 analog out -> Mk5 analog in, I get 0.0 ppm clock drift in REW and can use rectangular windowing.
Does Reaper have the ability to adjust the Blackhole clock? If not, I might consider switching to CamillaDSP if you want to avoid the Core Audio resampling related to drift correction.
Michael
that's what I was trying to do by editing the blackhole source code but I was not able (adjust the blackhole clock according to the USB interrupt of the MK5).
CamillaDSP is unknown to me honestly.
I should study it ... but does it work with Core Audio or needs Pipework or Jack?
mdsimon2
Major Contributor
No need to use anything other than Core Audio (and Blackhole).
Download and unpack a precompiled binary (camilladsp-macos-amd64.tar.gz or camilladsp-macos-aarch64.tar.gz, depending on if you have an Intel (AMD64) or ARM (aarch64) Mac). I usually move binary to /local/bin/ so I can run it from terminal by just typing camilladsp. The base installation assumes you have ~/camilladsp/coeffs/ and ~/camilladsp/configs/ directories to store configuration files and FIR coefficients.
There is also a web-based GUI. Install that by downloading and unpacking the bundle (bundle_macos_intel.tar.gz or bundle_macos_aarch64.tar.gz). I usually unpack the bundle to /opt/ and use it by running /opt/camillagui_backend/camillagui_backend in the terminal.
To run camilladsp with the GUI, I typically run camilladsp -s ~/camilladsp/statefile.yml -w -g-40 -p 1234 in the terminal.
"-s ~/camilladsp/statefile.yml" tells it you are using a statefile which will point to the configuration you apply in the GUI
"-w" tells it to wait for a configuration from the GUI
"-g-40" applies a -40 dB gain to start, you can delete this if you don't want any attenuation applied at startup or change to something else
"-p 1234" tells it use port 1234 for the websocket server (default for the GUI)
To access the gui, point your browser to http://hostname:5005 can also use IPADDRESS:5005.
If you want it running all the time you can automate using a plist.
If you want automatic sample rate switching, take a look at camilladsp controller -> https://github.com/HEnquist/camilladsp-controller, but I would explore this once you have a basic setup working.
Michael
Download and unpack a precompiled binary (camilladsp-macos-amd64.tar.gz or camilladsp-macos-aarch64.tar.gz, depending on if you have an Intel (AMD64) or ARM (aarch64) Mac). I usually move binary to /local/bin/ so I can run it from terminal by just typing camilladsp. The base installation assumes you have ~/camilladsp/coeffs/ and ~/camilladsp/configs/ directories to store configuration files and FIR coefficients.
There is also a web-based GUI. Install that by downloading and unpacking the bundle (bundle_macos_intel.tar.gz or bundle_macos_aarch64.tar.gz). I usually unpack the bundle to /opt/ and use it by running /opt/camillagui_backend/camillagui_backend in the terminal.
To run camilladsp with the GUI, I typically run camilladsp -s ~/camilladsp/statefile.yml -w -g-40 -p 1234 in the terminal.
"-s ~/camilladsp/statefile.yml" tells it you are using a statefile which will point to the configuration you apply in the GUI
"-w" tells it to wait for a configuration from the GUI
"-g-40" applies a -40 dB gain to start, you can delete this if you don't want any attenuation applied at startup or change to something else
"-p 1234" tells it use port 1234 for the websocket server (default for the GUI)
To access the gui, point your browser to http://hostname:5005 can also use IPADDRESS:5005.
If you want it running all the time you can automate using a plist.
If you want automatic sample rate switching, take a look at camilladsp controller -> https://github.com/HEnquist/camilladsp-controller, but I would explore this once you have a basic setup working.
Michael
From an initial test it seems very nice, although cumbersome. In my case, however, it seems that it cannot replace Reaper, since cannot load plugins, perform automations or use MIDI controllers.
I should use it as a parallel layer just to keep the blackhole clock adjustment, but it doesn't seem elegant to me as a solution...
I prefer to edit BlackHole to synchronize directly with the hardware interrupt of the MK5. If CamillaDSP performs the blackhole clock adjustment means it detects the MK5 interrupts, so I could analyze the source code to take a cue on the method. Too bad it's in Rust and I don't know it much...
I will ask ChatGpt for help.
Anyway, I remain with the initial doubt... that is, if the fluctuation of USB clock is also present on the DA-AD stage of the MK5. I repeat, the strange thing is that the built-in speakers from Mac do not present any fluctuations.
I think I will buy a USB-SPDIF interface on Amazon to see how it behaves, both alone and as a clock source of the MK5 (obviously the PLL of the MK5 is based on its internal oscillator so SPDIF clock source will not be able to improve its performance, in fact I do not expect differences).
mdsimon2
Major Contributor
The most straight forward explanation is that Blackhole and the internal DAC use the same clock internal to the Mac.
I've tried drift correction on a few different aggregate devices and there are always some fluctuations if they have different clocks.
Michael
mdsimon2
Major Contributor
Why did Motu raise the price tho?
I bought mine on Feb 2023 for $595, then a few months later they raised the price to $650 for NO reason, nothing changed or was added
It was released in April 2021 for $595 and since then there have been some hardware changes (new ADC for example).
Inflation alone from 2021 to 2023 would support a price increase to above $650.
To me it is more of surprise that it stayed the same price for so long, especially after a long hiatus shortly after release where it was unavailable due to part issues.
Michael
You can filter results for analysis to only be 20-20kHz, to remove DC issues.
Better not to use EQ if you want to see the performance 'as is'
Definitely worth filtering analysis to 20-20kHz though
Regarding -46dB, was that using front mic input or rear line input?
I found rear line input to be better than front mic input
Since I do room correction measurements, I am more interested in testing loopback with front mic input
mdsimon2
Major Contributor
Filtering to 20-20 kHz will not remove the impact on phase response that occurs as a result of DC high pass behavior (or minimum phase DAC filters).
I just pulled up my initial unfiltered GS loopback for the Mk5 and here were the results.
Standard Loopback: -45.9 dBrms difference
20-20 kHz FIR filtering in DW: -45.9 dBrms difference
I understand the performance "as-is" and by using EQ I understand exactly what is needed to improve it. The EQ was developed by impulse inversion from loopback measurements.
To get a feel for the level of correction I am talking about see here -> https://www.audiosciencereview.com/...-adc-actually-exist.52223/page-4#post-1884969, in terms of magnitude response we are talking something like +/- 0.1 dB.
Rear input. For room correction the differences we are talking about are irrelevant. They are very small, and your soundcard calibration will remove frequency response variations caused by DAC / ADC from your acoustic measurement.
Michael
I also thought that they had the same clock, but in that case I see impossible the constant 5ppm drift measured by REW.
If the fluctuation is always present, it may indicate the use of a regulated control loop to maintain its stability, appropriately tuned to keep the various kind of distortions below a threshold.
If the correction were only proportional it could be unstable in fact.
I will look at how it is implemented in CamillaDSP out of curiosity, but if it is only proportional it would be interesting to observe it's stability. Also because the resolution of the Core Audio clock adjustment feature of some devices is approximate and in any case not standardized. BlackHole for example comes with 20ppm resolution every 0,001 step of the slider, and it does not seem to me that the driver is designed to receive a different parameter from an app.
8KHz sounds suspiciously like noise caused by USB packet timing (125 μs). May want to try a USB isolator, powering your PC from a battery, etc.
Hmm but same is not there with rear input? As shown above
I'll try with Topping HS02 isolator
Possibly there's a different analog leakage current path from the rear and the mic inputs.
Damn the Topping HS02 isolator doesn't work with Motu. I even put a USB hub in between which sometimes is needed with other USB DACs.
Cuemix doesn't see the DAC at all with Topping isolator in between. Damn
Similar threads
