Please try a different USB cable and/or USB-C port. Directly to the Macbook with no hubs.
Also test USB 2.0 mode. See manual and look for "interface mode".

No hubs, directly connected, everything else disconnected. Tried two of the ports, no difference. I am not using USB 2 as I need the Madi channels, that is why I bought the interface in the first place.

I also won't use class compliant mode, as I need TM, which is the other reason why I bought the interface.

Reading for hours through the various posts on this forum I have collected the following info, although nothing is "official"

- M1 USB audio has a problem, Thunderbolt doesn't
- the v3.3 Kernel driver might help, as one can set a higher buffer value, but Apple is discontinuing direct access to the Kernel, which is why RME has driver v4.7
- USB2 has no problems, because less channels mean less data. That is also why other RME interfaces have no problem, like the BabyFace.
- class compliant mode might solve it (not sure why it should, maybe higher buffer settings?) but then TotalMix is not available anymore except through an iPad - more clutter & devices, not less, I don't like it.
- it seems to be an Apple problem that also other interface providers struggle with, but nobody has heard anything from Apple regarding a fix.

--------

Meanwhile I did a couple more tests. I tried to open a lot of memory-hungry applications and sometimes, audio will stop for several seconds if I do so. ActivityMoniror did not show any memory swapping.

Also, when I play audio, sometimes it doesn't simply stop but does have some distortion before it stops. Looking at what happens to the sine wave test signal, it is very well possible that I hear some distortion in an audio signal before it is shut off.

Obviously, RME won't be able to help much or else this wouldn't be an issue anymore.

It seems to me that issue is not solvable from our end at this time. I will consider the UFX+ instead, which has Thunderbolt.

ups… I was too optimistic. Just had a some crackling with no memory pressure whatsoever, and no load on the CPU. I think the choice is clear. Bye bye UFX III - it was nice while it lasted.  Fingers crossed your 8 year older sibling has what it needs.

Works flawlessly here. No dropouts or sth.

Maybe it had to do sth with your MacOS related config?

Tested with:
UFX III (latest Firmware) connected directly via USB3 to:
MacStudio M1 Max
Sequoia 15.1.1
DK v.4.17

---
Edit 2024.12.25:

I just deleted the links to pixshare, as they replaced them (after expiration) with big commercial links to their website.
I don't like to be a spreader of such practices...   
---

deleted image

---

deleted image

---

deleted image

---

deleted image

Thanks - anyhow the topic is closed for you, I just would like to reproduce and understand your issue.

Ok, i did a new test today - tried to max out CPU load, RAM and the USB3 throughput. Believe me or not - i had dozens of apps running at the same time....

Let me describe - all things here were running at the same time:
- UFX III was recording via DUREC to a USB Stick
- Ableton was sending a sine Wave at 0dB and recording the AES Playback to the blue track
- Ableton was set to simulate the max cpu load (80%)
- The clip RAM was also set for all Tracks
- browserbench jetstream was also running
- I even started two instances of an app which played some Audio in Xcode (the red marks in screenshot) to add additional load on cpu, RAM, CoreAudio and the USB3 Bus (one instance on simulator, the other directly on my Mac)

Result:
- I cannot hear or see any dropouts.
- Nothing wron in the durec recording or abletons direct record.
- Cannot confirm this at all.

Let me ask 3 Questions:
Did you really record a sine wave for 2 hours, to look if there are dropouts?
How did you do it (as the browserbench thing just rans for 1,2 minutes)?
How much RAM does your M1 MacBook have?

BTW: I also cannot confirm your statement: "USB2 has no problems, because less channels mean less data. That is also why other RME interfaces have no problem, like the BabyFace."
Because you mix USB2 and USB3 in a total different context.
-> USB2 class spec defines 480 MBit/s transfer rate as maximum. Thats enough for less channel units.
-> While USB3 is specified at 5 GBit/s max. Thats enough to transfer all channels the UFX III needs (if properly connected to a USB3 controller on the Mac).

Here my screens:

Edit 2025.01.04 deleted expired image links (reason: see my post above)
----

deleted image

---

deleted image

See post number 9
The difference i see is Sonoma vs Sequoia.
As your software runs fine on Sonoma it will have no issues on Sequoia (it is in use now for a time)
Let's hope the upgrade will solve the isseue, unfortunately I don't know any other magic trick.

And there is no guarantee for the fix.
You are right, there is a lot of reports about dropouts, but the huge majority who has no issues and therefore do not report anything, this is invisible.

I'm sorry to hear that, A total fresh install is what I also would do, I guess.

Sonoma and Sequoia behave(d) exactly same here. I just always updated with new releases of MacOS, but never reinstalled a whole system (same for Linux and Windows) for more than 10 years or since the (win95 era is past ;-))...

So, I wonder how the rumor still exists today, by hoping a fresh install will fix everything, instead of trying to get the real cause...

To mention (again) I usually do not do single (one-file) recordings of (multiple) tracks for multiple (or 6 and more) hours.
If you do so, hundreds of reasons can cause dropouts...
Without further details, it is always just a guess. Impossible to give a proofed solution.

Anyhow some examples and tipps, you could check:
- Keeping the (general) formula in mind:
    File size (in bytes) = Sample rate × Bit depth × Channels × Duration (in seconds)
    This would be ~8GB for a 6 hour, stereo, 48kHz, 32bit float recording file (!)
- Afaik (not sure), Spotify usually plays its songs at 44.1kHz? Maybe better to switch your unit to this?
- Do you record into RAM or directly to a file?
- If RAM -> its not endless...  after a while, Mac will cache it to disk (see the swap-thing in this thread)
- Any other processes suddenly get active which affect RAM/Disk writes?
- Any other processes suddenly make use of the same USB controller?
- USB Cable physically 100% OK?
- Tried to raise the buffersize in Pro Tools?
- No other devices or sw that could interfere?
- Checked the RME Settings App for CRC errors?
- Used the Activity Monitor App for an spikes?
- Had a look in the Console App if there are some relevant logs during dropouts?
- etc... etc...

Edit: I addressed this to Tinball.

@fables, yes - i wanted to show that i was not possible to max out my RAM with "usual" apps.

But i am on 64GB RAM here...
Ok - so i just wrote a little bash script, which constantly pumps some data into RAM:

#!/bin/bash

# This script stresses the RAM by allocating memory in blocks of a specified size.

# Function to stress the RAM
stress_ram() {
    local data=()  # Array to hold the data in memory
    local block_size=$1  # Block size in MB passed as an argument
    local block_size_bytes=$((block_size * 1024 * 1024))  # Convert MB to bytes
    local counter=0  # Counter to track the total allocated memory

    echo "Starting RAM stress test with ${block_size} MB per block. Press Ctrl+C to stop."

    # Infinite loop to allocate memory
    while true; do
        # Generate a block of data and store it in the array
        data+=($(head -c "$block_size_bytes" </dev/zero | base64))
        counter=$((counter + block_size))  # Increment the total allocated memory
        echo "RAM usage: ${counter} MB"
        sleep 0.1  # Short pause to make the process observable
    done
}

# Check if block size argument is provided
if [[ $# -eq 0 ]]; then
    echo "Usage: $0 <block_size_in_MB>"
    exit 1
fi

# Call the stress function with the specified block size
stress_ram "$1"

Running the test again (for about 40 Minutes now)...
Till now: No dropouts...
Will post the results when the 64GB are reached.

Edit: Here my result:

It seems that Apple does som kind of magic?
After the RAM was nearly 64 GB, the Mac swaps it to disk. I noticed  it by constantly lowering my free disk space.
Although, the RAM pressure is and was always green. And although my script was constantly pumping data into RAM.

Believe me or not, but i could not find even one dropout in the recorded sine file in ableton.
UFX III was connected via USB3 during this.

fables, (for me) your descriptions are not clear enough to be able to reproduce your issue.
Anyhow, I tried my best, to reproduce your issue while showing what i did as transparent as possible.
But without concrete facts and ability to reproduce what you did... I cannot confirm this at all.

Thanks for sharing

I have the same problem. Random dropouts during audio or video playback, recording or playback from Nuendo.
MacOS 14.7.2, Macbook M1 Pro, 32 GB, DK 4.17, UFX III

I have also seen in the activity display that the USB driver has a very high CPU consumption during normal playback of a WAV via Quicktime. What is going on?
As a RME user for over 10 years, I am really disappointed for the first time

I still don't understand why RME doesn't continue to use Thunderbolt. Other manufacturers also manage to offer Thunderbolt 3 interfaces. The fact that intel doesn't want audio interfaces via Thunderbolt is nonsense. Why should Intel care what the chips are used for? And as long as there are PCI to Thunderbolt enclosures, surely it must be possible to install something like that directly in an audio interface.

It's been explained here clearly and many times. If you still don't understand it, read it again repeatedly until you do.

If the host system is incapable of reliably working with USB audio interfaces, why should we assume it will work better with a Thunderbolt interface? Just because the USB implementation in the hardware or in the OS kernel is buggy, so we can hope that PCIe stack is better implemented? It's a fallacy. At least USB specification is straightforward to implement. Thunderbolt has been a buggy mess since its inception, and now that its 3rd generation has been included in the USB4 specification as a subset, its future is even more vague.

"Mac" and "professional sector" is an oxymoron. Or do you believe that anything you can buy at a retailer that has the word "pro" in its name is automatically suitable for commercial use? Yes, some professionals manage to use it for their work, but it does not make it a "sector".

As it as been shown here, there is nothing "rock solid" in this quirky, buggy, and inherently insecure interface. And even the FireWire with a much wider support had been eventually killed off.

Why no way. These interfaces support USB protocols, so there is a way.

Basic USB 2.0 stack has achieved adequate performance, stability, and latency, and SuperSpeed USB specifications improve on that. So if your DAW struggles to work with multichannel USB interfaces, switching to Thunderbolt will not fix that, if not make it even worse.

I was having more dropouts on Sonoma. With OS 15, I'm getting fewer. RME tech support was asking to watch my Activity monitor to see if the problems begin when 60% of RAM is in use. It happens whether I'm using 50% of the RAM or 90%.

Pro Tools is running rock solid now. I've only had one dropout in the last couple of days. I'm running 32k buffer and a 96k session. Lots of virtual synths, recording 12 tracks at a time. No issues.

Spotify - This is where I'm experiencing the most dropouts. I've tried listening only in 44.1k since that is the rate that Spotify streams. Still an issue.

I switched to Apple Music. I enabled lossless hi-res streaming. I've been streaming a whole bunch of music marked as hi-res lossless and have the UFX set to 192khz. I have heard only one audio dropout in the past 48 hours.

Long story short, after re-imaging my M1 and going through endless troubleshooting, it seems my system has settled down a bit. I really think Spotify is the main issue with streaming dropouts. I'm not having any issues with Apple music.

*shoulder shrug

Hey guys, nice to meet you all

Just bought an UFX III, installed the Kernel Extension and still having random dropouts.

M1 Pro, 16GB RAM, Sequoia 15.2.

Wondering if this will get fixed at some point or should i just return my interface and get something else. I hate the situation as i love the UFX, it sounds amazing when it works.

@maggie33 what kind of setup do you have? i'm curious as you are saying you have no dropouts, you said 64GB RAM but could that be all? If that's the case i'll just update to an M4 with lots of RAM )

Thank you,
Bogdan

I may have missed the part where you specified what kind of mac are you running on, like cpu and OS version, sorry.

Thank you for pointing me in the right direction

https://imgur.com/a/JCtuqDS

You can only offer what’s available. Naturally, Thunderbolt (TB) was marketed as the superior interface when it was still around – that’s just how marketing works ;-)

Regarding TB vs. USB2/3

I have already demonstrated in this forum that UFX+ using USB3 handles even 100% CPU load and a minimal ASIO buffer size of 32 samples without any audio dropouts, see https://forum.rme-audio.de/viewtopic.ph … 2#p210092.
Or see also my artificial benchmark with a large 400 track Cubase project (UFX+ vs RayDAT: https://www.tonstudio-forum.de/blog/Ent … s-de-en/).

The lack of Intel TB1, TB2, and TB3 chips has been openly explained by RME in this forum. They also made it clear that implementing TB4 is not feasible due to complexity.

So, what exactly is being sugarcoated? What’s there to criticize about RME or this forum? AFAIR neither RME nor the forum have misrepresented anything. The facts were communicated transparently. Otherwise please deliver URL references for your claim.

to "Apple and TB/USB"

Even during Apple’s struggles with USB3 drivers and their custom communication chips, solutions were available. For example, users could buy TB docks with integrated USB3 chipsets. In the PC world, we sometimes add PCIe cards when needed.

to "Big/Little"

The "Big-Little" CPU issue seems to stem from the fact that none of the manufacturers involved conduct specific tests for audio applications. But there are solutions for this, at least for Windows based systems:
- BIOS profiles that allow disabling efficiency cores,
- Process Lasso Pro, which can assign audio processes to performance cores or
- to simply avoid Big-Little CPUs entirely or
- more pragmatically, to purchase a pre-built and tested system.
The latter is ideal if you’re unsure or don’t have the time or expertise to deal with such issues.

As you rightly pointed out, these are not RME-specific problems.

There is nothing against TB, but also not against USB. I’m confident RME would support it again if it became feasible again.

to "the Forum"

What are your main concerns regarding communication and the "way that RME and the forum treats this" concetete? You should be a bit more specific than leaving the things you complain about in such a nebulous state. So I can only interpret it this way ..

Regarding your claim that RME or even this user forum misrepresents or sugarcoats things is something I disagree with. In addition: since I’m almost the only person here regularly addressing performance topics, your criticism seems directed at me as well. So please clarify what you mean exactly not to produce unnecessary misunderstanding whoever is concerned.

I don’t recall ever misrepresenting or sugarcoating anything. When inaccuracies arose, I corrected them and backed them up with facts whenever possible. Are you seriously blaming me or another person for setting the record straight?!

To sum up

Of course you can be disappointed that Thunderbolt is no longer available, that's perfectly understandable. But please think about why this is the case what the causalities are.
But there is also no reason to make USB look worse than it is.

I also think that it is not fair to point the finger of blame at RME or the forum when nothing has been reported incorrectly or glossed over (why I answered to your posting).

Ultimately it doesn't change the facts that TB 1-3 chips are not available anymore from Intel (irony on: big thanks to Intel for this) and that an implementation with TB4 is not possible; RME communicated openly for what reason.

The USB products are running stable for plenty of Windows and Apple user. If this is not the case for your specific device, then please be so honest to open a case with the particular vendor and complain there. I understand this is tricky with Apple, as you can't easily add PCIe cards
(EDIT: at least it would be possible to use thunderbolt docks or external cases to get other USB3 controller on board so that UFX III or XT II worked reliable).
But is this all RMEs or the forums fault?!

Ok thanks, lets finish this topic, maybe misunderstandings on both sides.

In regards to complexity I found these information with ChatGPT. Note: I do not trust the bad quality of information, but it looks to me as if there are certain information which seem to explain what might be meant with "higher complexity".

TB 4 and 5 seem to implement so many functions that are not required for connecting a recording interface. It seems to cause many hurdles to achieve compliancy to the standards and to implement this all on a FPGA. Finally the much higher data throughput is also not really needed for audio processing which is also kind of a burden performance wise (for the FPGA).

Chat GPT: "Thunderbolt 4 and 5 are more complex compared to earlier versions (Thunderbolt 1-3) due to advancements in technology and the increased demands for higher speeds, compatibility, and additional features. These differences primarily stem from the following factors:
1. Increased Bandwidth and Speed:
    Thunderbolt 3: supports up to 40 Gbps.
    Thunderbolt 4: Maintains 40 Gbps but with stricter performance requirements
       (e.g., support for 4K displays at 60 Hz, minimum 32 Gbps for PCIe data transfer).
    Thunderbolt 5: Aims for up to 80 Gbps, a significant increase.
2. To achieve these high data rates, Thunderbolt 4 and 5 chipsets must be much more powerful and complex, making FPGA implementations more challenging.
3. Protocol Complexity and Functionality:
Thunderbolt 4 and 5 offer additional features such as support for daisy-chaining up to six devices, multi-function adapters, USB4 compatibility, and enhanced security features like data encryption.
These added capabilities increase the chip complexity, as they need to simultaneously support multiple protocols (e.g., PCIe, DisplayPort, and USB), and ensure smooth interoperability between them.
4. Compatibility:
Thunderbolt 4 guarantees backward compatibility with older devices, while Thunderbolt 5 adds requirements to support future technologies, adding further design challenges. Compatibility needs to work across various device types and with different cables, which adds design and testing requirements for the chips.

Challenges for FPGA Implementation:

Implementing Thunderbolt in an FPGA (Field Programmable Gate Array) poses several technical challenges:

1. Protocol Complexity: Thunderbolt requires handling multiple protocols at once (e.g., PCIe and DisplayPort), demanding high data rates and precise synchronization between the different transmission types. This can be difficult to implement in an FPGA, which is typically optimized for specialized tasks.
2. High Bandwidth Demands: For Thunderbolt 4 and 5 (up to 40 Gbps and 80 Gbps), the FPGA must be capable of handling high-speed interfaces and protocols. Many FPGAs may not offer the required internal bandwidth or would need to be paired with external components, increasing design complexity.
3. Protocol Complexity and Licensing: Thunderbolt requires specific licensing and adherence to Intel standards, which can add costs and complexity. Intel provides Thunderbolt technology as a proprietary solution, which makes integration more challenging.
4. Power Supply and Cooling: Thunderbolt 4 and 5 require precise power delivery and thermal management, especially at high data rates and power consumption. Implementing this in a compact audio interface may present additional challenges regarding heat dissipation and power requirements.

Given the challenges outlined above, especially the complexity of Thunderbolt protocols and the need for special licensing, it might not be worth the effort trying to implement this.
Furthermore this would most likely have significant impact on the price.

Moreover, USB ports are available on most computers and laptops, appealing to a broader user base. The complexity and requirements of Thunderbolt for FPGA-based solutions in a compact audio interface might have been seen as too costly and difficult to implement."

And do you think that if Apple has buggy implementation of USB3, that USB4 will make it better?

My baseline is that USB is just inferior to Thunderbolt for this situation because the implementation standards for manufacturers are not as stringent with USB, leading to the same kind of chaos as seen with the Apple chips.
This also leads RME to feel compelled to include a list of notes and compatibility information for USB3 chips in the manual. I just find this to be an undesirable situation, thanks to Intel.
Thats it.

Another drawback of TB is that many PCs do not have it. All AMD PCs and also some Intel ones. It means that RME would have to use the both TB and USB on interfaces.

UFX+ here.

The current and previous Driverkit drivers fundamentally do not work for me, current Sequoia, M1 Max MacBook.

I get:
1) random pops that occur out of nowhere, regardless of DAW load or buffer size
2) periodic invasive bursts of noise

This happens on both USB3 or USB2 connection, whether passed through a Thunderbolt dock, or directly connected to a USB-C port on the MacBook itself. The Thunderbolt Driverkit exhibits the same behaviour - Thunderbolt kext works however, but no lower than 64 samples.

My friends who run RayDats inside Sonnet PCIE Thunderbolt cages are running 32 samples buffer on either the Kext or Driverkit drivers, without any issues. The problem is unique to the UFX models.

Interestingly I hooked up my older UFX via USB2 and it has exactly the same issues on this Mac with the current drivers. Only the Kexts work, make of that what you will.

Just came across this.
Maybe useful for people who want to dive in a little deeper in this.
Just a a "basic" (=free) dev-appleid is needed to download the instructions and the profile...
https://developer.apple.com/bug-reporti … form=macos