Don’t know how Apfel exactly connected his Ff 800 via FW to his imac.
Maybe you are right and he used TB at all.
But this is not the discussion here at all.

Fact is:
M1 USB Ports have no (general) USB problem with DK or kexts.

thx for clarification, Apfel.

The bus is .. well.. the same. It's all connected to the M1 chip and I believe switches operational modes, sharing resources. Look up information on SMMU for more details.

I'm inclined to agree with you. Then again I believe there is a silent majority who have had no issues with their audio interfaces, they just never wrote in this forum.

because of other variables such as your peripherals' topology, especially PCI-ish stuff like NVMe drives, hubs, external displays, which we haven't had any clear answers about in this forum. you're likely to find so many threads on this, just browse the forum.

Hey! Somehow I cant attach an image to you show my USB fireface configuration: I´ll leave a drive link so you guys can check it out! 
https://drive.google.com/file/d/1_bIBUp … sp=sharing

What is there to check out?

Hi, been lurking here for a while and would like to first thank everybody who contributes to help others!

I have dropouts on the following combination with minimal CPU and RAM load:

- Apple MacBook Pro M1 Pro (32 GB RAM)
- Sonoma 14.7.2
- RME Fireface UFX III (via the RME proprietory USB transfer mode; no matter which safety offset)
- Currently running on Kernel Extension Driver 3.33 (but, I tried the same with DriverKit Driver)

It does not matter which USB connection available in my setup, USB cable used, directly or connected via (iVanky) hub, the UFX III as single unit at controller or sharing the controller, it creates more or less frequent dropouts.

The only factor that makes a difference is my LG 32UL950-W display:

- Connected via TB4 (no matter which available pathway): Dropouts
- Not connected or turned off: No dropouts

If I remember correctly, there has been a similar report by another user on this or another forum.

I have absolutly no dropouts when I run the UFX III via 'Iso Transfer Mode' with the LG display connected. Again, no matter which USB connection used available in my setup, etc. (s. above).

Edit:
After posting this, I realized I should try to run the LG display via HDMI instead (as I am not interested in its internal hub anyways and as this could be the cause for interference). Oddly enough, it made it even worse (higher frequency of dropouts) with the LG display being connected only via HDMI.

Better make sure to use the 4.18.

Thanks for doing the tests and the detailed report. Please note we can't fix USB performance when the issue is outside of our hardware and drivers. In your case I expect the OWC dock is not at fault  (they have always been stellar performers for me), instead the issue lies with the M3 Max, its internal design, under the hood drivers and/or the current macOS. Apple might silently improve this at some point of time, but who knows...

BTW, USB 3.2 is not used here. Neither by Thunderbolt (Mac to Dock) nor the UFX III (USB 3.0 from Dock to UFX).

MC,Ralf,  Which thread are you referring to about forcing USB3?  do you mean using ISO Transfer Mode as Turntabloid stated?  if so, I was curious bout that already and tried that too. 

Test 3 - UFX > OWC > Mac
shutdown mac and UFXIII then restarted fresh 20min test. This time, not touching the the max patch; just let it run.
7:24 - Glitch!
8:24 - Glitch!

Test 4 - UFX > OWC > Mac (turned on iso transfer mode in the USB Settings app)
7:09 - Glitch!
9:28 - Glitch!
10:39 - Glitch!

Yes correct!  I have zero issues when the UFX III is plugged in directly to my mac via the LogiLink USB 3.2 (type C) cable. I think this cable came with the UFX III.

I will say that I've had some other similar type issues with this OWC hub(https://www.owc.com/solutions/thunderbolt-dock) where I had to bypass it and go directly into the computer.  My previous OWC hub(circa 2016) was great, never had an issue.

But I tend to think this is an Mac OS issue too.  Just the other day Apple release 14.7.3 which fixed a nasty permission issue with oneDrive. Seems like Apple has been sleeping recently.

Finally, I did run a test forcing USB3 mode using the hardware settings on the unit and it was the worse performance of all my tests.

Test 5
2:48 - glitch
3:12 - glitch
3:26 - partial dropout(like the signal dropped out but the reverb in the max patch was still echoing.)
3:36 - dropouts
3:52 - big drop
4:15 - partial

Anyway, hope others find plugging in directly to work as a temporary fix.

There's a few threads on here with what seem to be the same core issue, following some advise on one of the other threads I managed to get a possible work around (its a bit too soon to be sure but 2 hours and no glitches so far...). It was to go to the front panel and navigate to the setup/Options/Interface mode and change from 'auto' to USB2', you have to disconnect the cable to the computer first, then you can plug the cable back in and the host light on the front panel should now be yellow to show a USB2 connection. This obviously is just a temporary work around and means we could have spent a damn site less on an audio interface if we're going to be stuck with USB2. If anyone else finds this thread because they're having the same problem then please post, I think it's helpful to know how widespread the issue is.

Though this should be the first thing to try, this sort of advice is far less clear cut than before. Even if it applies in this particular case, thinking about the USB-C cables we use to connect USB2, USB3, and TB equipment, and any respective docks, it's impossible to say if connecting the device to a dock or hub with a more stable chipset than Apple's own mutable protocol bus, wouldn't actually help. We simply don't know what's in the kernel, and it clearly is a confusing mess at this moment.

My FF UCX is permanently connected to a Sonnettech TB4 hub (Dual M.2), more specifically one of the SS USB-C ports at its front, using a USB-C to USB-B cable, and the performance is the same as every other USB port on the Mac that I've tried (DK meh, Kext great), and using the kext drivers I am enjoying a stable system at the cost of "adjusting" SIP.

If I read the posts around here correctly, RME seem to have adopted a "wait and see" approach, and I think it's obvious that Apple won't fix this any faster than they have so far.

It might be useful to share some tools and methods to help diagnosing what's happening under the hood. For example, using System Information > USB, I can see that my RME FF is connected to a GenesysLogic USB controller managed by "AppleUSBXHCITR" and there's nothing around it. At the same time my MixPre-D, connected directly to the back of the Mac, shares an Apple USB bus with the keyboard plugged in next to it and with my VIA/Orico USB3 hub connected to the front port of the Mac, driver "AppleEmbeddedUSBXHCIASMedia3142".

hope this helps.

It is not just connecting directly to computer. The propper USB socket should be used. And maybe certain USB sockets not being used by other HW (it depends on computer model...)

One has to have a look in device manager.

This isn't RME specific. If you want a reliable recording laptop, consider a PC [to finish these sessions]....

(NOTE: this was meant as an ad-hoc solution for these specific live recordings, with the user's M1 apparently misbehaving. It's not a general Mac/PC statement)

USB transfers are controlled by the host. Peripherals only send and receive data. So make sure you order a new DAW host, preferably not from Apple, trololo.

The frustration comes from being a huge fan of RME for almost a decade. Any time someone asked me what interface brand they should look at, RME was my first and only answer. Everything I’ve used has been rock solid. So imagine my shock when their interfaces stop working correctly and I’ve been trying to troubleshoot this for several months. I come across a forum to see it’s not just me but others are having the same issue I’m having. I’m in the middle of recording 80 groups across four days, two days where I’m also filming but can’t sync the audio to film because of the same glitches unless I rebuild the DurRec recordings (which I’ll admit is easy but I’m in a time crunch and every minute is useful to have). I’m experiencing how this persistent issue is causing problems with my workflow, when my RME gear for years was one of the few consistently well working things with rock solid performance, and posting that I was having the same issues as others is responded with “buy a PC”…yeah, you can say I’m frustrated.

Good luck everyone who’s experiencing the same issues. I hope this gets resolved. But I’ve got work to do and can’t wait for a solution that’s apparently never coming.

Okay, fair points you make so let me work to clarify some things on my end.

"You don't seem to be expecting a quick solution from Apple, why is that? What makes you so sure that your "campus laptop" is a reliable and stable audio recording system to begin with?"

I typically use my M1 Max MacBook Pro 16" mentioned in my original post (2021, currently running 14.7.4). Our campus laptop mentioned (running 13.7.4) was one I started using this week in hopes the issues were simply with my personal laptop, however they are there as well.

The campus laptop has been used by students to record ensemble concerts with our UFX+ system BECAUSE WE LIKE RME. Please don't get the impression we are not fans of your work. Our program specifically purchased this unit because for our private freelance work, which for me doesn't just include on-location recording but also mixing, sound design, production, and film composition. My RME interface has been at the core of that work for 10 years. Our students have enjoyed working with this interface as well and used it for their projects. This laptop was for them to specifically have something to use for campus projects and their own. My personal laptop started showing the issues mentioned in this forum (and there are two other forums I found mentioning this same issue as well) in November. This campus laptop started showing these issues this week. My laptop has shown issues when using our UFX+, my UFX II, or my Digiface Dante with other tasks as well such as mix or stem printing in Pro Tools.

And yes, Apple is never free from blame regarding our work. Don't get me started on their lack of working with getting ARA working in Logic on these M-based machines...

"Did you ever test the setup before attempting to do critical live recordings with it?"

Of course! I reverted to the kernel extension driver on the campus laptop last night, after removing the Driver Kit driver, to see if that would help. I then used loopback to record eight tracks of various noise generators within Logic Pro 11 for two hours to test for glitches. Luckily, nothing happened, but today during recording I had dropouts occurring during the two-hour mark (these are happening around the two to two-and-a-half hour mark of recording nonstop). During our lunch break I reinstalled the Driver Kit drivers and turned off the use of System Extensions in Recovery Mode. Dropouts continued to occur.

"Have you tried increasing latency while recording? Or tested other software?"

Yes, I typically run a buffer of 512 or 1024 since I'm monitoring directly in TotalMix FX. These issues have happened with Pro Tools 2024, Logic Pro X and 11, Nuendo Live 2 and 3, Reaper 6, and Ableton Live 11.

"The reputation of RME devices doesn't come out of nowhere, and if at some point, a certain type of computer doesn't deliver as previous systems and other platforms have been known to, and nothing really changed as far as the interfaces involved are concerned, does it not seem safe to assume that it could be the computer causing that?"

A fair point and I see where you're coming from. Again, our personal work AND your reputation is why we wanted our students to work with RME gear and why we do too. I thought maybe it was just my personal MBP, but it has happened with two separate M-based Macs now. I've also used the following interfaces for other similar tasks on campus with my 16" MBP with none of these issues: Antelope Orion Gen 3, Focusrite Red16 Line, Behringer X32, Allen and Heath SQ 6, Avid Pro Tools MTRX Studio, and Dante Virtual Soundcard.

"So if you need a way to just reliably records your live performances to a hard drive now, why not consider trying a PC laptop with e.g. Reaper? If that works better, you will not only have files that are intact without having to resort to the (apparently reliable) Durec backup, you will also have determined that the interface is not the cause of the glitches in your recordings. And then you can look for a solution later if you wish/have to work with the "campus laptop" again."

We will probably need to do something like this now in the meantime. And I got a good chuckle from your passive-aggressive "apparently reliable" quip about DurRec when I spoke about how I for a long time have sung the praises of your products because of their reliability and my aggravation comes from this happening now and I feel validated seeing that it's not just me it's happening to. I'd also like to say I'm far from some Mac purist and frequently use Windows when working with Wwise and Unity and feel completely comfortable working with Windows. I just don't want to have to buy another laptop with our money that could go to other things in our program. I've also used my MPB 16" with my RME UFX II or the UFX+ for three years without any of these issues until this past November.

"You may be looking in the wrong place."

You literally have people in this forum, and other forums on the RME User Forum, with the same or similar problem of dropouts during recording or playback or use in general trying to figure out what's going on. I don't know if I upset you because I posted this with a bit of time between the last post, but I posted because I wanted you all to know it's still happening to others. If the attitude is "you're looking in the wrong place" when all of us have come to love working with RME products and we're hoping there will be a solution so we can continue to enjoy your products, well I don't even know what to say to that.

That's cute, seeing as three of the devices I listed used USB to run at least 32 inputs with no issues and that I downloaded the same driver you speak of and still had the same issues. Oh, and I've downloaded every updated driver as it's come out in hopes of a fix. Guess reading comprehension isn't your strong suit, is it?

Enjoy your time being smug instead of helpful

...that 'work-around' doesn't support the Digiface Dante - yet. We have plans to shortly add the CC mode for the DF Dante so it could be used that way as well. It might be the last resort (again) for issues like this with USB-3 high channel count interfaces on current macOS.

What changed since then? Would you assume the UFX units suddenly became unreliable?

they're not.

@lyric88

For me, even a 11y old PC build (Windows 10 Pro) works still excellent with outstanding performance when it comes to audio processing. I am able to play back a Cubase "artificial test projects" with 400 tracks and 803 VST without audio loss.
This with UFX+ and now UFX III using USB3 and at the smallest ASIO buffer size of 32 samples at 44.1 kHz / 64 samples at 96 kHz.

You need to get a system which matches the Near-Realtime processing requirements of a DAW system.

The ability of a system to process audio well doesn't have something to do with benchmark performance, name of the brand or price. You need a system which works internally in an "efficient way" so that it can work reliably for audio processing without loss.

Even for Windows Desktop systems, this is sometimes challenging depending on how well the mainboard, BIOS and the drivers are. Disabling energy saving is mandatory and to use the power profile for giving you best performance.
Bad drivers can block CPU cores for too long, resulting in higher DPC latencies. If audio related processes are scheduled to run on such a busy core, then audio loss can occurr, especially when using smaller buffers.

Even worse it is with Laptops where energy saving can not be disabled entirely otherwise it would heat up too much. With laptops you can also run in thermal issues, then you can observe a throttling of CPU clock (if certain thresholds are exceeded) to prevent overheating / damage of components. When throttling happens, audio drops can occur.
Look at notebookcheck.com how many laptops are not suitable for audio processing, because they have too high DPC latencies: https://www.notebookcheck.com/DPC-Laten … 375.0.html

According to LatencyMon (measuring tool for Windows which induces a typical DAW load to the system) DPC latencies need to be under 1ms, where values close to 1ms can be regarded as bad already. The lower the values, the better as it increases the chance to be able to work with lower buffer sizes to have lower latency for processing/monitoring. My system has for example 13-90 microseconds DPC latency, if IDLE, not 1000 (1 ms).

Sadly, Apple seems to make design decisions without taking care of near-realtime demands for audio processing or doing some thorough tests, although they also sell a DAW product (Logic).

If you do not have the knowledge, then get a turnkey system for audio. There are real reasons why such company still exist, they are not only there to take higher prices for the HW and enrich themselves from you. There are excellent companies, who put many efforts into testing their HW components, using good working drivers and finally fine-tuning the system for audio processing. Some also create Windows custom laptops with selected HW components/drivers, in case you need a laptop for whatever reason.

It is not sufficient to simply buy an Apple and to expect it will work fine. Most of their systems are laptops, which have their set of problems, also in the windows world. And Apple did some design decisions for the sake of security. But for audio processing, kernel drivers are better (higher priority) compared to being a user process under the hood of the process scheduler.
RME can offer only workarounds, that can improve it. But the real fix needs to come from Apple. Possibly best would be to re-enable drivers to run in kernel mode to improve performance for customers which use recording interfaces with a high number of channels, where issues seem to occur more often. Some finetuning of USB drivers and background services might also be needed.

What I want to say, a recording PC / DAW is not like an Office PC or a machine performing rendering tasks where it is unimportant, when the data arrives. Here you have to meet the requirement of being able to process audio in near-realtime and the CPU cores may not be blocked for too long by e.g. bad drivers.
Also not beneficial Apples move that drivers may not run in kernel mode anymore, where they would have the highest priority.
This is a design decision by Apple for their OS which only honours security topics, but which is not beneficial for audio processing.
Security is not unimportant, but you shouldn't overdo it either - at the end of the day, you want to be able to work well with a system. Security should not become an end in itself.

To sum up, most likely best performance is being achieved with a desktop system especially when working with recording interfaces with a high number of channels. Also there you need sometimes to follow best practises, like e.g. isolating the recording interface behind a dedicated USB3 PCIe card with a supported USB3 controller. On my system all works extremely well with a Sonnet USB3 card with Fresco Logic USB3 controller (FL1100). In the same system on the same PCIe slot a card with ASM3142 USB3 controller I am also getting issues.

i have a FF802FS and a M1 MBP w/Sonoma. had the stutter problem since buying the FF802FS. today i downloaded the newest driver kit "driver_usbdk_mac_421.zip".

now i have installed this one and the latest kernel. when opening the RME fireface usb setting panel i read "driver 4.21" in the corner. but the stutter got worse than before installing it.

how can i switch to using the kernel one? just to see if that one works better? do i have to delete everything manually and re-install one-by-one and try?

OMG it is worst then I thought. I lost the confidence on my flagship rme interface now, if it glitches, it could be introducing smaller digital artifacts even when it's not glitching ? Sometimes it is even introducing long digital beeps. What should I do, there's no definitive solution to this yet ? I've seen it's been a long time issue, where is the RME engineering team ?