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.

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.

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.

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

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)

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

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.

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.

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.

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?

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.

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

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...

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

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?

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

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.

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.

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

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 ;-)

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.

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…

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.