Hi!

Same for me. Worked great on Monterrey (3.27, UCX II). When I updated to Ventura -> Stuttering and glitches. Now I have 4.06 but no difference. I have noticed that there is a lot less problems when the memory pressure (in the activity monitor) is green. When it goes to yellow the stuttering is unbearable. Seems to be some kind of resource thing. Any of you experienced any difference related to RAM usage?

Cheers
Terje

Yup, it's OS related.  However, it doesn't matter whether you're using an RME driver, or something else. It'll glitch like crazy.
The only workaround I am using for now for example with Pro Tools to stop it from crapping out mid recording, is to re-nice it to -20. Basically giving it priority over system events that it would normally flake out over.  Note, this will work for most DAWs.

In my case (Ventura 13.2.1 on Mac Studio) the audio glitches seem to depend on the application. I don't get glitches in Cubase, Logic or Dorico but when using Safari. After changing from Safari to Firefox the glitches seem to be gone...

RME tech support directed me here. Just wanted to throw my frustrating experience out there.

Just received my new Mac Mini M2 Pro. Installation of everything has been a breeze and really easy until I started setting up my RME Fireface UC.

Constant audio distortion/stuttering/crackling through all software running the driver: macOS, Pro Tools, Soundminer. Reminiscent of the sound of sample rate issues. Same issue whether I'm plugged into the Mac Mini or a USB 3 powered hub.

I've been able to make it temporarily work by unplugging and plugging back in the USB cord. But after awhile the distortion comes back, or instantly comes back after rebooting.

Here are my specs:
Fireface UC
Mac Mini M2 Pro
macOS Ventura 13.2.1
Firmware v138
Driver v3.28

What are my options as of now? Where should I report this to Apple to add onto the pile?

I'm gonna try this public BETA to see if anything changes.

EDIT: I tried this BETA 4.06 and now I'm not getting any audio at all. I have a YouTube video playing in the background and every 30 seconds or so I'll here a little millisecond slice of audio poke through but that's it.

Really hoping there's some kind of temporary fix here

Hi, mikejamesgal. Welcome to our un-merry little gang. Weird that they directed you here. We have found no universal solution. Personally I went back to 3.27 driver and got it working ok again after trying all sorts of antics with the 4beta driver and swapping usb ports and all sorts of stuff.

Total Mix FX is sometimes crashing and my UCX dissappears.
It will only show up again after a reboot.
It is not disappearing from the Fireface USB Settings.

It just happened now in the moment I plugged my Digiface USB.
As if the Digiface is pushing out the UCX from Total Mix FX (as far as I know Total Mix supports 4 parallel interfaces though and it works after reboot...).

Let me know if you need more info.

I am on Total Mix 1.80 beta 5 and 4.06 beta drivers.
MacBook Pro M1 13", macOS Ventura 13.2.1

You can try 4.07 with TM FX 1.80 release version:

https://www.rme-audio.de/downloads/driv … ac_407.zip

The crash that you reported sounds like the one fixed in TM FX 1.80 RC3.

I am using the braided USB-A cable that came with my RME802 and into one of the few USB-A sockets on the back of my Mac Studio. It works since I backed down to 3.27 driver.

Version 4.07

- Supports the UFX III based on firmware USB 19 DSP 6

- Improved installer

- Settings dialog checks for running RME kernel extension

New in TotalMix FX 1.80:

- Supports the UFX III

- Adds the ref level 'Boost' to inputs 3/4 of the Babyface Pro, with 9 dB more gain. Note: requires firmware 203 or higher.

- Improved: Using the ARC USB to close/open the TotalMix window had unexpected side effects under Ventura

- Bug fix Digiface Ravenna: MADI channels were shown as Ravenna channels when Names option was active

- Improved: switching the Digiface Ravenna from USB 2 to USB 3 did not show the additional channels without reboot

- Added support for 75 dB mic gain for the Digiface AES

- New function Offline-Device Setup (Optionws): allows to use TotalMix FX without connected interface, including load/edit/save of Setups and Workspaces

- New function Color in Channel Layout: the channel name can be white or shown in 7 other colors

- Change: Key focus is now locked when in background after start to avoid unintentional configuration changes

- Improved function to determine IP addresses in Network Remote Settings

- Bugfix Network Remote Settings: Deletion of a user did not work correctly

- Improved: Opening of Network Remote Settings device-dependent, avoids collision with mixer settings
- Improved function to determine IP addresses in Network Remote Settings

- Improved: Loading of user list in Network Remote Settings

- New ARC USB: can now control the makeup gain of the mic channel's Dynamics section

- New ARC USB: all encoder functions are now also available as 'Push' mode (only active as long as the button is pressed)

- New PFL mode: When in PFL mode the global Solo button (upper right) will switch off all active PFLs

- Fix: in rare cases connecting the audio interface could exit TotalMix

- Extended OSC support. The updated OSC table is here:

https://www.rme-audio.de/downloads/osct … fx_180.zip

The OSC table zip includes a new touchOSC template that showcases all functions.

New in Page 1: CUE control as channel dependent function, control of link speaker B, and the direct selection of a channel in Page 2 as a start offset of Page 1.

New in 'none paged' page: added setOffsetInBank and loadQuickWorkspace (these are no new functions)

- Various performance improvements and fixes

The zip file linked by MC was updated with release notes as well, so we know it's the official word. But in this context I'm not sure if FZ here is the chicken or the egg? Thank you very much FZ!

I installed 4.07 a few days ago. Did not expect any improovement in the sound dropout. At first it worked worked a few days and I thought that maybe the new install made it work. That was a wrong assumption. The problem is back. 4.07 is as glitchy as 4.06.

So I am going back to 3.27

Cubase 11 is not producing any sound! Cubase 12 is fine. System sound is fine! Can I go back to older drivers? I did not know that was beta

The MacOS Ventura update (13.3) dropped today and appears to have addressed those audio glitches and dropouts.

Definitely both.

As mentioned in my answer #161, I continued testing with my Thunderbolt Hubs:

No problems with the OWC Thunderbolt Hub and a USC-C to USB-B cable connected to the MADIface Pro.

A solution ?
What do you want ? A special custom built driver for your computer ?
What is that interface ?
What is the computer ? intel-Mac ?
Actual MacOS is Ventura 13.3
Actual driver is 4.07
Here MacbookAirM1 Ventura 13.3, driver 4.07, Babyface old, Digiface USB, Madiface Pro, no problem, music plays fine.

Yes, it's not the driver... it's the OS.. Ventura 13.3 fixes this.

@mattrixx Sry, I did not read your post. That’s good news! I will give Ventura a try now.

Latest update of Monterey 12.6.4 that came out a few days back! Its glitching so much that its not usable. Won't even play 4 bars before dropping out! I am in luck that I have my trusty old Fireface 800 that runs like a real RME that we know from so many years. To get the better conversion from the BF Pro FS, I have connected it thru ADAT from the Fireface 800 and my speakers are connected to the BF Pro... I just use the FF800 as a primary interface connected to my M1Pro MBP. FW> Thunderbolt>Thunderbolt 3. Even with all this conversion it runs perfectly! A sudden upgrade to Ventura is not possible as I have to wait for all my plugins to have stable support in Ventura. That will be the case with most professionals who need stability! I want to upgrade to a higher end interface from RME but I can't until I know for sure that this has been sorted. Companies like Universal Audio who are nowhere near RME when it comes to driver support have figured it out so I don't see why RME can't. Waiting is all we can do as when I contacted support, I just got back a rude and sarcastic reply!

Just to be clear, your account starts in 2022 with beta stage software, or? Please don't mix together stories about various versions with each other, as no-one have anything to gain from that. Even if you didn't, not making it clear is not helpful for others. Threads like these are for all beta users, not just for those of us that have problems.

Now when the 4.07 release is out, issues related to this should be posted in a specific thread, I think. Is there one?
EDIT
OK, created New macOS RME USB 4.07 (release) driver. If you agree the release should be discussed separately, feel free to post there.

Ventura 13.3 did NOT fix the issue for me. Nothing changed at all. When memory usage goes up, the stuttering/glitching starts.

MacBook Pro M1, 16gb RAM
Ventura 13.3
RME UCX II/ARC USB
Firmware 42, Driver 4.07, Totalmix 1.80(3)

Cheers
Terje,
Norway

Yes spot on.. actually Monterey was where all this started.. and we were blurred with whether it was  a beta driver, or OS...  We've driven the trails and thankfully, on top of a great RME beta program and some comms with apple.. It's working perfectly. Monterey or earlier versions of Ventura are not ideal. Ventura 13.3 is where the magic is back at!

I am glad that it's been fixed with Ventura, but sadly a lot of plugin companies have still not optimised their stuff for Ventura so an upgrade to a new OS is not possbile for a lot of people. Hopefully Apple can release an update for Monterey where this problem is addressed. Good to hear that the RME magic that we are familiar with is back!

EDIT: rephrased

Looking at the reports from some users, the audio dropouts seem to be related to the main memory fill level in some cases.
In this context, it could be that paging and swapping activities of the system (also) cause the audio dropouts.

Even if there is still memory available, operating systems try to swap currently not needed RAM to disk according to certain strategies rather early. This to be able to serve future RAM requests of applications faster and not to slow down applications until enough memory is free. Memory allocation is a dynamic process, it is not static as you might think. So, there is instantly the allocation and deallocation of memory going on in the background and a certain paging activity.

As paging/swapping is a critical function in the kernel and essential for any system, it is most likely that those I/O activities have higher precedence over normal system and user processes. Especially time-critical processes like audio processing could be quicker impacted (-> audio loss). For normal applications this has no impact, but for audio processing it has.
Same for macOS changes regarding memory management. So, the best is simply to have enough memory.

Therefore, it might have helped mattrixx, in his case, to prioritize Protools to -20 which is the highest priority for user and background processes on systems with Unix flavor. Still, kernel processes have higher priority and when it comes to important kernel related I/O processes they may not be interrupted.

Such strategies can also change between OS versions, why it can function in the one or other OS version sometimes better and sometimes worse.

In error reports that say that the problems get worse with increasing RAM load, I am missing concrete information about:
- how much RAM is installed in the system
- the CPU, and memory usage and
- how high the paging and swapping activity of the system is.
This could help to correlate issues with audio dropouts with available memory and swapping/paging activities of macOS.

mattrixx also reported that raising the process priority of Protools showed improvement. But this will probably not help in all cases.

Some personal remarks regarding DRAM capacity

My personal impression is that 8 GB of RAM equipment is a bit meager on a 64-bit system. That will lead to paging/swapping activity of the OS very early on. So if some issues come from too little main memory and increased paging/swapping activity, that will be the case more often (or always) with 8 GB.

But even with a 16 GB system, you might run out of memory if you simply need a lot of memory.
This depends on whether the DAW projects are large, how many and which virtual instruments are in use, and what other programs or background services are running on the system.

Turning off virtual RAM to eliminate a negative impact from paging/swapping - like some people in internet suggest - could only be considered, if one is sure to have enough main memory. But also see the reports about crashes.
I wouldn't recommend the deactivation of virtual memory for an 8 or 16 GB system, maybe only for a quick test whether a problem might be related to paging/swapping. BUT ONLY if there is enough RAM.
BECAUSE … if an operating system runs out of main memory, this will inevitably lead to a hard crash (kernel panic).
This is associated with data loss for open files, and a file system check is due because the file system cannot be closed properly. So be careful.

DRAM upgrade - where necessary / if possible

On systems where upgrading of memory is possible and where paging/swapping takes place, I would propose, to upgrade DRAM, to get more headroom and to be able to exclude paging/swapping as root cause.
By this, you would also proactively solve any potential issues, that could arise due to any future changes in the macOS kernel (when paging starts or how much performance it costs).

To what extent the Apple OS can be parameterized, when it starts to page/swap, I can't say. Others would have to look into this or ask Apple. In any case, main memory is a core issue for IT systems besides CPU performance, and paging/swapping should always be avoided if possible. This is a golden rule for all IT systems and especially for audio processing because delays in processing have to be avoided.

As a side note: who thinks now that 8 GB would be but already a lot, in earlier times everything ran even well with 4 GB…
Please keep in mind, applications are getting fatter and the word width of the CPU on machine level has increased from 32 to 64 bit. So, 4 GB DRAM is simply not enough anymore for a basic 64-bit based system.

Today's minimum for a 64-bit system is 8 GB DRAM, but that's also the "minimum". If you want more headroom, use 16 GB or even more (depends on your demand / projects / applications).
For a DAW, I would always recommend 16 GB as a minimum.

See also this webpage: https://www.pugetsystems.com/solutions/ … endations/
"RAM is an extremely important factor for performance in DAWs. Avid’s website lists 8 GB as the minimum, but later says, “32 GB or more recommended”. For real-world workloads and because multitasking is so common these days, we advise 64 GB of memory as a baseline, with options to go up to 128 GB for more complex projects."

Don't get me wrong, I am not telling everybody needs 32 or 64 GB DRAM for every DAW software. But you should simply take a closer look, what YOUR memory demand is or might become over time and to avoid that your system comes into paging/swapping activity permanently or too early.

As memory demand usually increases over the years, I would plan for memory reserves to be on the save side for OS and Application updates for the next years until the next system change is due. But the more memory and CPU reserves you have, this might be a few years later. Essential to consider on systems, where memory cannot be exchanged / upgraded.

Summed up

You might have memory issues. This needs to be found out.
If yes, upgrade DRAM if possible.
If this is not possible, ask Apple what can be done in terms of parametrization of the operating system.

Please note: currently only a theory based on my personal experience. I only bring this topic up as I have the gut feeling, that some of these issues are related to it. It might help you to get ideas where else to look for possible issues/solutions.