1

Topic: New macOS RME USB 4.04 driver – public beta test

This is our next update on our macOS USB DriverKit driver, see here for history: https://forum.rme-audio.de/viewtopic.php?id=35324

Version 4.04 has several improvements in performance and compatibility. It comes with TotalMix FX 1.77b3. The MIDI support missing in 4.03 is back.

Cubase / Nuendo users: this driver now signals the correct 'transport type', USB. Steinberg is already working on a fix so that RME's driver with this (correct) type indication will be usable within Cubase and Nuendo 12. Until then there is a very easy, simple and penalty-free workaround. Open Audio MIDI Setup, Audio Window, click on the lower left + sign, select Create Aggregate Device, then add your RME interface as the only device. This gives the interface a different transport type that Cubase accepts.

https://archiv.rme-audio.de/images/aggregatedeviceDK.png

And some other important notes again:

Attention: Fireface UFX / UCX / UC / 802 and Babyface require a firmware update to versions UFX: 361, UCX: 49, UC: 127, 802 : 17 (111), Babyface: 226 to enable the use of this DriverKit driver. Link to firmware update tool:

https://www.rme-audio.de/downloads/fut_usb_mac.zip

The FUT runs on M1. But as it needs the driver, and the driver is not working as long as the device firmware has not been updated, it is necessary to first update the firmware of these interfaces using the former kernel extension driver!


Current driver version: 4.04. Included TotalMix FX: 1.77b3. This is a special DriverKit version that is not compatible to previous drivers.

System requirements: macOS 11 and up, Intel or M processor (Apple Silicon)

Installation: Double-click on driver_mac_usbdk_404.zip to expand the archive file to the driver file Fireface USB DK 404.pkg. Installation works automatically by a double-click on the pkg (package) file. Users that tried version 4.0 will not see the Allow dialog and button anymore. All others should get that dialog, and before reboot should check that in Security & Privacy, tab General, the RME driver is allowed to load. If not unlock the settings and allow it. Then reboot computer.


Notes

A previously installed kernel extension driver, like 3.27, does not need to be uninstalled. It will be overwritten automatically. After that you could set the system security back to normal, unless any other existing kernel extensions still need reduced security.

To go back to 3.27: easiest method is to drag the Fireface USB Settings app found in the folder Applications to the trash can - only use the Finder for this action. With DriverKit this Settings dialog is 'the app', upon removal all driver files belonging to it will also be removed automatically. You will be asked for permission for the removal of the extensions. If done simply reinstall the former 3.27.

As an alternative we also made a version of the 3.27 driver available that should reliably remove the DriverKit extension during its installation, see link below. The one found on our website for download is not guaranteed to always do that.


Downloads:

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


Former driver 3.27 with updated installer to remove DriverKit 4.0x:

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


Any feedback is much appreciated.

Regards
Matthias Carstens
RME

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

This hard-crashed my computer (mac mini m1, monterey, babyface pro fs) a few seconds into boot after the first restart.
Then after second restart (post crash), everything seems to be fine and stable, no problems now ten minutes in.
I'll let you know if it happens again.

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

Hi MC,

Thank you for the new Version. I just installed it on a M1 Studio...

And played around with my iPad. That means i activated Stand Alone MIDI and CC Mode in TMFX.

But now, the Fireface 802 seems not to switch back to normal Mode... After a couple Restarts, of Mac and the Fireface, Plugging in - and out, it seems to be disconnected to TMFX, but I can go to Settings... And in Audio-Midi-Setup it seems to be still in CC Mode.

Maybe I missed something.

But two Questions:
1) How can i bring the FF back to normal Mode?
2) Why has the CC-Mode MIDI Driver 2 Midi-In and 2 Midi-Out Ports?

Pls have a Look at the Screenshots..

https://ibb.co/GcKdcdB
https://ibb.co/6s3HFgy
https://ibb.co/Xtdt0LT

Regards, Maggie

4

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

Thanks for the feedback. First of all you made us aware of the missing 802 in the opening post (I just added it): the Fireface 802 also needs to be updated to firmware 17 / 111 (with the linked FUT) to be able to be used with DriverKit.

In case yours is already updated: Open TM FX first (just double-click on the TM FX symbol in the Dock), then connect the 802. This should bring it back to PC mode.

Regards
Matthias Carstens
RME

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

Thank you for the Support even on a Holiday!

If i remeber coorectly, I installed the FUT Firmware, when before installing the 4.03 Firmware as described... Everything worked...

Although i tried to start the fut App to reinstall the Firmware. But the App seems to come Up for a few Milliseconds and then it seems to crash. Although it asked me to allow to execute it via the security Settings. Which i confirmed. But now it just starts and disappears.

I just also recognized that the Fireface USB Settings App also starts up but it seems to crash after a few milliseconds.

So at the Moment i have noch Chance to figure out which Firmware ist currently running on the FF...

I will try to connect it to my MacBook and see what is happening there. I will let you know.

Give me few Minutes.

Thank you, so far.

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

I just installed the 4.04 Driver and the FUT Firmware an a Macbook with Monterey. The FF have never been attachted to it before.

Restarted.

Plugged the FF ito USB... And i culd open the FUR App. I reinstalled the the FUT Firmware on it. Although it didn't show me any FW Changes. The i started the TMFX App. And Voila! it is conected on the Macbook. I unchecked the Stand Alone MIDI. And plugged it out of the Macbook.


Then i plugged the FF into the M1 Mac Studio... And everythhing is back again as it was before.

I dont understand this Situation exactly. But it works now. It seems that whatever it was caused the M1 not to recognize the FF properly after my iPad Experiments with CC and MIDI Standalone Mode.

Maybe its a hint for you? Maybe i did something stupid?

Thanks and regards, maggie.

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

I've just given this beta 4.04 a go after my report for 4.03 which did not work on my Open Core Big Sur 5,1 Mac Pro.

Good news here as this 4.04 beta installed and works without any issues so far. I've only run a music player and then Logic Pro playback with about 20 tracks in the session.

Hardware is Madiface USB to ADI-648 and using a UFX via Adat expansion along with 3 x Cranborne Audio 500 Adat racks at 96Khz. The whole system is Clocked via ADI-2 Pro FS R B over AES to UFX then work clock.

It's all looking as stable as it was on 3.27. Thanks for the good work:-)

__________________________
Paul Najar
Jaminajar Music Production
www.jaminajar.com

8 (edited by enricoclaudio 2022-06-07 15:53:32)

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

No issues after installing 4.04 driver in my Mac Studio M1 Max running macOS 12.4 and Fireface UCX II Audio Interface. Thanks again for bringing another solid driver update wink

9 (edited by magebarf 2022-06-07 16:09:28)

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

Same here, upgrade from 4.02 (with an intermediate update to 4.03, which I guess did nothing in practice as I'm on Monterey) to 4.04 worked without any issues so far, on my M1 Mac mini.

And as far as I can tell, no more occurences of the kernel crash I saw soon after installing 4.02 (which sadly yielded no crash dump I could find on disk, only a error report dialog), so that seems to be a rare occurrence.

10

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

Unlike the kernel driver, the operating system's volume controls (software controls and keyboard buttons) are no longer working without TotalMix running. The channels in the user interface (MacOS Audio MIDI Setup) are updated but the hardware does not react to the actual change, the levels stays the same.

Is there a way to listen to the events from the driver itself instead of relying on TotalMix to forward them?

Thanks!

--
BabyFace Pro FS – MacOS 12.4 – MacBook Air 2020 (Intel)

11 (edited by kay 2022-06-08 08:44:43)

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

On a MacBook Air 2020 (Intel) with BabyFace Pro FS:

Playback of a video stream in Firefox has quite frequent audio dropouts and the video freezes for a fraction of a second during that. The userspace driver is not usable when the machine needs to process video too. This problem never occurs with the kernel driver.

The DriverKit process takes 25-30% of CPU time during playback. Is this expected?

No other software is running, no other drivers are installed. Only a monitor and an USB mouse and keyboard are connected. The BabyFace is connected directly to one of the USB ports of the laptop.

12

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

kay wrote:

Unlike the kernel driver, the operating system's volume controls (software controls and keyboard buttons) are no longer working without TotalMix running. The channels in the user interface (MacOS Audio MIDI Setup) are updated but the hardware does not react to the actual change, the levels stays the same.

Yes, this is the new OS system how to handle these things. Apart from that there is no valid reason to exit TM FX.

Regards
Matthias Carstens
RME

13

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

kay wrote:

On a MacBook Air 2020 (Intel) with BabyFace Pro FS:

Playback of a video stream in Firefox has quite frequent audio dropouts and the video freezes for a fraction of a second during that. The userspace driver is not usable when the machine needs to process video too. This problem never occurs with the kernel driver.

The DriverKit process takes 25-30% of CPU time during playback. Is this expected?

No other software is running, no other drivers are installed. Only a monitor and an USB mouse and keyboard are connected. The BabyFace is connected directly to one of the USB ports of the laptop.

It does not take 25% of CPU time. This is for one core only. With the former driver the CPU load is not so easy to see , but there as well.

We will continue to work on this new driver, but I fear that the combination of Intel CPU and third party software like Firefox is out of our control.

Regards
Matthias Carstens
RME

14

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

We will continue to work on this new driver, but I fear that the combination of Intel CPU and third party software like Firefox is out of our control.

The same happens with other video playback software too. Final Cut freezes for a fraction of a second too during playback with the userspace driver. There are no known issues with the kernel driver and this setup.

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

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

Regards
Daniel Fuchs
RME

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

kay wrote:

On a MacBook Air 2020 (Intel) with BabyFace Pro FS:

Playback of a video stream in Firefox has quite frequent audio dropouts and the video freezes for a fraction of a second during that. The userspace driver is not usable when the machine needs to process video too. This problem never occurs with the kernel driver.

I can confim this here too. Pretty often I have pretty long (almost a second long) dropouts - a simple video stream is enough.

After around an hour of actual usage of the FF UCX (=sound playing) the computer starts to give me the RAM full dialog posted in the other beta thread. It does not matter how much apps or if even one is open – the dialog will reappear after a while. At the end I am forced to reboot the maschine. It is like the audio stream gets written into the RAM. The longer I play something the less space is available. And again: this computer never ever had this behaviour before. It started with the beta driver.

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

Hello all,
struggling to get a Fireface UCX (USB) to work on my M1 Pro MacBook Pro running Monterey 12.4.
I have flashed the FF to the latest FW for the Beta (flashed it on a different, non M1 computer). Running package 4.04.
The settings page sees the FF, but nothing else sees it (not the OS, not Nuendo).
Help?

18 (edited by steven1145 2022-06-09 12:35:02)

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

OK so it seems that the USB cable was the culprit for that (or a n'th driver install helped).
Now the issue is that Nuendo does not pass audio inside the DAW with the RME driver (from tracks to bus, simple stuff), whereas it works with the onboard sound card device of the MBP.
This is Nuendo 12.0.3, running either native or Rosetta.

19 (edited by paulnajar 2022-06-09 13:08:31)

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

Further to my previous post here I had my first day of recording with the 4.04 driver on Open Core Big Sur 11.6.6 Mac Pro 5,1.

While simple tasks like stereo playback and smaller multitrack session playback in Logic were OK, today there were issues.

Recording a single vocal track with about 16 playback tracks and almost no plugins in the session @ 96Khz with 64 sample buffer caused one instance of glitching and stuttering about once every other take in a 4 minute song. The CPU meter was showing higher load than I recall with this session.

I reinstalled the 3.27 driver and everything was again perfect and noticeably lower CPU load and no glitches while recording the same task in the same session.

My impression is that the 4.04 driver imposes a higher CPU load under identical work load compared to the 3.27 driver.

__________________________
Paul Najar
Jaminajar Music Production
www.jaminajar.com

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

steven1145 wrote:

OK so it seems that the USB cable was the culprit for that (or a n'th driver install helped).
Now the issue is that Nuendo does not pass audio inside the DAW with the RME driver (from tracks to bus, simple stuff), whereas it works with the onboard sound card device of the MBP.
This is Nuendo 12.0.3, running either native or Rosetta.

Tested using the 3.27 driver to remove 4.04, and audio now works within Nuendo. Go figure... I'll stay on 3.27 if it works, for now.

21

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

DigiCheck NG is now available with the option to show playback channels directly, see here:

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

For this new functrionality it needs this driver, USB DK 4.04, that's why I mention it here.

Regards
Matthias Carstens
RME

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

Ok, this did not turn out well. I have a new fresh clean Mac Studio with Cubase 12 on it. I  have RME 4.03 installed until now. Upgraded to 4.04 drivers and I can not get any audio to playback in Cubase. Sound plays just fine from Spotify, Safari and other apps. Anybody encountered this?

23

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

First post second paragraph. How could you miss this?

Regards
Matthias Carstens
RME

24 (edited by naturligasteg 2022-06-20 09:36:53)

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

MC wrote:

First post second paragraph. How could you miss this?

Yes, how could I. Maybe cheap reading glasses in combo with italics made me only see the midi part. Got exited cause I need that midi port. Seems to work with the workaround.

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

Hello, i want to try the beta on a m1 airbook    os12 with a babyface pro fs.
will the bew firmware still work with older rme usb drivers? My mainnstudio computer runs on an old os 10.9.
The old blue babyface does work with booth.
Will an upgraded babyface pro will do that too?

26

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

The new firmware is compatible to older drivers, don't worry.

Regards
Matthias Carstens
RME

27 (edited by El Duderino 2022-06-25 00:06:02)

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

So my daily experience with the beta driver:
The computer is totally stable, no matter how much programs I open and work with. The moment I connect the Fireface UCX the clock is ticking. As long as no audio stream (=meaning audio is playing) is up everything stays fine. But when I use the Fireface actually then after around 2 hours at the latest the memory is full dialogs appears no matter how much programs are running and finally the computer is brought to it's knees. If there are less programs (more free RAM) open then it takes longer and vice versa. After a restart everything starts from the beginning. During the whole time the driver-performance is bad. Constant dropouts for so long that periphery like the E-RM multiclock is loosing sync. Not like CPU overload dropouts – I have the impression it is related to the system swapping like hell.
So far so already reported.

The new stuff:
The dropout was so big that the driver crashed the whole audio system within MacOS, meaning even the speaker of the Mac Mini disappeared from the list of available devices.

This should be called alpha not beta. ;-P

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

El Duderino, when this happens, and you believe it to be swapping, have you checked out the disk io stats from the activity monitor?

Just open the activity monitor, go to the tab "Disk" and at the bottom you will see "Data read/sec" and "Data written/sec" that will be of interest. I'm also manically trying to keep track of the total data written since last power on due to rumored swap issues where the M1 computers were writing almost the full disk size daily due to some strange phenomenon.

If those numbers are spiking, it could be interesting to sort the process list above by bytes written as well, to see what process is responsible. But more likely than anything, if it is swapping, it will be hidden behind the kernel_task process...

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

Also came in here to report I had a system crash, causing a reset, while at the password entry screen after 10-15 hours + of sleep.

Same this time as with the 4.02 driver, no system crash dump available on disk, only the Apple Problem Report dialog, from where I copied the full contents (and just sent to the support email).
This time no direct pointers to the RME drivers, but the com.apple.driver.usb.cdc.ecm was the last kernel extension to be loaded, and the stack trace starts from com.apple.iokit.IOUSBHostFamily.

This on a computer where the only USB connected device is the RME Babyface (original). Even keyboard and mouse is over BT, so any other USB device would have to be internal components of the M1 Mac Mini.

30 (edited by 3phase 2022-06-26 13:14:12)

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

Hello,
I am testin the beta driver now, especially for midi clock performance..
Seems to have got a little better.. But I cant be sure about that yet, in any case its not worse than the previous driver.

The general problem I experience is not RME midi specific... happens on other midi interfaces too, and the rme midi driver behaves even better than the ones from other companies. But..since rme is better , and the new driver seems to be even tighter...
Is it maybe possible to get totally rid of the problem by  changes to the driver?

The problem itself appears with Ableton live 11 on an 2020 MacBook Air m1 with osx 12, on each program start or audio device change, the midi offset delay for the clock needs to be readjusted...
The offset of the clock output is set to make recorded clock slaves to sit correctly on the one when being recorded.. and not later. because of the latency.. While with non rme midi drivers that negative offset delays can vary up to 20 ms... the 3.27 rme driver behaved on the babyface pro fs better..within 10 ms max..often less..And with the new driver I ve been on 10 restarts below 3 ms offsets variation.. But that can be a lucky accident.. In any case the rme drivers show a better performance than others..even with aggregate devices, that seem to kick other drivers really into the wild.

Update..I had situations where the babyface with 404 was 6-10 ms off.. so maybe its just the same performance as with the previous driver

Is this an Ableton problem? Or Apples core audio/midi? Or is that something that happens with the driver communication and can be fixed by the interface manufactorer?
So that on each program/interface launch the same midi clock offset delay is valid, and no manual recalibration is necessary for any new session. The actual performance of the 4.04 driver is close to acceptable.. but you will have a slightly different sounding session on each relaunch too.. having the drum machines 2 ms earlier or later does make an audible difference..however not one that hurts as badly as 15 ms shifts as with other combined audio/midi interfaces, which sound just broken, and make readjustment on any launch mandatory.

Another small problem.. with the babyface pro FS the midi driver in Ableton or the core midi setup is not longer named as rme device, but just as usb midi device.. from which you might have more than one.. That has been like this with driver 3.27 allrady..and stays like this with driver 4.04.. Is this intentional, or a byproduct of a class compliant driver? or just a little bug that can be fixed? I ve actually a class compliant m audio uno midi interface that shows with name, despite not having an own driver...

Thanks and greets, 3p

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

magebarf wrote:

El Duderino, when this happens, and you believe it to be swapping, have you checked out the disk io stats from the activity monitor?

Just open the activity monitor, go to the tab "Disk" and at the bottom you will see "Data read/sec" and "Data written/sec" that will be of interest. I'm also manically trying to keep track of the total data written since last power on due to rumored swap issues where the M1 computers were writing almost the full disk size daily due to some strange phenomenon.

If those numbers are spiking, it could be interesting to sort the process list above by bytes written as well, to see what process is responsible. But more likely than anything, if it is swapping, it will be hidden behind the kernel_task process...

I am sorry but before checking this I had to revert back to the non-beta drivers (which crashes the mac daily) because of all the crashes even after a restart. It's absolutely not usable. Now even the 3.27 driver with extension removal hangs during installation.

Dear MC, one aspect you should consider when testing: not everybody has the Fireface permanently switched on. Maybe this brings some trouble but when I think about it – even after a restart with a FF UCX connected the clock ticks.

This whole RME experience is the opposite of the years with a windows PC. Very strange.

32

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

Dear El Duderino, we work with our units every day, the whole day. Still can not reproduce any memory eat-up - and it seems others (so far) also can't.

To be able to do so we would need more details, and maybe a simple example of a setup where this happens after some time. One important detail is to know how you used the RME. Was it selected as default system playback? Is it something simple then like watch YouTube on Firefox for 2 hours (audio via RME) to see the effect?

Regards
Matthias Carstens
RME

33

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

3phase wrote:

Is this an Ableton problem? Or Apples core audio/midi?

You seem to have missed that all RME USB 2 devices don't use an RME MIDI driver - it is Apple's Class Compliant MIDI driver that is in use. So it is quite unlikely that we can address this special effect.

Regarding the naming: we have tried to give it an own name, but due to the unusual combination of driver-based audio and Class Compliant MIDI it just doesn't work in macOS, sorry. If you switch RME hardware into full CC mode (like with the UFX and others where this option is available) the respective name is there.

Regards
Matthias Carstens
RME

34 (edited by 3phase 2022-06-27 14:32:40)

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

MC wrote:
3phase wrote:

Is this an Ableton problem? Or Apples core audio/midi?

You seem to have missed that all RME USB 2 devices don't use an RME MIDI driver - it is Apple's Class Compliant MIDI driver that is in use. So it is quite unlikely that we can address this special effect.

Regarding the naming: we have tried to give it an own name, but due to the unusual combination of driver-based audio and Class Compliant MIDI it just doesn't work in macOS, sorry. If you switch RME hardware into full CC mode (like with the UFX and others where this option is available) the respective name is there.

Thanks, I feared that this is the case. Can't you have an own driver too that maybe handles the midi more in a rme style accurate fashion? With the audio you also don't rely on apples core audio and midi stays important in production and is a huge benefit of the rme interfaces.. Even with extra dedicated midi interfaces in the studio the rme mid came in very handy and allways been extra stable priority ports for sensitive data like the clocking source.

So i ve to assume that the older fire faces have a better midi performance than your new devices? I never had to readjust the offsets with the fire faces and older rme interfaces. That's actually not good, and apple not really known to address midi problems.. But this all explains why Logic is the only daw that can't clock properly while doing an audio recording..They rely on their shitty core midi too, and this messes up the clock offsets on each rec start of logic.. a bug that remained for over a decade now.. So you cant hope for fixes on apples side. To sync audio and midi streams should be property of the main audio drivers.. do you plan to outsource the audio too and have it all cc on apple? No good idea if you want to remain the  industry leader for interface solutions.. best regards

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

In my last comment on this beta driver I was on Big Sur and noted that 4.04 was higher CPU load than 3.27 but I've since updated to Monterey 12.4 and tried 4.04 again. It seems the load is reduced by comparison. Could this be possible?

Kind regards

__________________________
Paul Najar
Jaminajar Music Production
www.jaminajar.com

36

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

One strange behaviour I have noticed, unchanged from regular driver and regardless of Babyface or Babyface Pro FS is that I get audio dropouts when I am using Apple Magic Trackpad as wired and in the same USB controller as Babyface. Audio breaks for fraction of a second whenever I press to select. I have tried to use powered hub, but it does not help. Problem does not occur when using Trackpad via Bluetooth, but I would much prefer wired use so I that I could switch peripherals between machines quickly.

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

I am trying to pinpoint a problem I've been having recently. It started around the same time as when I installed the V4.04 beta driver.

It used to be that I could leave my Mac on for days/weeks without any problem, but lately it becomes unusably slow in half a day or at most up to a day or two. I have found that my memory usage is larger than before and sometimes a large a amount of swap space is used. In Activity Monitor, kernel_task uses 16 GB and more.

So I'm thinking of installing the V3 driver to see if that fixes the problem. But before I do, let me know if there is anything else I should check w/regards to the V4 driver.

Thanks,
Ben

UFX, iMac 27" late 2014, quad i7, 32 GB ram, 1TB SSD, OSX 11.7, Logic 10.7.4, Final Cut 10.6.4

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

MC wrote:

Dear El Duderino, we work with our units every day, the whole day. Still can not reproduce any memory eat-up - and it seems others (so far) also can't.

To be able to do so we would need more details, and maybe a simple example of a setup where this happens after some time. One important detail is to know how you used the RME. Was it selected as default system playback? Is it something simple then like watch YouTube on Firefox for 2 hours (audio via RME) to see the effect?

Sorry I had to roll back to the old driver and voila the symptoms disappeared. (But now I have again the pink screens when the card is switched off after returning from standby – the whole reason I tried out the beta drivers was to avoid that annoyance)

I am happy to give you as much information as you need to find a solution for the problem. Thanks for acknowledging that it is not just "my system". :-)

The card is connected via a Lindy USB3 7port hub (got it from Thomann, for me at least a proven brand). Beside the card I have DSoniq Realphones installed. That is a headphones correction tool which runs also a system wide audio driver so even non-plugin hosting applications can be heared "corrected". So this is my system default audio output (Realphones System-wide). Within that the FF UCX is selected as output with 128 samples of buffer. Of course in Reaper I have the plugin loaded in the monitoring chain. So to trigger the "your system has no application memory anymore" dialog I just have to play some audio. No matter the application. It can be Firefox playing Youtube or Soundcloud. Or IINA (way less RAM usage). Or Ableton. And again: it does not matter how many programs are open. The dialog will reappear eventually even when the last remaining application running is finder. The whole process needs around two hours. If I start with a lot of programs open of course the dialog appears earlier.
After a restart I can open up as much RAM-heavy applications as I like and use the FF UCX. Beside the dropouts it works. But time will come and the dialog starts hitting (it's funny how the system closes without asking background apps like calendar and mail beside that) as long as audio is played. The system works fine for more than two hours when not playing any audio (but a connected UCX running).

Please tell me what you need exactly for information (dumps, screenshots whatever) to further get behold of this.

39 (edited by Christian Baum 2022-07-05 21:49:10)

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

Just some short feedback so far: Received Mac studio & Babyface Pro FS. Updated BF to FW 200 on my old iMac and then installed it first thing on the new Mac using the newest beta driver. My plan was to leave kext behind without even trying it - my old FF800 has to either go or be used as an ADAT converter for the BF.

Everything looks fine. I'm not into performance comparisons or anything. I just want to use Logic with high quality converters and lots and lots of software instruments and a few hardware synths.

Installation has been a breeze, Total Mix works fine, Logic is at 64 samples latency and works. No killer tracks or huge productions just yet, but for the naked eye, I got a good first impression.

This week however, I will also receive my UAD Satellite TB3 (replacing my Firewire unit), and they're far from DriverKit, it seems. I hope, mixing RME's beta driver with legacy kext tech won't pose any problems. Will report back.

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

There's still something weird happening with 4.04 and a UFX+ talking via MIDI-over-MADI to an Octamic XTC:
I have it setup to monitor our in-ears and every couple of minutes the Gain of Octamic Mic In 1 will go crazy (way into the red for about 3 seconds, then it goes back to normal). Octamic Mic In 1 is on MADI 9 and that's the only channel that does this.

Other than that I got a freeze and lockup of TotalMix FX when initiating a restart of my Mac Studio.

All back to normal when using the old driver.

Best,
Frank

Happy Fireface UFX+, Octamic XTC and M-32 Pro user.
http://www.stoersender-studio.ch

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

Can it be the case that you are mixing two different kinds of remote management protocols.
TM FX and RME MIDI remote ? You can only use one of the two on the same MADI bus.

BR Ramses
UFX+, 12Mic, XTC, ADI-2 Pro FS R BE, RayDAT, X10SRi-F, E5-1650v4, Win10Pro22H2, Cub12Pro

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

I turned off the DIN Midi control options on the XTC and the UFX+ and switched to
Midi Port 3 for Midi over Madi as described in the manual.
Also, it's weird that it only happened on Madi 9.

I'll try to reproduce it again if the muse strikes me ;-)

Happy Fireface UFX+, Octamic XTC and M-32 Pro user.
http://www.stoersender-studio.ch

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

I updated my M32 Pros with the latest Firmware which lists improved MIDI over MADI support. It seems to work now, let‘s see if it holds!

Happy Fireface UFX+, Octamic XTC and M-32 Pro user.
http://www.stoersender-studio.ch

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

any time window, when the final version of the driver is expected? i guess this public beta is pretty stable but i am gonna wait untill the final release.

45

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

We are working on 4.05 which hopefully is the final release then.

Regards
Matthias Carstens
RME

46 (edited by 3phase 2022-07-23 21:14:21)

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

MC wrote:

https://archiv.rme-audio.de/images/bfpro_loopback_works.png

But how did you managed to get the babyfaces outputs as source for digichek NG?

They are not available for me on Digicheck NG with driver 4.04 firmware v200 on babyface pro FS with macbook air M1.
Do i miss a button again, or do i ve just to wait for the next beta? Thats what i ve assumed when i found that Add playback channels setting is greyed out on my setup with Digicheck NG 0.89beta1…

47

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

3phase wrote:

But how did you managed to get the babyfaces outputs as source for digichek NG?

By pushing the Loopback button...DC shows the input (record) channels.

3phase wrote:

They are not available for me on Digicheck NG with driver 4.04 firmware v200 on babyface pro FS with macbook air M1.Do i miss a button again, or do i ve just to wait for the next beta? Thats what i ve assumed when i found that Add playback channels setting is greyed out on my setup with Digicheck NG 0.89beta1…

You are the second person to report this, thanks. We will check why this happens to some after the German summer holidays.

Regards
Matthias Carstens
RME

48 (edited by 3phase 2022-07-24 04:25:27)

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

MC wrote:

You are the second person to report this, thanks. We will check why this happens to some after the German summer holidays.

oh, just 2? but i also just reported it by accident because i didnt expected the first beta to do it all already. But thanks for future fixes, Will be nice to have that feature, wish you nice holydays.

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

3phase wrote:
MC wrote:

You are the second person to report this, thanks. We will check why this happens to some after the German summer holidays.

oh, just 2? but i also just reported it by accident because i didnt expected the first beta to do it all already. But thanks for future fixes, Will be nice to have that feature, wish you nice holydays.


Hi ya.. I think I am the other one. :-)
The playback option is greyed out for me too, but the loopback method continue to work fine for me.

----------------
Matt McKenzie-Smith (UFXII, UFX, Babyface) MacStudioUltra OS12.4
----------------

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

After upgrading to 4.04 I was getting really big drop outs in larger projects in Bitwig, to the point where the track just stopped. Moved back to 3.27 and works flawlessly. Definately needs a little more time in the oven.