201 Reply by innerclock (edited by innerclock 2023-04-02 20:57:32)

  • Registered: 2023-04-01
  • Posts: 10

Re: New macOS RME USB 4.06 driver – public beta test

I'm back on the basic 2020 MacMini M Processor machine - minimal RAM (8GB) running Monterey 12.6.4 - same very basic DAW templates - minimal load projects - one software instrument - single track.

Fireface UC > FW-138 / Driver - v3.28A (KEXT)

MADIface USB > FW-v25 / Driver - v3.28A (KEXT)

Environment - macOS 12.6.4 - Ableton Live 11.2.11 - empty project - single software instrument plugin - Live CPU load nothing above 5% when running 24/96 with 32 samples buffer.

With both UC and MADIFace USB - 24/96 Project Settings - 32 samples buffer size = zero glitches/dropouts and no degradation when opening windows / moving mouse.

Update - I just thought I try my 2018 Intel MacMini (again) that I just had serviced with a clean 13.3 install but sticking with the older format driver:-

Fireface UC > FW-138 / Driver - v3.28A (KEXT)

MADIface USB > FW-v25 / Driver - v3.28A (KEXT)

Environment - 3 GHz 6-Core Intel Core i5 - macOS 13.3 - Ableton Live 11.2.11 - empty project - single software instrument plugin - Live CPU load nothing above 5% when running - same audio settings as on M1/Monterey platform - 24/96 with 32 samples buffer - but now glitching and dropouts like its raining just sitting there - move the mouse / open a web page etc and it gets a whole lot worse.

So even with the older (stable on the basic M1 processor / Monterey machine) KEXT driver - the Intel/Ventura 13.3 combo is a train wreck at this point.

Hope some / any of that helps.

Update - just checked Physical Memory / Memory Used differences between both Macs in case its a RAM issue - these numbers are reported with identical system load - OS / background services / Ableton Live - nothing else.

M1/Monterey = 8GB Physical / 5.50 GB used - both UC/MADIFace USB work great.
Intel/Ventura =8GB Physical / 6.0 GB used - both UC/MADIFace USB no good.

I have a Mac Studio M1 Max 32GB RAM in the main room running 12.6.4 but its driving an Antelope Orion 32 Gen III via Thunderbolt and don't want to update OS at this point as its very stable.

I'm happy to get another Mac Studio and run Ventura for my RME rig if its down to Processor type and RAM capacity or even drop 32GB RAM into the 2018 Intel MacMini if that will address the issue (I have my doubts) but I'd like to know first before I drop the coin either way smile

Best - D

Fireface UC MADIface USB M-16DA PT Logic PRO Cubase 12 Live Intel and M Series Macs Mojave ~ Ventura

innerclock's Website

202 Reply by ramses (edited by ramses 2023-04-02 21:21:19)

  • ramses
  • DAW Mastermind
  • Offline
  • From: UTC+1
  • Registered: 2012-10-14
  • Posts: 13,132

Re: New macOS RME USB 4.06 driver – public beta test

Hi, is the system paging/swapping? How much swap space is in use?
Swap usage you can see at the bottom of activity monitor, I saw in a screenshot.
Where you can see paging/swapping activity, sry I don't know.

BR Ramses - UFX III, 12Mic, XTC, ADI-2 Pro FS R BE, RayDAT, X10SRi-F, E5-1680v4, Win10Pro22H2, Cub14
  • Registered: 2023-04-01
  • Posts: 10

Re: New macOS RME USB 4.06 driver – public beta test

ramses wrote:

Hi, is the system paging/swapping? How much swap space is in use?
Swap usage you can see at the bottom of activity monitor, I saw in a screenshot.
Where you can see paging/swapping activity, sry I don't know.

Hey - 6.30am here - I couldn't help myself - I've just carefully dismantled my 2018 Intel MacMini machine and pulled the standard 8GB RAM out - I'll drop in two 16GBs later today for 32GB total when I get hold of some. At least that will eliminate the possible RAM issue and Ventura 13.3 - but I still have my doubts as this very same machine was glitching with the RMEs under Monterey 12.6.4 (KEXT or DriverKit User Space Drivers hence the full service / test bench and fresh Ventura install. It was then I remembered I had a 2020 M1 MacMini laying about - as said previously - only 8GB RAM running 12.6.4 and the KEXT drivers installed and it runs the RMEs flawlessly.

Fireface UC MADIface USB M-16DA PT Logic PRO Cubase 12 Live Intel and M Series Macs Mojave ~ Ventura

innerclock's Website

204 Reply by JL

  • JL
  • AD/DA expert
  • Offline
  • Registered: 2008-01-10
  • Posts: 39

Re: New macOS RME USB 4.06 driver – public beta test

Whats the actual benefit from using driverkit driver except that in the future kext drivers will be dropped alltogether? I have zero interest in investing time (optimizing and compromising normal computer usage) to make shit work that's supposed to work anyway.

For me 13.3 Ventura works with KEXT driver, does not work with Driverkit driver. New try with next driver update maybe, I just hope rme will "magically" fix the driver before driverkit is the only option.

  • Registered: 2022-11-09
  • Posts: 46

Re: New macOS RME USB 4.06 driver – public beta test

JL wrote:

Whats the actual benefit from using driverkit driver except that in the future kext drivers will be dropped alltogether? I have zero interest in investing time (optimizing and compromising normal computer usage) to make shit work that's supposed to work anyway.

For me 13.3 Ventura works with KEXT driver, does not work with Driverkit driver. New try with next driver update maybe, I just hope rme will "magically" fix the driver before driverkit is the only option.

Customer support already told me it will not "Magically" get fixed tongue tongue Jokes apart, I couldn't care less about what type of driver works or doesn't as long as the audio plays smoothly! We buy these interfaces to do serious work and not experimentation! Other companies have managed to figure it out so why can't RME?

MacBook Pro M1Pro - Monterey -  Babyface Pro FS - Fireface 800 -  Logic Pro X 10.7.7

206 Reply by Scheffkoch (edited by Scheffkoch 2023-04-03 11:50:36)

  • Registered: 2008-11-04
  • Posts: 90

Re: New macOS RME USB 4.06 driver – public beta test

"I couldn't care less about what type of driver works or doesn't as long as the audio plays smoothly!"

...but then there is a solution for you: use the "old" kext driver (see innerclocks post)...it is still possible to install it under monterey and ventura...

207 Reply by soundpotion (edited by soundpotion 2023-04-03 12:13:30)

  • Registered: 2022-11-09
  • Posts: 46

Re: New macOS RME USB 4.06 driver – public beta test

Scheffkoch wrote:

"I couldn't care less about what type of driver works or doesn't as long as the audio plays smoothly!"

...but then there is a solution for you: use the "old" kext driver (see innerclocks post)...it is still possible to install it under monterey and ventura...

I tried it after I saw the post... Its a lil better but till get glitching... I am using a Babyface Pro FS with firmware v.203 and 3.28A driver.

MacBook Pro M1Pro - Monterey -  Babyface Pro FS - Fireface 800 -  Logic Pro X 10.7.7

208 Reply by stromkraft (edited by stromkraft 2023-04-03 18:21:29)

  • Registered: 2014-07-01
  • Posts: 79

Re: New macOS RME USB 4.06 driver – public beta test

ramses wrote:

Summed up

You might have memory issues. …

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.

I can only speak for myself, but when I had issues with the user space driver beta I haven't seen a lot of swapping, nor have I had any indication of anything but audio to be disturbed. Now, with the 4.07 release and macOS 13.3 I don't seem to have any dropouts really.

A good article for getting some ideas for how to evaluate swapping is Tracking swap space: is it wearing out your SSD? over at The Eclectic Light Company.

The highlights:

"Activity Monitor and the size of the VM volume in your boot volume group, shown by selecting its container in Disk Utility. When there’s no swap use, that VM volume should be tiny, less than 1 MB. In the Memory tab of Activity Monitor, the figure for Swap Used should be zero."

In Terminal:

"vm_stat can be used in either of two ways. When used without options, it gives a set of statistics for virtual memory use since that Mac last started up.
vm_stat shortly before you shut your Mac down or restart it will give figures at the end for swapins and swapouts"

RME Babyface v226 | 4.07 | MacBook Pro 13" 2020 | 16gb/1tb

209 Reply by innerclock (edited by innerclock 2023-04-03 21:02:32)

  • Registered: 2023-04-01
  • Posts: 10

Re: New macOS RME USB 4.06 driver – public beta test

JL wrote:

Whats the actual benefit from using driverkit driver except that in the future kext drivers will be dropped alltogether? I have zero interest in investing time (optimizing and compromising normal computer usage) to make shit work that's supposed to work anyway.

For me 13.3 Ventura works with KEXT driver, does not work with Driverkit driver. New try with next driver update maybe, I just hope rme will "magically" fix the driver before driverkit is the only option.

KEXT Drivers (generally were/used to be the 'gold standard') as they allow low level priority system access to the Mac hardware which is why they worked. Apple seems to be moving more towards protecting their OS as a priority rather than allowing developers direct access to their OS core and so forcing driver developers to use their new User Space DriverKit API - if it's as good or better - we have to wait and see. I have my doubts........and I really don't want to go back to Windows ......... I'll go back to mowing lawns...... or Maybe a 9600 PPC running system 9.2.2 - or maybe SMPTE and a 24 track tape machine - that worked really well - no latency, no drivers, no screens......

https://www.zdnet.com/article/apple-dep … -security/

https://blog.kandji.io/guide-for-apple- … extensions

Fireface UC MADIface USB M-16DA PT Logic PRO Cubase 12 Live Intel and M Series Macs Mojave ~ Ventura

innerclock's Website

210 Reply by innerclock (edited by innerclock 2023-04-04 03:55:18)

  • Registered: 2023-04-01
  • Posts: 10

Re: New macOS RME USB 4.06 driver – public beta test

Update: 2018 Intel MacMini now has 32GB brand new RAM installed and fresh install of Ventura 3.3

Fireface UC > FW 138 > Driver (KEXT) 3.28A

Still glitching and popping away with almost zero load - 24/96kHz and 32 samples buffer - single track VST plugin instrument.

That's just doing nothing - if I open a browser or move the (wired - Bluetooth is OFF) mouse - it sounds like a 56k Modem from 1995.

Just downloaded and installed DevKit Driver 4.07

Reboot. Same Environment/Project Settings. Result = exactly the same.

I'm not game to test the MADIface USB > M-16DA

So - if it's not RAM then?

Ventura?

Intel?

Way above my paygrade.........

Fireface UC MADIface USB M-16DA PT Logic PRO Cubase 12 Live Intel and M Series Macs Mojave ~ Ventura

innerclock's Website

211 Reply by JL (edited by JL 2023-04-04 10:58:05)

  • JL
  • AD/DA expert
  • Offline
  • Registered: 2008-01-10
  • Posts: 39

Re: New macOS RME USB 4.06 driver – public beta test

innerclock wrote:

Update: 2018 Intel MacMini now has 32GB brand new RAM installed and fresh install of Ventura 3.3

I previously had MacBook Pro 15”, 2018, 2,9 Ghz 6-Core Intel Core i9, 32 Gb and was not able to use RME interfaces with internal USB controller without glitching.

Back then the solution was to use external USB controller connected to the computer with thunderbolt (not usb), I used Caldigit Mini Dock (live and studio) and Caldigit TS3+ at home. You whould give it a try especially if you can get your hands on one without buying, if you need to get one maybe investigate a bit more but I'd say that's your issue/solution right there. Here's a thread about the problem:

https://forum.rme-audio.de/viewtopic.php?id=27964

and:

https://forum.rme-audio.de/viewtopic.php?id=26881

Disclaimer though: problem / solution could have evolved from what I'm aware of with driver / os updates, I stopped following when I found a working combo and kept using that until switching to M1 mac on 2021, with which I've had zero RME issues until driverkit driver 4.07.

Update: Oh well, went to check the threads, apparently the general agreement is that MacOS 10.14.4 fixed the issues, and after that external USB controller did not really make a difference anymore. I'd give it a try anyway if possible, of course might be something totally different also. Sorry for misleading, if I was misleading. smile

212 Reply by innerclock (edited by innerclock 2023-04-04 20:47:49)

  • Registered: 2023-04-01
  • Posts: 10

Re: New macOS RME USB 4.06 driver – public beta test

JL wrote:
innerclock wrote:

Update: 2018 Intel MacMini now has 32GB brand new RAM installed and fresh install of Ventura 3.3

I previously had MacBook Pro 15”, 2018, 2,9 Ghz 6-Core Intel Core i9, 32 Gb and was not able to use RME interfaces with internal USB controller without glitching.

Back then the solution was to use external USB controller connected to the computer with thunderbolt (not usb), I used Caldigit Mini Dock (live and studio) and Caldigit TS3+ at home. You could give it a try especially if you can get your hands on one without buying, if you need to get one maybe investigate a bit more but I'd say that's your issue/solution right there. Here's a thread about the problem:

https://forum.rme-audio.de/viewtopic.php?id=27964

and:

https://forum.rme-audio.de/viewtopic.php?id=26881

Disclaimer though: problem / solution could have evolved from what I'm aware of with driver / os updates, I stopped following when I found a working combo and kept using that until switching to M1 mac on 2021, with which I've had zero RME issues until driverkit driver 4.07.

Update: Oh well, went to check the threads, apparently the general agreement is that MacOS 10.14.4 fixed the issues, and after that external USB controller did not really make a difference anymore. I'd give it a try anyway if possible, of course might be something totally different also. Sorry for misleading, if I was misleading. smile

Thanks for the feedback - OK - so using the Mac's built in USB 3.1 buss fails because of an Apple issue since 10.14? Sheeesh. Has that been an RME problem right through to OS 12 and now 13? But if I purchase a genuine Thunderbolt 3/4 (depending on my Mac (2108 Mini or Studio Max) to USB dock/bridge it bypasses the built-in Apple 3.1 USB buss issue because it's using the Thunderbolt engine/driver ? Seriously? This is getting to be an expensive experiment....... I'm starting to see why the Antelope Orion Gen III connected directly - Thunderbolt < > Thunderbolt has no issues. That being said my Gen II blew up after only 18 months and no replacement main PCBs were available - $6K in the skip. Unforgivable really. The test plugs we develop run continuous audio and absolutely MUST provide zero dropouts and glitches. We have to remain current with future Mac OS builds obviously too and need reliable / professional grade audio interfaces hence the need to work with Ventura - we've always recommended RME since day 1 but this has me worried.......

Last question for this post if anyone knows - for my trusty UC and new MADIFace USB M-16DA combo - if I use a genuine Thunderbolt 3/4 Dock > USB - does that mean I'm using Thunderbolt Drivers (cant see any on the RME site so assume not) so still using the existing KEXT/DevKit USB Drivers it's just that they run through the Thunderbolt pipeline/conversion so immune to the native USB buss Apple issues?

Fireface UC MADIface USB M-16DA PT Logic PRO Cubase 12 Live Intel and M Series Macs Mojave ~ Ventura

innerclock's Website

213 Reply by Jeff

  • Jeff
  • Jeff
  • Moderator
  • Offline
  • From: USA
  • Registered: 2007-05-21
  • Posts: 4,661

Re: New macOS RME USB 4.06 driver – public beta test

so using the Mac's built in USB 3.1 bus fails because of an Apple issue since 10.14? Sheeesh. Has that been an RME problem right through to OS 12 and now 13?

That was about the T2 security chip in the 'Touchbar' MBP. I can confirm as I have one that did not work for USB audio (without a hub) for a couple years, then an OS update finally fixed it. It was always an Apple bug.

Regards,
Jeff Petersen
Synthax Inc.

Jeff's Website

  • Registered: 2023-04-01
  • Posts: 10

Re: New macOS RME USB 4.06 driver – public beta test

Jeff wrote:

so using the Mac's built in USB 3.1 bus fails because of an Apple issue since 10.14? Sheeesh. Has that been an RME problem right through to OS 12 and now 13?

That was about the T2 security chip in the 'Touchbar' MBP. I can confirm as I have one that did not work for USB audio (without a hub) for a couple years, then an OS update finally fixed it. It was always an Apple bug.

Thanks Jeff - never went near those Touchbar MPBs - our Macs are all bolted to test benches so they are Mini's PROs and Studio/Studio MAX machines running various OS builds. I guess I don't mind dropping $500 on a Thunderbolt 3/4 dock if that's going to eliminate the issue - just wouldn't mind knowing 100% first - the 32GB RAM upgrade on the 2018 Intel Mac Mini (nice to have anyway I guess) wasn't cheap and didn't fix anything - D

Fireface UC MADIface USB M-16DA PT Logic PRO Cubase 12 Live Intel and M Series Macs Mojave ~ Ventura

innerclock's Website

215 Reply by JL

  • JL
  • AD/DA expert
  • Offline
  • Registered: 2008-01-10
  • Posts: 39

Re: New macOS RME USB 4.06 driver – public beta test

Jeff wrote:

That was about the T2 security chip in the 'Touchbar' MBP. I can confirm as I have one that did not work for USB audio (without a hub) for a couple years, then an OS update finally fixed it. It was always an Apple bug.

Apparently 2018 mac mini also has T2 chip and I understood it was affected with the issue. Great to hear that's fixed now.

https://support.apple.com/en-gb/HT208862

  • From: Adelaide - Australia
  • Registered: 2007-05-01
  • Posts: 455

Re: New macOS RME USB 4.06 driver – public beta test

fa151515 wrote:
innerclock wrote:
mattrixx wrote:

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

Hey Matt - seems like you are using the older KEXT Driver on both M1 and Intel machines - on the M1 Pro Ventura 13.3 have you tried the 4.06 User Space Driver?


bad news.  Issue is back with Firmware v42 et Driver 4.07.
what's going on ?

Yep, I was loving it for a while and now it's become almost unbearable. 13.3 with 4.07 driver... even re-nicing the apps I use, doesn't seem to help.

----------------
Matt McKenzie-Smith (UFXII, UFX, Babyface) MacStudioUltra OS13.2.1
----------------

mattrixx's Website

217 Reply by stromkraft (edited by stromkraft 2023-04-05 11:08:09)

  • Registered: 2014-07-01
  • Posts: 79

Re: New macOS RME USB 4.06 driver – public beta test

mattrixx wrote:
fa151515 wrote:
innerclock wrote:

Hey Matt - seems like you are using the older KEXT Driver on both M1 and Intel machines - on the M1 Pro Ventura 13.3 have you tried the 4.06 User Space Driver?


bad news.  Issue is back with Firmware v42 et Driver 4.07.
what's going on ?

Yep, I was loving it for a while and now it's become almost unbearable. 13.3 with 4.07 driver... even re-nicing the apps I use, doesn't seem to help.

Surely, renicing would only affect CPU overload problems anyway, no? I haven't reniced anything in 10 years.

As told in the 4.07 thread all my audio issues went away with macOS 13.3. Before I had dropouts (in macOS 13 anyway) even when watching youtube.

RME Babyface v226 | 4.07 | MacBook Pro 13" 2020 | 16gb/1tb

218 Reply by mattrixx (edited by mattrixx 2023-04-05 11:18:32)

  • From: Adelaide - Australia
  • Registered: 2007-05-01
  • Posts: 455

Re: New macOS RME USB 4.06 driver – public beta test

2

stromkraft wrote:
mattrixx wrote:
fa151515 wrote:

bad news.  Issue is back with Firmware v42 et Driver 4.07.
what's going on ?

Yep, I was loving it for a while and now it's become almost unbearable. 13.3 with 4.07 driver... even re-nicing the apps I use, doesn't seem to help.

Surely, renicing would only affect CPU overload problems anyway, no? I haven't reniced anything in 10 years.

As told in the 4.07 thread all my audio issues went away with macOS 13.3. Before I had dropouts (in macOS 13 anyway) even when watching youtube.

Definitely both M! machines.. M1 Mac and M1 Ultra.
What do you mean by older kext ?? (whoops. just re-read the message)
You actually make a really great point here... The CPU's are barely doing anything. So re-nicing an app to max priority for CPU usage to an app, probably does little, I'm not sure why I said Firmware v42, it's actually v23 (too many key commands that day)

----------------
Matt McKenzie-Smith (UFXII, UFX, Babyface) MacStudioUltra OS13.2.1
----------------

mattrixx's Website

  • Registered: 2014-07-01
  • Posts: 79

Re: New macOS RME USB 4.06 driver – public beta test

mattrixx wrote:

What do you mean by older kext ??

What did @innerclock mean by older kext, you mean.

RME Babyface v226 | 4.07 | MacBook Pro 13" 2020 | 16gb/1tb

220 Reply by stromkraft (edited by stromkraft 2023-04-05 11:21:49)

  • Registered: 2014-07-01
  • Posts: 79

Re: New macOS RME USB 4.06 driver – public beta test

mattrixx wrote:

You actually make a really great point here... The CPU's are barely doing anything. So re-nicing an app to max priority for CPU usage to an app, probably does little, I'm not sure why I said Firmware v42, it's actually v23 (too many key commands that day)

Well, IPC (Inter Process Communication) interrupts are a thing, even if I still don't know about a good Mac tool for testing/measuring this. Disabling the network, external USB keyboards, BlueTooth are all good starting points.

RME Babyface v226 | 4.07 | MacBook Pro 13" 2020 | 16gb/1tb
  • From: Adelaide - Australia
  • Registered: 2007-05-01
  • Posts: 455

Re: New macOS RME USB 4.06 driver – public beta test

stromkraft wrote:
mattrixx wrote:

You actually make a really great point here... The CPU's are barely doing anything. So re-nicing an app to max priority for CPU usage to an app, probably does little, I'm not sure why I said Firmware v42, it's actually v23 (too many key commands that day)

Well, IPC (Inter Process Communication) interrupts are a thing, even if I still don't know about a good Mac tool for testing/measuring this. Disabling the network, external USB keyboards, BlueTooth are all good starting points.

Definitely disabling USB Keyboards and Bluetooth is impossible here.... pretty much the same as cutting my arms and legs off.  No worky!!

----------------
Matt McKenzie-Smith (UFXII, UFX, Babyface) MacStudioUltra OS13.2.1
----------------

mattrixx's Website

  • Registered: 2014-07-01
  • Posts: 79

Re: New macOS RME USB 4.06 driver – public beta test

mattrixx wrote:
stromkraft wrote:
mattrixx wrote:

You actually make a really great point here... The CPU's are barely doing anything. So re-nicing an app to max priority for CPU usage to an app, probably does little, I'm not sure why I said Firmware v42, it's actually v23 (too many key commands that day)

Well, IPC (Inter Process Communication) interrupts are a thing, even if I still don't know about a good Mac tool for testing/measuring this. Disabling the network, external USB keyboards, BlueTooth are all good starting points.

Definitely disabling USB Keyboards and Bluetooth is impossible here.... pretty much the same as cutting my arms and legs off.  No worky!!

No, no. You do that in order to find the problem, OK?

RME Babyface v226 | 4.07 | MacBook Pro 13" 2020 | 16gb/1tb
  • From: Adelaide - Australia
  • Registered: 2007-05-01
  • Posts: 455

Re: New macOS RME USB 4.06 driver – public beta test

The problem?.. all you have to do is open a website with lots of ads on it in Safari (or just go and do a frantic button press of the system settings alert sound).. Like a news site of sorts and watch your performance meter in Logic get hectic on the live processing thread that you have a software instrument active.  Glitchy glitchy glitch...
...and Just tested the same on my MacBook Pro M1 Max with BT and WiFi turned offf..... exactly the same.
What's weird to me, is that after running the OS 13.3 update, I had 3 days of bliss and then something went wrong.

----------------
Matt McKenzie-Smith (UFXII, UFX, Babyface) MacStudioUltra OS13.2.1
----------------

mattrixx's Website

  • Registered: 2021-08-19
  • Posts: 30

Re: New macOS RME USB 4.06 driver – public beta test

mattrixx wrote:

What's weird to me, is that after running the OS 13.3 update, I had 3 days of bliss and then something went wrong.

exactly the same for me !

225 Reply by stromkraft (edited by stromkraft 2023-04-05 23:30:37)

  • Registered: 2014-07-01
  • Posts: 79

Re: New macOS RME USB 4.06 driver – public beta test

mattrixx wrote:

The problem?.. all you have to do is open a website with lots of ads on it in Safari (or just go and do a frantic button press of the system settings alert sound).. Like a news site of sorts and watch your performance meter in Logic get hectic on the live processing thread that you have a software instrument active.  Glitchy glitchy glitch...
...and Just tested the same on my MacBook Pro M1 Max with BT and WiFi turned offf..... exactly the same.
What's weird to me, is that after running the OS 13.3 update, I had 3 days of bliss and then something went wrong.

I'm using Ableton Live, that does multicore full-on by design. This means recording live input doesn't affect a specific core differently. I can play a track in Live and stream two streaming sites (in apps) and run a zoom meeting at the same time without a hiccup now on 4.07 and also before using the kernel driver (both in in Big Sur and Monterey).

Of course, I could run specific plug-ins that use a lot of CPU on one core with a specific low audio buffer and that would cause dropouts. But core overload in such cases is expected, if the core is indeed overloaded. A user space audio driver in itself shouldn't cause audio dropouts, I think. IPC interrupts can involve the audio driver, both kernel and user space. All the software running interacts, but in your described case it's Apple that designed the OS and the DAW and you should start there for that.

I'd suggest you remove the DAW from the testing and seek "glitches" and dropouts doing other things when that's not even running. That was the situation under the beta, wasn't it? It could "glitch" doing anything.

Even if it can be the RME driver that is still immature, RME can only work within the confines the OS gives user space drivers. If you remove also the RME interface, for another one or native audio and the problem reliably disappears completely, that would be useful info for both RME and Apple, I believe.

I'll think about a strategy to suggest for these kinds of thing. RME really should be more forward on this topic too and suggest useful testing strategies so we can give the data they can use to make their products better. I'd love to be able to do that. I suspect they simply set up their own test and maybe at least use our reports here as pointers. I don't know. At any rate I'm more happy with RME than Apple.

RME Babyface v226 | 4.07 | MacBook Pro 13" 2020 | 16gb/1tb
  • From: Adelaide - Australia
  • Registered: 2007-05-01
  • Posts: 455

Re: New macOS RME USB 4.06 driver – public beta test

stromkraft wrote:
mattrixx wrote:

The problem?.. all you have to do is open a website with lots of ads on it in Safari (or just go and do a frantic button press of the system settings alert sound).. Like a news site of sorts and watch your performance meter in Logic get hectic on the live processing thread that you have a software instrument active.  Glitchy glitchy glitch...
...and Just tested the same on my MacBook Pro M1 Max with BT and WiFi turned offf..... exactly the same.
What's weird to me, is that after running the OS 13.3 update, I had 3 days of bliss and then something went wrong.

I'm using Ableton Live, that does multicore full-on by design. This means recording live input doesn't affect a specific core differently. I can play a track in Live and stream two streaming sites (in apps) and run a zoom meeting at the same time without a hiccup now on 4.07 and also before using the kernel driver (both in in Big Sur and Monterey).

Of course, I could run specific plug-ins that use a lot of CPU on one core with a specific low audio buffer and that would cause dropouts. But core overload in such cases is expected, if the core is indeed overloaded. A user space audio driver in itself shouldn't cause audio dropouts, I think. IPC interrupts can involve the audio driver, both kernel and user space. All the software running interacts, but in your described case it's Apple that designed the OS and the DAW and you should start there for that.

I'd suggest you remove the DAW from the testing and seek "glitches" and dropouts doing other things when that's not even running. That was the situation under the beta, wasn't it? It could "glitch" doing anything.

Even if it can be the RME driver that is still immature, RME can only work within the confines the OS gives user space drivers. If you remove also the RME interface, for another one or native audio and the problem reliably disappears completely, that would be useful info for both RME and Apple, I believe.

I'll think about a strategy to suggest for these kinds of thing. RME really should be more forward on this topic too and suggest useful testing strategies so we can give the data they can use to make their products better. I'd love to be able to do that. I suspect they simply set up their own test and maybe at least use our reports here as pointers. I don't know. At any rate I'm more happy with RME than Apple.

I have indeed done that too... I can make it glitch using just the internal core audio driver for the internal speaker of both the MacBook Pro and the Mac Ultra...  ie Playing music in the Music app and firing off alerts using the "play" trigger in the alerts sounds tab of system settings.

----------------
Matt McKenzie-Smith (UFXII, UFX, Babyface) MacStudioUltra OS13.2.1
----------------

mattrixx's Website

  • From: Adelaide - Australia
  • Registered: 2007-05-01
  • Posts: 455

Re: New macOS RME USB 4.06 driver – public beta test

fa151515 wrote:
mattrixx wrote:

What's weird to me, is that after running the OS 13.3 update, I had 3 days of bliss and then something went wrong.

exactly the same for me !

Wow, really?   It's interesting..... it's like the bucket eventually got full and started messing with us.
I wonder if it's some sort of cache thing?

----------------
Matt McKenzie-Smith (UFXII, UFX, Babyface) MacStudioUltra OS13.2.1
----------------

mattrixx's Website

  • Registered: 2008-12-06
  • Posts: 198

Re: New macOS RME USB 4.06 driver – public beta test

Hey ramses,

you summed it up pretty nice.

The amount of RAM (I have 8 GB on a Mac Mini M1 running Big Sur) does not matter IMHO. Why? Well the moment I switch the FF UCX on it is like a clock ticking. After 2 hours I am forced to reboot because "there is not enough RAM". With 16 GB I would have then 4 hours? Yeah great, not. In the same way it does not matter how much applications are running or how big they are – this is only a time _shifting_ factor.

I have these issues since day one with my Mac. But only with the newer (beta) driver generation. The old drivers (3.27) had not these issues but serious other ones (The computer crashes hard after waking up from standby when the FF UCX is not connected). Fun Fact: after going back to the old driver I have the RAM issues like with the new driver like I did not switch back. What now? I have no idea. I hoped for some hint from RME side with which tool I could monitor and log these bugs to find a solution. Since I am new to Mac OS my knowledge is limited. I would love to give more details but I have no idea what details.

229 Reply by stromkraft (edited by stromkraft 2023-04-08 03:21:56)

  • Registered: 2014-07-01
  • Posts: 79

Re: New macOS RME USB 4.06 driver – public beta test

El Duderino wrote:

…with which tool I could monitor and log these bugs to find a solution. Since I am new to Mac OS my knowledge is limited. I would love to give more details but I have no idea what details.

A start would be the app Activity Monitor > Memory tab which lists process memory usage and at the bottom you have "Memory Pressure" for the total. Leave it open and check progress now and then.

RME Babyface v226 | 4.07 | MacBook Pro 13" 2020 | 16gb/1tb
  • Registered: 2008-12-06
  • Posts: 198

Re: New macOS RME USB 4.06 driver – public beta test

stromkraft wrote:
El Duderino wrote:

…with which tool I could monitor and log these bugs to find a solution. Since I am new to Mac OS my knowledge is limited. I would love to give more details but I have no idea what details.

A start would be the app Activity Monitor > Memory tab which lists process memory usage and at the bottom you have "Memory Pressure" for the total. Leave it open and check progress now and then.

Yeah, I did that:
https://forum.rme-audio.de/viewtopic.ph … 93#p187993

The official answer can be summed up like this: "not our business". Okay. Good to know. There goes the reputation.

231 Reply by stromkraft (edited by stromkraft 2023-04-08 11:46:32)

  • Registered: 2014-07-01
  • Posts: 79

Re: New macOS RME USB 4.06 driver – public beta test

El Duderino wrote:
stromkraft wrote:
El Duderino wrote:

…with which tool I could monitor and log these bugs to find a solution. Since I am new to Mac OS my knowledge is limited. I would love to give more details but I have no idea what details.

A start would be the app Activity Monitor > Memory tab which lists process memory usage and at the bottom you have "Memory Pressure" for the total. Leave it open and check progress now and then.

Yeah, I did that:
https://forum.rme-audio.de/viewtopic.ph … 93#p187993

The official answer can be summed up like this: "not our business". Okay. Good to know. There goes the reputation.

If it isn't the driver causing memory leaking, how is it RME's fault you have a memory leak? If you believe it is what analysis data you have indicates this is the case?

RME Babyface v226 | 4.07 | MacBook Pro 13" 2020 | 16gb/1tb
  • Registered: 2008-12-06
  • Posts: 198

Re: New macOS RME USB 4.06 driver – public beta test

Who says it is not the driver memory leaking?

I mean: it only appears when the Fireface is connected to the Mac. No Fireface = No problems.

I am asking exactly what analysis data I could deliver (sorry for the missing screenshot – wished I could just post it in the forum without external service) that can help to solve the issue.

233 Reply by stromkraft (edited by stromkraft 2023-04-10 07:14:51)

  • Registered: 2014-07-01
  • Posts: 79

Re: New macOS RME USB 4.06 driver – public beta test

El Duderino wrote:

Who says it is not the driver memory leaking?

I mean: it only appears when the Fireface is connected to the Mac. No Fireface = No problems.

I am asking exactly what analysis data I could deliver (sorry for the missing screenshot – wished I could just post it in the forum without external service) that can help to solve the issue.

Absence of data show nothing.

I suggested a starting point and you replied with you've done that, indicating you think you've covered it all. What if drivers existed as processes and there existed some tool that could glean some info about these, then what could you try? After such collection of data, what does the data suggest?

RME Babyface v226 | 4.07 | MacBook Pro 13" 2020 | 16gb/1tb
  • Registered: 2014-07-01
  • Posts: 79

Re: New macOS RME USB 4.06 driver – public beta test

Anyway, I've started to look for the actual dropout causes in the release discussion. Granted I don't have such issues and don't intend to get it, but I have an intel machine I can possibly test with.

If you actually want to find the causes in the release version, please add the knowledge you have, there.

RME Babyface v226 | 4.07 | MacBook Pro 13" 2020 | 16gb/1tb

235 Reply by zwap (edited by zwap 2023-04-09 12:04:45)

  • zwap
  • ADAT user
  • Offline
  • Registered: 2021-07-20
  • Posts: 29

Re: New macOS RME USB 4.06 driver – public beta test

Hello, speaking of Mac drivers in general.  i find the register tab on the RME / Products / Drivers website can a bit confusing for some Apple users.

It says "Mac OS X" which also contains Drivers for Apple Silicon Macs and Drivers for MacOS 11+.

Mac OS X (10) is a legacy Operating System Series that is not supported by Apple anymore (the last one 10.15 Catalina phased out support in November 2022)

Also Mac OS X is not compatible with Apple Silicon Macs.  Apple introduced Apple Silicon with MacOS 11 (Big Sur) for their own processors.  there is no downgrade to Mac OS X possible.

i would find it more clear to have 2 tabs or a folder that divides  "Mac OS X - Legacy Operating System"   and "MacOS" which contains current operating Systems incl.  Apple Silicon (M1/M2) and Intel.

  • Registered: 2023-04-10
  • Posts: 4

Re: New macOS RME USB 4.06 driver – public beta test

Hi all, I wanted to report on an issue I've noticed after upgrading the FW/Driver on my UCX-II to v42/4.07.

The behavior I'm seeing so far is specific to Line Input 5 on the interface, to where the interface stops receiving any audio coming in. I can move the cable to any other input and it works, but here's the other crazy thing.  After a reboot, the input works.  I can also go to TotalMixFX and if I change the input's configuration from +19dBu to +13dBu the input starts working again, either on +19/+13dBu.  After some time which can be hours or days the input will stop processing audio again until I toggle the input configuration or reboot the interface.

Any additional information needed to debug this? I'd love to get as much information as needed for RME's team as I don't suspect this is a hardware issue.  If it is hardware for some reason I can work with Sweetwater to RMA but I believe this is related to software/firmware.

-Tyler

  • Registered: 2022-02-15
  • Posts: 14

Re: New macOS RME USB 4.06 driver – public beta test

tylerwylie wrote:

Hi all, I wanted to report on an issue I've noticed after upgrading the FW/Driver on my UCX-II to v42/4.07.

The behavior I'm seeing so far is specific to Line Input 5 on the interface, to where the interface stops receiving any audio coming in. I can move the cable to any other input and it works, but here's the other crazy thing.  After a reboot, the input works.  I can also go to TotalMixFX and if I change the input's configuration from +19dBu to +13dBu the input starts working again, either on +19/+13dBu.  After some time which can be hours or days the input will stop processing audio again until I toggle the input configuration or reboot the interface.

Hi, I just wanted to say that I have the exact same problem (UCXII 42/4.07). I 'solve' it by changing snaps on my ARC, but yeah seems like a bug. For me, it kind of dwarfs the stuttering/glitching problems though.

Cheers,
Terje

  • Registered: 2023-02-15
  • Posts: 10

Re: New macOS RME USB 4.06 driver – public beta test

Eithunsen wrote:
tylerwylie wrote:

Hi all, I wanted to report on an issue I've noticed after upgrading the FW/Driver on my UCX-II to v42/4.07.

The behavior I'm seeing so far is specific to Line Input 5 on the interface, to where the interface stops receiving any audio coming in. I can move the cable to any other input and it works, but here's the other crazy thing.  After a reboot, the input works.  I can also go to TotalMixFX and if I change the input's configuration from +19dBu to +13dBu the input starts working again, either on +19/+13dBu.  After some time which can be hours or days the input will stop processing audio again until I toggle the input configuration or reboot the interface.

Hi, I just wanted to say that I have the exact same problem (UCXII 42/4.07). I 'solve' it by changing snaps on my ARC, but yeah seems like a bug. For me, it kind of dwarfs the stuttering/glitching problems though.

Cheers,
Terje

Hello - I have the same issue and have been commenting in this thread: https://forum.rme-audio.de/viewtopic.php?id=36840.  It started happening to me before the 4.0# series drivers.  It affects Line Input 5 on my UCX II as well.

239 Reply by soundpotion (edited by soundpotion 2023-04-11 21:44:09)

  • Registered: 2022-11-09
  • Posts: 46

Re: New macOS RME USB 4.06 driver – public beta test

Hi, So here is an interesting experiment. I connected the same Babyface Pro FS that's been stuttering and glitching when used with the RME driver in an indirect way using Sonarworks Sound ID and "magically" everything is back to normal! Everything works perfectly including Totalmix, but only difference is that in my DAW or system audio preferences I choose Sound ID as my interface and not the RME! I choose the RME interface as the output inside Sound ID. So this kind of proves that this is completely an RME driver issue. Otherwise it should glitch and stutter like it's been doing when you choose the RME interface from the list of audio output devices. Please correct me if I'm wrong! Tired of using work arounds. Need a proper solution!

MacBook Pro M1Pro - Monterey -  Babyface Pro FS - Fireface 800 -  Logic Pro X 10.7.7

240 Reply by MC

  • MC
  • MC
  • Administrator
  • Offline
  • From: Germany/Thailand
  • Registered: 2007-04-06
  • Posts: 25,537

Re: New macOS RME USB 4.06 driver – public beta test

When did you start to use Sound ID?

Regards
Matthias Carstens
RME

MC's Website

241 Reply by stromkraft (edited by stromkraft 2023-04-12 04:38:29)

  • Registered: 2014-07-01
  • Posts: 79

Re: New macOS RME USB 4.06 driver – public beta test

soundpotion wrote:

Everything works perfectly including Totalmix, but only difference is that in my DAW or system audio preferences I choose Sound ID as my interface and not the RME! I choose the RME interface as the output inside Sound ID. So this kind of proves that this is completely an RME driver issue. Otherwise it should glitch and stutter like it's been doing when you choose the RME interface from the list of audio output devices.

You do realise the RME driver is active when you hear sound, right? Sound ID is not the hardware driver. The part to investigate is why adding an intermediary would solve this kind of thing.
Does this work the same using the 3 different processing options with Zero Latency, Mixed or Linear Phase in Sound ID? The first would be especially interesting. I'm assuming here these are also on macOS.

As you can read in various places, similar ideas have been presented as solutions also when RME hardware is not involved in stuttering or audio dropout problems. What can we learn from that?

RME Babyface v226 | 4.07 | MacBook Pro 13" 2020 | 16gb/1tb
  • Registered: 2022-11-09
  • Posts: 46

Re: New macOS RME USB 4.06 driver – public beta test

stromkraft wrote:
soundpotion wrote:

Everything works perfectly including Totalmix, but only difference is that in my DAW or system audio preferences I choose Sound ID as my interface and not the RME! I choose the RME interface as the output inside Sound ID. So this kind of proves that this is completely an RME driver issue. Otherwise it should glitch and stutter like it's been doing when you choose the RME interface from the list of audio output devices.

You do realise the RME driver is active when you hear sound, right? Sound ID is not the hardware driver. The part to investigate is why adding an intermediary would solve this kind of thing.
Does this work the same using the 3 different processing options with Zero Latency, Mixed or Linear Phase in Sound ID? The first would be especially interesting. I'm assuming here these are also on macOS.

As you can read in various places, similar ideas have been presented as solutions also when RME hardware is not involved in stuttering or audio dropout problems. What can we learn from that?


Ofcourse I understand that its still using the RME driver. Perhaps I did not use the right words. What I meant is that when I choose the RME interface in as my output I have problems as explained in the later part of my post. So if this is completely Apple's problem, how is it that other interfaces with drivers have no issues, my fireface 800 works fine and even my internal sound card works fine. There has to be something to it that RME is not doing right? To answer your question about Sound ID, all modes work fine. I'm not a big fan of their room correction so I just switch off calibration and get on with my sessions.

MacBook Pro M1Pro - Monterey -  Babyface Pro FS - Fireface 800 -  Logic Pro X 10.7.7
  • Registered: 2008-12-06
  • Posts: 198

Re: New macOS RME USB 4.06 driver – public beta test

stromkraft wrote:

Absence of data show nothing.

I suggested a starting point and you replied with you've done that, indicating you think you've covered it all. What if drivers existed as processes and there existed some tool that could glean some info about these, then what could you try? After such collection of data, what does the data suggest?

Sorry, I am not a native English speaker, so maybe there is something lost in the translation.

At no point I said I am done delivering data or wanted to indicate that. I ask for help which data can I deliver because I have no clue – beside a screenshot of the activity monitor which got an official answer with a wave of the hand.

244 Reply by stromkraft (edited by stromkraft 2023-04-12 11:01:36)

  • Registered: 2014-07-01
  • Posts: 79

Re: New macOS RME USB 4.06 driver – public beta test

soundpotion wrote:
stromkraft wrote:
soundpotion wrote:

Everything works perfectly including Totalmix, but only difference is that in my DAW or system audio preferences I choose Sound ID as my interface and not the RME! I choose the RME interface as the output inside Sound ID. So this kind of proves that this is completely an RME driver issue. Otherwise it should glitch and stutter like it's been doing when you choose the RME interface from the list of audio output devices.

You do realise the RME driver is active when you hear sound, right? Sound ID is not the hardware driver. The part to investigate is why adding an intermediary would solve this kind of thing.
Does this work the same using the 3 different processing options with Zero Latency, Mixed or Linear Phase in Sound ID? The first would be especially interesting. I'm assuming here these are also on macOS.

As you can read in various places, similar ideas have been presented as solutions also when RME hardware is not involved in stuttering or audio dropout problems. What can we learn from that?

Ofcourse I understand that its still using the RME driver. Perhaps I did not use the right words. What I meant is that when I choose the RME interface in as my output I have problems as explained in the later part of my post. So if this is completely Apple's problem, how is it that other interfaces with drivers have no issues, my fireface 800 works fine and even my internal sound card works fine. There has to be something to it that RME is not doing right? To answer your question about Sound ID, all modes work fine. I'm not a big fan of their room correction so I just switch off calibration and get on with my sessions.

Well, as this is a chain of software — the audio source like a DAW, which is interfacing CoreAudio, which in its turn interfaces the audio interface driver at some point — where all these more or less sequentially shares a data stream, the answer might be tricky to find.

I'd like to get a grip on when this problem happens if there is actually a core overload somewhere, even brief such as with a spike. This would explain audio dropouts when the CPU load is relatively low. As would IPC interrupts if that could be detected.

It might also be interesting to know where the dropouts actually happen. Without adding an intermediary piece of software, which might affect the outcome just being present, I don't know how to check for this earlier than the audio interface. Most of the RME interfaces have loopback, so with that active it's a possibility to record the audio dropouts. Only RME can tell us what a clean loopback recording while output suffers from dropouts would indicate. At any rate, I've had both outcomes during the beta period. I can't test this now myself as I have so far no dropouts since macOS 13.3.

In the 4.07 discussion there are some investigations going on focused on the driver process and such, but nothing conclusive yet I think.

It would be great if RME could suggest some standard tests, the results of which could be useful for them in finding problems when we send reports for specific issues, or even better if such tests could help us users to fix the problems ourselves without bothering RME support.

RME Babyface v226 | 4.07 | MacBook Pro 13" 2020 | 16gb/1tb
  • Registered: 2022-11-09
  • Posts: 46

Re: New macOS RME USB 4.06 driver – public beta test

MC wrote:

When did you start tp use Sound ID?

I used it briefly since I purchased it last year, but yesterday I thought why not try to use it in this way and see if I can stop the stuttering and it worked. I am on the driver ver 3.28A and firmware v203 on Monterey 12.6.5

MacBook Pro M1Pro - Monterey -  Babyface Pro FS - Fireface 800 -  Logic Pro X 10.7.7
  • Registered: 2022-11-09
  • Posts: 46

Re: New macOS RME USB 4.06 driver – public beta test

stromkraft wrote:
soundpotion wrote:
stromkraft wrote:

You do realise the RME driver is active when you hear sound, right? Sound ID is not the hardware driver. The part to investigate is why adding an intermediary would solve this kind of thing.
Does this work the same using the 3 different processing options with Zero Latency, Mixed or Linear Phase in Sound ID? The first would be especially interesting. I'm assuming here these are also on macOS.

As you can read in various places, similar ideas have been presented as solutions also when RME hardware is not involved in stuttering or audio dropout problems. What can we learn from that?

Ofcourse I understand that its still using the RME driver. Perhaps I did not use the right words. What I meant is that when I choose the RME interface in as my output I have problems as explained in the later part of my post. So if this is completely Apple's problem, how is it that other interfaces with drivers have no issues, my fireface 800 works fine and even my internal sound card works fine. There has to be something to it that RME is not doing right? To answer your question about Sound ID, all modes work fine. I'm not a big fan of their room correction so I just switch off calibration and get on with my sessions.

.

It might also be interesting to know where the dropouts actually happen. Without adding an intermediary piece of software, which might affect the outcome just being present, I don't know how to check for this earlier than the audio interface. Most of the RME interfaces have loopback, so with that active it's a possibility to record the audio dropouts. Only RME can tell us what a clean loopback recording while output suffers from dropouts would indicate. At any rate, I've had both outcomes during the beta period. I can't test this now myself as I have so far no dropouts since macOS 13.3.
.

It's a very similar pattern every time. You hit play in the DAW it behaves fine for about 6-10 starts and stops and then it doesn't stop stuttering until you re-open the session or restart the computer. It kind of feels like a cache or something fills up and then it's unusable. I don't know if that makes sense but its the best I can explain it. I kept activity monitor open to see what's going on there and was surprised to see that even as I hit play in a moderately heavy session in Logic Pro X, I have close to 70% of CPU still idle! Also, if a there is a system overload in any DAW, U will get a system overload warning and the session will stop playing. In this case the audio doesn't stop. It stutters and glitches for a few seconds and plays fine then. The problems repeats again when u stop and play again and so on and so forth. Another thing I noticed was that inside the DAW there is uneven distribution of load on the cores! This happens only if I put my babyface pro as output device inside the daw or system audio preferences. When I switch to the FF800 or my internal audio interface, the problem is gone. I also have an intel Mac which has an old driver for the babyface pro installed and the device works fine there. That rules out any issue with my particular device or a cable issue.

MacBook Pro M1Pro - Monterey -  Babyface Pro FS - Fireface 800 -  Logic Pro X 10.7.7
  • mjfe87
  • mjfe87
  • S/Mux specialist
  • Offline
  • Registered: 2011-06-21
  • Posts: 290

Re: New macOS RME USB 4.06 driver – public beta test

MC wrote:
naturligasteg wrote:

II have tried different usb port and is seems about the same... goes many hours without any issues and the suddenly there is a pop or stop or two...

In the end it is Apple's responsibility to make DriverKit work without such effects. THEY put DriverKit on all of us, and THEY decided that a not-kernel based solution is good enough for anyone. Although technically that is more than questionable.

That said pops and clicks can also happen with kernel-based drivers.

I've been struggling with clicks/drop-outs on v3.27a with the MADIface Pro and XT and am a little nervous about a live recording tomorrow despite having upgraded to 3.28. When using the XT there are no CRC errors but is there another way to identify the cause?

Judging by this thread it looks like 3.28 is currently safer than 4.07 on an M1 Max - is that right? And would reverting to an 'external' USB hub like CalDigit solve the issue?

Seems unbelievable we're still battling Apple in 2023...

Eastwood Records
www.eastwoodrecords.co.uk

mjfe87's Website

  • Registered: 2014-07-01
  • Posts: 79

Re: New macOS RME USB 4.06 driver – public beta test

mjfe87 wrote:

I've been struggling with clicks/drop-outs on v3.27a with the MADIface Pro and XT and am a little nervous about a live recording tomorrow…

Are you saying you've had "clicks/drop-outs" in recordings?

RME Babyface v226 | 4.07 | MacBook Pro 13" 2020 | 16gb/1tb

249 Reply by stromkraft (edited by stromkraft 2023-04-13 03:59:33)

  • Registered: 2014-07-01
  • Posts: 79

Re: New macOS RME USB 4.06 driver – public beta test

soundpotion wrote:

I kept activity monitor open to see what's going on there and was surprised to see that even as I hit play in a moderately heavy session in Logic Pro X, I have close to 70% of CPU still idle!

When it comes to audio dropouts and similar, what matters is any single core getting overloads, not overall CPU load.

soundpotion wrote:

Also, if a there is a system overload in any DAW, U will get a system overload warning and the session will stop playing.

We're not talking about system overload. What led you to believe we were? Core overload is what we're talking about, especially in the form of CPU spikes. For this kind of problem, it's useful to remove the situations from where this occurs from the ones where they don't, so it's a natural first check.

When we have done that to some satisfaction, we can refocus how using a specific audio interface or a specific driver might influence the problems we experience in the situations where Core overloads aren't happening. For this non-overload problem category I think it's vital to understand from where dropouts stem.

I'm looking at some approaches to try on my intel, where I might be able to get this problem going, but beside trying another interface I think it would be interesting if any of you getting dropouts get these when your device run in class compliant mode. Because then, no RME driver nor Totalmix is involved. The main problem is being able to the recreate issue state. When I had these problems before that was pretty hard to do as I remember it.

Can you please try class compliant mode and see if it makes a difference?

RME Babyface v226 | 4.07 | MacBook Pro 13" 2020 | 16gb/1tb

250 Reply by MC

  • MC
  • MC
  • Administrator
  • Offline
  • From: Germany/Thailand
  • Registered: 2007-04-06
  • Posts: 25,537

Re: New macOS RME USB 4.06 driver – public beta test

soundpotion wrote:
MC wrote:

When did you start to use Sound ID?

I used it briefly since I purchased it last year

I expect Sound ID to work in a way that it can't be removed from CoreAudio completely without de-installation. You might want to do exactly that to verify that Sound ID has nothing to do with your unusually prominent issues.

Regards
Matthias Carstens
RME

MC's Website