151 (edited by Jperkins 2023-06-20 12:28:54)

Re: New macOS RME HDSPe series driver – public beta test (1.07)

MC wrote:
Jperkins wrote:

@MC:

On the website it mentions that DK 1.08 brings the AES cards to version 11, but I'm seeing version 12 here. Is that a website error?

Do I have the current versions of things?

https://www.dropbox.com/s/ndx58ukxcikj7 … M.png?dl=0

DK 1.08 is a driver download and does not have info on firmware versions. The Mac FUT download lists the Legacy version of all cards (here 11), not the DK versions, so it is correct.

Thanks for the info. It's all somewhat confusing to me but when it says "AES to 11/204", does mean Rev. 11? That's why I wondered why/how I'm on Rev. 12 and also, why is it always two numbers like 11/204?

it also says "AIO Pro to 23" which does match my HDSPe settings app but for my AES cards it says Rev. 12 and the website just says 11/204.

I think the presentation and wording of these updates could be made a little simpler for non-programing folks.

152

Re: New macOS RME HDSPe series driver – public beta test (1.07)

The FUT download includes a readme that explains the numbers, and more.

Regards
Matthias Carstens
RME

153 (edited by Jperkins 2023-06-20 14:40:56)

Re: New macOS RME HDSPe series driver – public beta test (1.07)

MC wrote:

The FUJT download includes a readme that explains the numbers, and more.

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.

Re: New macOS RME HDSPe series driver – public beta test (1.07)

Jperkins wrote:
MC wrote:

The FUJT download includes a readme that explains the numbers, and more.

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.

Unless you are linking word clock from the WCin of the RME you can keep it checked.
As for Izotope, a possible workaround might be to use RX monitor to the plugin in your daw. That's what I do, because RX os one of those mac app that "take over" your device.

155 (edited by Jperkins 2023-06-20 15:41:10)

Re: New macOS RME HDSPe series driver – public beta test (1.07)

mlprod wrote:

Unless you are linking word clock from the WCin of the RME you can keep it checked.
As for Izotope, a possible workaround might be to use RX monitor to the plugin in your daw. That's what I do, because RX os one of those mac app that "take over" your device.

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.

Re: New macOS RME HDSPe series driver – public beta test (1.07)

Jperkins wrote:
mlprod wrote:

Unless you are linking word clock from the WCin of the RME you can keep it checked.
As for Izotope, a possible workaround might be to use RX monitor to the plugin in your daw. That's what I do, because RX os one of those mac app that "take over" your device.

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.

Yes you can have both terminated. I also use RX on the same output as Reaper, just that I don't like it taking over when opening it. RX monitor plugin is on a channel that does nothing else than sending that input to main outs.

Re: New macOS RME HDSPe series driver – public beta test (1.07)

mlprod wrote:
Jperkins wrote:
mlprod wrote:

Unless you are linking word clock from the WCin of the RME you can keep it checked.
As for Izotope, a possible workaround might be to use RX monitor to the plugin in your daw. That's what I do, because RX os one of those mac app that "take over" your device.

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.

Yes you can have both terminated. I also use RX on the same output as Reaper, just that I don't like it taking over when opening it. RX monitor plugin is on a channel that does nothing else than sending that input to main outs.

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.

Re: New macOS RME HDSPe series driver – public beta test (1.07)

MC wrote:

The FUJT download includes a readme that explains the numbers, and more.

OK, I read the Read Me but that brings up this question.

What is the difference between a Modell card and a Legacy card?

I seem the Modell version is a new variation but are there any notable changes? Mine are both Legacy apparently as they show Rev. 12.

When the HDSPe AES cards are in stock again, will they be the Modell version?

159

Re: New macOS RME HDSPe series driver – public beta test (1.07)

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

Regards
Matthias Carstens
RME

Re: New macOS RME HDSPe series driver – public beta test (1.07)

MC wrote:

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

Thanks for the info. Anyway, after nearly a week with the 1.08 DK drivers on MacOS 13.4, I'm pretty happy with performance.

Re: New macOS RME HDSPe series driver – public beta test (1.07)

Jperkins wrote:
MC wrote:

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

Thanks for the info. Anyway, after nearly a week with the 1.08 DK drivers on MacOS 13.4, I'm pretty happy with performance.

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

162 (edited by Jperkins 2023-06-23 14:13:27)

Re: New macOS RME HDSPe series driver – public beta test (1.07)

In addition, it's been nice that (so far), my AIO Pro card does not go missing overnight or after the computer has been idle.

With my last Mac Pro and whatever drivers/software I had installed, my AIO Pro card would often go missing and show Rev. 0. The only way to fix it was to shut down the computer, and unplug the power cable for a moment and then restart.

After a week of solid use, that hasn't happened on the new Mac Pro and latest RME drivers.

163

Re: New macOS RME HDSPe series driver – public beta test (1.07)

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.

Regards
Matthias Carstens
RME

Re: New macOS RME HDSPe series driver – public beta test (1.07)

MC wrote:

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.

Thanks! I have a short today and gone most of the weekend but I will try the new version Sunday evening or Monday.

I appreciate the great support.

165 (edited by a-stream 2023-06-25 04:19:18)

Re: New macOS RME HDSPe series driver – public beta test (1.07)

MC wrote:

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.

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.

166

Re: New macOS RME HDSPe series driver – public beta test (1.07)

If upping the buffer size does not fix that (and you updated to firmware 20 or 209) then you have a different issue out of our control.

Regards
Matthias Carstens
RME

Re: New macOS RME HDSPe series driver – public beta test (1.07)

MC wrote:

If upping the buffer size does not fix that (and you updated to firmware 20 or 209) then you have a different issue out of our control.

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?

Re: New macOS RME HDSPe series driver – public beta test (1.07)

MC wrote:

If upping the buffer size does not fix that (and you updated to firmware 20 or 209) then you have a different issue out of our control.

Nevermind my previous response--I ran the latest firmware updater and I was able to get to firmware 20 (even though it said I was up-to-date at first). Good news! It greatly mitigated the issue with my pops and glitches. Streaming videos on YouTube in Safari now works without issue. It's not quite as CPU friendly as the kernel driver still--I'm getting some glitches on very large and taxing Logic sessions which I didn't get before with the kernel driver. If raise the buffer setting to 512 or 1024 it looks like things are fine. So this driver is a great step up from 1.08 that was completely unusable on my system.

169 (edited by Jperkins 2023-06-26 17:26:58)

Re: New macOS RME HDSPe series driver – public beta test (1.07)

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.

Re: New macOS RME HDSPe series driver – public beta test (1.07)

Jperkins wrote:

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.

Still good with no dropouts?

Re: New macOS RME HDSPe series driver – public beta test (1.07)

mlprod wrote:

Still good with no dropouts?

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.

172 (edited by GeometryGod 2023-07-09 08:03:34)

Re: New macOS RME HDSPe series driver – public beta test (1.07)

I'm running driver 1.09, firmware v210 on my RayDAT

I am getting intermittent audio glitches and stutters when running Spotify / YouTube in conjunction with Ableton projects. I did not have these issues before upgrading to the DriverKit version.

Re: New macOS RME HDSPe series driver – public beta test (1.07)

GeometryGod wrote:

I'm running driver 1.09, firmware v210 on my RayDAT

I am getting intermittent audio glitches and stutters when running Spotify / YouTube in conjunction with Ableton projects. I did not have these issues before upgrading to the DriverKit version.

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?

174 (edited by GeometryGod 2023-07-10 07:08:15)

Re: New macOS RME HDSPe series driver – public beta test (1.07)

Jperkins wrote:
GeometryGod wrote:

I'm running driver 1.09, firmware v210 on my RayDAT

I am getting intermittent audio glitches and stutters when running Spotify / YouTube in conjunction with Ableton projects. I did not have these issues before upgrading to the DriverKit version.

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?

Both Ableton and my system audio (including Spotify / YouTube) are set to the RayDAT.

175 (edited by Jperkins 2023-07-10 16:09:51)

Re: New macOS RME HDSPe series driver – public beta test (1.07)

GeometryGod wrote:
Jperkins wrote:
GeometryGod wrote:

I'm running driver 1.09, firmware v210 on my RayDAT

I am getting intermittent audio glitches and stutters when running Spotify / YouTube in conjunction with Ableton projects. I did not have these issues before upgrading to the DriverKit version.

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?

Both Ableton and my system audio (including Spotify / YouTube) are set to the RayDAT.

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.

Re: New macOS RME HDSPe series driver – public beta test (1.07)

Jperkins wrote:
GeometryGod wrote:
Jperkins wrote:

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?

Both Ableton and my system audio (including Spotify / YouTube) are set to the RayDAT.

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.

Yeah - it's actually quite bad. I commonly switch between apps, and this is becoming a pretty big issue (and it was never an issue before). How do we submit feedback for this build? Is RME checking this thread?

Re: New macOS RME HDSPe series driver – public beta test (1.07)

GeometryGod wrote:

Is RME checking this thread?

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.

Re: New macOS RME HDSPe series driver – public beta test (1.07)

Jperkins wrote:
GeometryGod wrote:

Is RME checking this thread?

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.

Yes - I seem to have a similar behavior (CD skipping sound). This only started happening with the new drivers.

Re: New macOS RME HDSPe series driver – public beta test (1.07)

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.

180

Re: New macOS RME HDSPe series driver – public beta test (1.07)

I doubt any differences. And we'll check if the Settings dialog is unintentionally limited to three cards.

Regards
Matthias Carstens
RME

181 (edited by Jperkins 2023-07-19 17:46:43)

Re: New macOS RME HDSPe series driver – public beta test (1.07)

MC wrote:

I doubt any differences. And we'll check if the Settings dialog is unintentionally limited to three cards.

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.

Re: New macOS RME HDSPe series driver – public beta test (1.07)

OK, as of yesterday the symptoms of other apps that share my Rev 2.0 AES card and a few other misc tasks on the Mac causing an audio disruption is back.

I'm not sure why that issue went away but as I went back to my previous setup (2 independent AES cards, AIO Pro card, and MiniDSP AES/USB device for metering input), the issue came back at some point.

Re: New macOS RME HDSPe series driver – public beta test (1.07)

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.

184 (edited by waedi 2023-07-21 17:44:51)

Re: New macOS RME HDSPe series driver – public beta test (1.07)

The driver download folder has a readme text, scroll down to the last page.
Instructions for installing and uninstalling is there.
Short : You can delete the settings dialog application use the Finder.
Then install the desired driver following it's install instructions.
Also read this info page :
https://rme-audio.de/driverkit-info-hdspe.html

M1-Sonoma, Madiface Pro, Digiface USB, Babyface silver and blue

Re: New macOS RME HDSPe series driver – public beta test (1.07)

waedi wrote:

The driver download folder has a readme text, scroll down to the last page.
Instructions for installing and uninstalling is there.
Short : You can delete the settings dialog application use the Finder.
Then install the desired driver following it's install instructions.
Also read this info page :
https://rme-audio.de/driverkit-info-hdspe.html

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.

Re: New macOS RME HDSPe series driver – public beta test (1.07)

GeometryGod wrote:

This tells me that the driverkit version is still buggy.

Yeah, something is definitely up and different from the kernel versions.

What's weird is that for awhile my Rev 2.0 wasn't having the issue but then eventually it came back. I am trying to retrace my steps and see what changed but as of now, I wonder if it's related to computers that once had the kernel installed and then upgraded to DriveKit.

I was getting an issue that said I had both drivers installed and the method of uninstalling the kernel version after doing the firmware on my new card felt a little sketchy.

I wish this update process was simpler and RME issued a simple and direct kernel version uninstaller app to remove any deep dark trace of the kernel driver so we can be sure that only the DriveKit files are present and there isn't any conflict happening behind the scenes.

187

Re: New macOS RME HDSPe series driver – public beta test (1.07)

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.

Regards
Matthias Carstens
RME

188 (edited by Jperkins 2023-07-22 15:34:21)

Re: New macOS RME HDSPe series driver – public beta test (1.07)

MC wrote:

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.

I'm using MacOS 13.4.1

When I tried to "uninstall" the kernel driver a few days ago after needing to install it to update the Rev 2.0 card to the latest firmware to work with the DriveKit, I didn't have an easy time installing it. I had never put the kernel driver on this Mac Pro before because my older cards had already received the firmware update.

Despite dragging the app to the trash and installing the 1.09 driver, I was getting the message about having two conflicting drivers installed. I forgot to save a screen shot.

After an hour or two of screwing around I finally found a forum thread that said to reduce the security settings again to prevent the kernel version from loading but this doesn't seem like a way to fully un-install it.

I fear some remnants of the kernel version now exist and maybe that is part of the minor glitch I experience.

Looking back, I should have had used my laptop to update the card since despite having the same new MacOS, I don't rely on it for AES card use.

I wish I could remove all deep dark traces of the kernel version to be sure.

Re: New macOS RME HDSPe series driver – public beta test (1.07)

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

Re: New macOS RME HDSPe series driver – public beta test (1.07)

I've just tried switching from the kernel to DK driver for my MADI FX card (running in a PCI-E enclosure on MacOS 13.5) and weirdly, I can't get the flash update to work...

It says that the Current Revision is "92, Legacy" and the New Revision is "92, DriverKit comp." but the programming status is Up-to-date, so it won't run an update to switch from Legacy to DK.

I tried installing the DK anyway, but then the HDSPe settings app just crashed immediately on opening, so I've uninstalled that as per the instructions for rolling back.

Any suggestions welcome!

Re: New macOS RME HDSPe series driver – public beta test (1.07)

MC wrote:

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.

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

Best,
Pål

Re: New macOS RME HDSPe series driver – public beta test (1.07)

psvennevig wrote:
MC wrote:

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.

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

Best,
Pål


I believe MC is referring to the Core Audio issues in Ventura and Big Sur before that. It is fixed in Mac OS Sonoma.

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

Re: New macOS RME HDSPe series driver – public beta test (1.07)

mattrixx wrote:

I believe MC is referring to the Core Audio issues in Ventura and Big Sur before that. It is fixed in Mac OS Sonoma.

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

Re: New macOS RME HDSPe series driver – public beta test (1.07)

mlprod wrote:
mattrixx wrote:

I believe MC is referring to the Core Audio issues in Ventura and Big Sur before that. It is fixed in Mac OS Sonoma.

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

The Core Audio issues are completely fixed, in my experience (MacStudio Ultra and MacbookProMax). No interaction between notification sounds/system alerts and Core Audio.
(Hearing from others that the same may be for the Ventura 13.6 released today.. though I cannot confirm.)

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

Re: New macOS RME HDSPe series driver – public beta test (1.07)

mattrixx wrote:
mlprod wrote:
mattrixx wrote:

I believe MC is referring to the Core Audio issues in Ventura and Big Sur before that. It is fixed in Mac OS Sonoma.

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

The Core Audio issues are completely fixed, in my experience (MacStudio Ultra and MacbookProMax). No interaction between notification sounds/system alerts and Core Audio.
(Hearing from others that the same may be for the Ventura 13.6 released today.. though I cannot confirm.)

Nice!
Kext drivers still work right?

Re: New macOS RME HDSPe series driver – public beta test (1.07)

To be honest I have no idea.  I don’t have any other kext drivers either.
But DriverKit working great

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

Re: New macOS RME HDSPe series driver – public beta test (1.07)

mlprod wrote:
mattrixx wrote:
mlprod wrote:

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

The Core Audio issues are completely fixed, in my experience (MacStudio Ultra and MacbookProMax). No interaction between notification sounds/system alerts and Core Audio.
(Hearing from others that the same may be for the Ventura 13.6 released today.. though I cannot confirm.)

Nice!
Kext drivers still work right?

yes, they still work on Sonoma