Thanks. I'll read it.

Anyway. after a few days of regular use, I give the new 1.08 DK driver for the HDSPe AES card an A- rating. The previous kernel driver on my Intel Mac Pro gets an A+ rating because it was literally perfect and stable.

So far, the only issue I see with the new 1.08 DK driver is that when I'm playing audio in REAPER and open iZotope RX (which uses the same AES card and main outputs), there is a slight audio glitch that sounds like a skipping sound as the app opens.

So far, this hasn't been an actual problem because when I am recording back in from my analog mastering chain, I am not opening RX or doing other computer tasks.

It does make me nervous that other computer activity (sometimes out of my control such as a notification or background task) could trigger a dropout or glitch during a playback/record process. That's not a good feeling to have.

On the positive side, before I record back in from my analog mastering chain and I'm just dialing things in and listening, I am often doing tasks in other apps (Safari, Apple Mail, and other misc apps) and so far, that activity DOES NOT seem to be causing any interference or hiccups and so far, none of my recordings have had a dropout or glitch that I have detected.

The only other thing I notice is that in the HDSPe setting app, the "Termination" check box seems to keep enabling itself.

I'm honestly not sure if I need to have it on or off but even if I turn it off, it comes back on. I don't remember the older version doing that.

With my main AES card, I have it set to "AutoSync" and my Crane Song HEDD is the master clock. The RME card gets clock from word clock output of the HEDD Quantum and the other word clock outputs of the HEDD Quantum feed my other converters. It seems OK.

With my other AES card (used for WaveLab only), the AES card is the master clock. It seems OK.

Is it correct to set both cards to Terminate? For some reason both devices are automatically setting themselves to have Termination on. Even if I turn it off, it just goes back to on.

As for RX, it's not really an issue because I just launch RX one time during a cleanup session and then it stays open until I'm done with the session. I'm not constantly opening and closing it. I don't really care for the RX Monitor method. In REAPER, I can just send copies of selected audio to RX to repair and then save & close in RX and the edited piece is active in REAPER. I think it's called "Open Item Copy" in REAPER. I have a very fast method for sending small sections of audio to RX to clean up rather than entire song.

For me, I'm able to use both apps using the same device and outputs which saves me from toggling my monitor controller when I am doing a lot of fast RX edits between REAPER and RX. I can hear my main work in REAPER from outputs 1/2 and then when I open a copy of a section in RX to fix it, I can hear that without having to touch my monitor controller.

That worked great on my Intel Mac Pro and is working on the new Mac Pro. It's just that when I was stress testing things, the only time I could make the AES card have an issue is opening RX when REAPER is playing audio. So it's kind of a non-issue, just a new behavior that makes you wonder if other things (out of your control) could trigger an issue.

Interesting. I don't find that REAPER and RX fight each other. I toggle between the two quickly and smoothly when I'm listening to my captures in REAPER or editing small sections in RX.

There is a setting in RX to "Release When Not In Use" which may help you.

Anyway, thanks for the other help.

The new version uses a newer FPGA, the old one wasn't available anymore. Otherwise the cards did not change in features and performance. The only one that has a small change is what you see now: new AES cards have a WC termination that is controlled  from the Settings dialog. But you have the old card, you need to use the blue jumper, and the display of that option needs to be removed when old cards are used. After next driver update...

Good to know, I can imagine Apple ditching the kernel driver option with Sonoma. Just a guess...

I uploaded new DriverKit firmware for most of the HDSPe series. When this firmware is used together with the new driver 1.09, then there will be no dropouts/clicks when buffer size is very small (like 32 or 16 samples) and the TotalMix FX windows is open to show all I/O levels.

This issue does not affect the HDSPe MADI FX, and the older HDSPe PCIe and ExpressCard. It is also no issue with the Kernel based driver.

I'm still getting lots of dropouts with the 1.09 driver. Everything seems to be running perfectly when Totalmix is either minimized or not running. As soon as I open the Totalmix window the pops and glitches start happening. It happens regardless of which application I'm using--Logic Pro X, playing YouTube videos in Safari e t c. I've tried changing buffer sizes between 32 all the way up to 1024 but the behavior is identical.

I have a HDSP Raydat and I'm on Monterey 12.6.6 on an iMac 2019. The kernel driver works without any issues on this system.

The latest firmware updater (released 2023-06-23) does not allow me to go above "v19, driverKit comp." It says programming status is "Up-to-date". How can I get to the firmware 20 that you mentioned?

So far DK 1.09 seems solid, and I think I'm up to date on card firmware too:
https://www.dropbox.com/s/nff7d6azqc6s6 … M.png?dl=0

I still get a slight disruption if I have audio playing in REAPER and then launch iZotope RX (without opening an actual audio file) which shares the same AES card, but other than that which at this time isn't a real problem, it feels very solid and stable.

That's the only thing I'm able to do to trigger any issues while stress testing the cards. It's fairly minor and not an issue to my actual workflow.

I'm talking about the initial launch of RX causes. the disruption, not just toggling back and forth and sending audio back and forth once RX is open.

I'm only having the occasional very rare dropout under heavy CPU load and switching between applications. Apart from that the latest driverkit driver has been completely stable for the last week or two.

Are Spotify / YouTube set to be using the same RayDAT card? Or do Spotify / YouTube use another audio device but still cause your RayDAT to glitch or dropout?

That's probably helpful for RME to know. I have a few RME cards (two AES and one AIO Pro) so I have my computer and streaming services set up to use another card entirely, so I can't really trigger any disruptions. But, I have noticed a slight hiccup if I have audio from REAPER playing out of my RME AES card and then open iZotope RX which is set to use the same AES card as REAPER.

That is a new behavior that didn't exist with the old kernel drivers which seemed more immune to other apps that share that same card/device.

They seem to be occasionally. My guess is that Apple changed something that RME might have to account for.

For me the new behavior is not an issue as I have a few different cards for various things.

One other new thing I've noticed is that when I connect my USB-C SSD and Carbon Copy Starts to back up any new or changed files, the audio starts skips (sounds like when a CD used to skip and repeat the same split second over and over) for a second or two.

I can't tell if it's an Apple thing or an RME but it's new.

Basically, the newer drivers seem to be more sensitive to other things happening on the Mac than the older kernel drivers were.

FWIW, I ordred a new AES card and installed it today. It's the newer version (Rev 2.0). My two other AES cards are the older legacy versions.

Anyway, the FWIW part is that I no longer have the CD skipping sound issue when I am playing audio from the new card and open an app that shares the same card/outputs, and when I connect my back up drive as mentioned in post 177 I don't get the major stuttering/skipping issue.

The newer Rev 2.0 version of the AES card appears to be immune to disruptions from other actions/tasks on the Mac.

Thanks! I have been testing but for whatever reason, the Rev 2.0 card is immune to disruptions from other apps that share the same card, while the Rev 1.0 card had been giving a slight glitch when I open another DAW that was set to use the same card. Other users report more severe disruptions.

It would be great to know if the settings app is unintentionally limited to three cards as fixing that would help me troubleshoot my other issue of one my AES cards not wanting to adapt to the sample rate of the incoming AES signal when it is set to AutoSync.

As mentioned in the other thread, it can handle changes from 44.1k to 48k and back to 44.1k no problem, but if I go from 44.1k to 96k in my DAW, the card that is playing the audio is fine but the extra card that is meant to be a metering input will only change to 48k. If I manually set the AES card to 96k it works, but when I go to play a 44.1k file, the card playing the audio changes to 44.1k no problem but the other card that is set to AutoSync goes to 88.2k.

Again, these cards are not linked or sync'd together, I'm using the 3 AES cards as individual interfaces.

I would see how the AIO Pro responds to incoming sample rates changes via AES but since the settings app is limited to 3 cards, I can't really do that easily and I'm tired of taking my Mac Pro apart to add/remove cards.

Yesterday I was live streaming while my production software (Ableton) was open, and I am getting lots of clicks and pops and glitches - which has never happened before with the previous driver.

I am on v1.09 rev 210.

Can someone please direct me with instructions how to roll back to the current (non beta) driver? This version is currently unusable for me.

Thanks for this.

I've downgraded to 4.24 / rev 207 and now my RayDAT is working flawlessly again. No skips, pops, etc. This tells me that the driverkit version is still buggy.

We cannot release an app that fixes a bug (!) in the macOS on lowest system level. That said AFAIK the bug is gone in latest OS versions (as it was in earlier ones). Uninstallation now works again as it should. That's why this topic no longer comes up here.

FWIW, if this is an Apple bug it's not fixed in 13.5

Humbly, for an old guy, what bug are you reffering to?

Best,
Pål

I think he was referring to the removing of the kext driver. In what way did you notice Sonoma is better specifically? I feel this might be a very good OS for audio from other sources as well...

Nice!
Kext drivers still work right?

yes, they still work on Sonoma

Thanks for sharing, that's great news !
May I ask what buffer size you use ?