Thanks. I was able to check my configuration. It seems that the driver is reporting a wrong RTL sample count:

I get an offset of 60 samples at 48K as well as 44.1K : the reported RTL is always 60 samples lower.
Buffer 512: 1177/1117
Buffer 256: 665/605
Buffer 128: 409/349
Buffer 064: 281/221
Buffer 032: 217/157 (works only at 44.1K @AIO)

I am pretty sure that most of the other card model values are correct, but we will recheck the AIO. Thanks.

I think I found the issue with the my AIO: After the firmware update, the card is identified as AIO Pro(3), Rev. 200
In the past, there was the serial number in the brackets and I am 1000% sure that it is an old AIO.

After jumping back to the 4.22 driver, I am able to play 32 samples buffer @48K (not really important, just fyi)
The identification is still AIO Pro (3), Rev. 200

Within the HDSPe Settings, it looks different:
I can choose between +24/+19/+13/+4 dBu input and output
Phones ist now Hi-Power and Lo-Power

Could this be a false identification of the card which results into false reported latency figures - since these cards have different converters?

(If you need screenshots etc please let me know.)

Unplug - replug the chassis. Else start the settings app manually (it's in Applications).

Drift is not supported, the units must be synced by word or digital signals.

I had the same issues (reported it on the first page of the thread) and it had something to do with macOS not really "allowing" the driver. The fix is the following:
- boot in recovery mode (shut down MacBook and turn it on while holding power button)
- open terminal
- enter csrutil disable (to temporarely disable SIP) and follow instructions
- when completed, you don't have to reboot
- now enter csrutil enable (to re-enable SIP again)
- reboot into macOS
- you'll now get asked by the OS to allow all drivers again in system settings, which you have to do
- reboot again (system will ask you to do so)

the HDSPe settings app should load now and no longer crash and the driver works properly, also the firmware utility should display the correct firmware now

Hm, for me that fixed everything. Do you see your AIO in the HDSPe settings?

I updated the opening post with driver 1.06 and 4.23 (and DigiCheck NG 0.891):

Version 1.06

- Bug fix AIO incorrectly recognized as AIO Pro. This bug was present in driver 4.22 as well.

- Bug fix MIDI hangs. Only affected older generation of interfaces (not MADI FX/XT, not revision 2 cards)

- Latency values of AIO/AIO Pro fixed

The Driver 1.06 fixed the issue with the AIO (TB3 chassis --> Mac Studio)

• the card is correctly identified as AIO and the settings for input/output/phones level are as expected

• reported / measured latency is spot-on, as shown in the table below - except

• issue: @88.2K the values jumping around (reported as well as measured)

               44.1            48                88.2                96
032        217/217        217/217        297/297        297/297
064        281/281        281/281        361/337        361/361
128        409/409        409/409        457/441        489/489
256        665/665        665/665        745/721        745/745
512        1177/1177    1177/1177    1251/1209     1257/1257

Thanks for the feedback. The 88.2 issue seems not related to card or driver. 32 samples for example might simply be too low, and you have to check that RTL reports a proper signal received when measuring.

I understand you from that point of view but the problem though is that the channels get shuffled around in the DAW when I/Os change numbers like that which is...not good. For example I have two cards, the 2nd being AIO Pro in my case. Those I/Os will also move when changing sample rates so that it is impossible to have fixed assignments in the DAW, you basically need to have two (or three) sets of assignements and shuffle between them each time to work in a different sample rate.
Workflow killer.

Edit: Should also mention that after some testing it seems the dropouts when using system audio seems to have to do with aggregate devices them selves, as it is the same now with the legacy drivers and having two RME cards "aggregated". Is this something you can do anything about?

I just had this error message after waking up my MacBook from sleep (image upload):

https://ibb.co/KKNZCrP

Driver version is 1.06 and audio is still working though...

In case it helps anyone, Apple updated Monterey and Ventura earlier this week. Testing with the DK drivers for me, is *possibly* looking better than before. I seem to be able to drop down to lower buffer sizes without glitching.

Obviously I can't guarantee that some other factor isn't involved, but updating is worth a try.

We are making good progress in ironing out the last issues of this new, combined HDSPe series and FX driver. The first post has been updated to DK driver version 1.07. The driver itself is unchanged, but Settings dialog and TotalMix FX are new as they did not handle some card combinations correctly.

- Bug fix Settings dialog did not detect cards correctly during HotPlug/Unplug

- Bug fix TotalMix FX 1.79 did not work correctly for card combinations including the MADI FX

No comment on what I wrote in post 71? (regarding the channel numbering)
Can you maybe at least make it optional? I will definitely not be alone with this problem once people start installing this new driver.

The issue is that (in the case of MADI and ADAT) half of the I/Os disappear when switching between 48 and 96kHz. So if lets say an AES port lies after the MADI channels (like with MADI FX) you can't have a fixed output from the DAW using the AES port when switching between sample rates since the numbering will change.
The current kernel driver does not do this (but the new DK does) and I would like to be ablt to keep it like it is now at least as an option! This is regardless of aggregate device or not.

As for aggregate deivce, works great in the DAW but dropout occurs if you invoke Core audio for something else, like watching youtube, playing from spotify or whatever. This is with legacy and DK drivers and is probably Apples fault.

It doesn't matter what device you play system sounds from, the aggregate device in the DAW will still be "disturbed" by it. At least on all my macs.

Only audio here.

Driver 1.07, AIO Pro does not adjust its samplerate according to the sync input. Everthing looks right  in the sync box, but the actual device does not follow. I have manually change the sample rate in the dropdown. Tried both syncing from MADI FX via SyncIn and ADAT from another unit.

Okay, what's the point of slaving to a WC/sync signal then?

Anyway, I have given up on running two cards together, I will do fine with the MADI FX only.

Best/M

Okay, I guess this just didn't fit my intended setup, I need total sync follows on all devices. But anyway with MADI FX only (which I have settled on now) the 1.07 driver seems to work well, no problems whatsoever yet.

This feature is often called 'Follow Clock' and also present in some RME devices. It is not straight forward to implement because AES (in earlier times), ADAT and MADI use SMUX techniques to achieve higher sample rates via standard, single speed sample rates.

Thanks for doing these tests. Normally I am not afraid to try beta software but I've had a very turbulent and busy few months and haven't been able to take the time to read the confusing directions again and try to update.

At this point I will likely just keep the current drivers and then start fresh when I upgrade my Mac Pro when the M2 ones come out or move to a Mac Studio and go back to chassis world again within the next few months.

I do hope RME can get these drivers to be as stable as the classic drivers because as you say, they were basically perfectly immune from dropouts in mastering.

I've printed 3 hour sessions in one pass with moderate plugin load going on and not a single dropout or glitch. They were solid. Hopefully it's not the end of an era for RME stability.

Curious if there is any update from RME on the stability of the new drivers. At some point soon I plan to get a Mac Studio or the new Mac Pro (if/when it gets refreshed to M2) and would need to use the newer drivers I think.

It sounds like there are a number of reports of the new drivers not being as stable. Dropouts and glitches are not something I can really deal with on a regular basis and the excellent stability of the drivers I'm currently using are a big part of why I use two RME AES cards and an AIO Pro card in my main mastering setup.

Good to know. I hadn't fully investigated that but I just assumed the new ones had to be used to be fully Apple Silicon native. Even on my Intel Mac Pro with Monterey MacOS yells at me sometimes about the RME drivers being old after I restart the computer.

I have an M1 MacBook Pro but I don't use it with all my RME cards.

At some point this year (hopefully soon) I plan to get the Apple Silicon Mac Pro and would love for there to be no audio dropouts, issues, and have things be as stable as they've been in the past.

I know these are just a public beta right now but there were more issues reported than I would have expected since RME is known for incredibly stable drivers and performance.