51 (edited by drvdd 2023-01-17 23:07:51)

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

I'm running an AIO within a Sonnet TB-Case at a Mac Studio (OS 13.1). The new driver/firmware runs smooth.
Observations:
- Logic is reporting much lower latency figures!
- 48K/32 Samples went from ca 4.5ms down to 3.3ms roundtrip latency. (not stable with a M1 Max)
- 48K/64 Samples went from ca 5.9ms down to 4.6ms roundtrip latency. (stable with a M1 Max)
-48K/128 is now 7.3ms roundtrip latency

I'm not sure, if these numbers are legit, but it feels faster when using virtual instruments.
At 32 samples I am hearing crackles, even if the load monitor tells me that everything is fine. Going up to 64 samples, everything works fine without a higher system cpu utilization.

Logic is reporting 1.3ms input/2.0ms output latency at 32 samples - this seems to be improbable fast.
Question: is the driver reporting a wrong latency OR does the update actually improves the performance at such a high level?

52

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

You can check yourself with RTL Utility for Mac:

https://oblique-audio.com/rtl-utility.php

Regards
Matthias Carstens
RME

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

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)

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

MC wrote:

You can check yourself with RTL Utility for Mac:

https://oblique-audio.com/rtl-utility.php

Possibly worth mentioning for info, that Ableton has info on how to calculate and apply a Driver Error Compensation value.

https://help.ableton.com/hc/en-us/articles/115000234830

I went through the process some time ago and for my aggregated Mulitfaces, I typically have 5 milliseconds added (if I remember correctly) for DEC.

55

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

drvdd wrote:

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.

Regards
Matthias Carstens
RME

56 (edited by mlprod 2023-01-18 22:46:31)

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

So I made the plunge today with an HDSPe MADI FX & HDSPe AIO PRO in the same Sonnet chassis.
All seems to work but a few strange things happened:

- The HDSPe Setting app won't launch, it only appears if I reinstall the driver, then it shows at the end of the setup process, but after reboot it is "gone" again. Any ideas?

- Neither total mix or settings app launch automatically after reboot that they used to do.

- The aggregate device with both of them also works. But what should I do with the Drift settings in the Audio Midi Setup app? (right now both are off) Just asking what is the correct way to do this particular thing.

All this on a MBP M1 Max and Ventura 13.1.

Thanks/M

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

MC wrote:

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

58

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

Yes, that would be a perfect explanation. We already fixed the MIDI hang bug, so will take care of this too for the upcoming new version.

Regards
Matthias Carstens
RME

59

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

mlprod wrote:

So I made the plunge today with an HDSPe MADI FX & HDSPe AIO PRO in the same Sonnet chassis.
All seems to work but a few strange things happened:

- The HDSPe Setting app won't launch, it only appears if I reinstall the driver, then it shows at the end of the setup process, but after reboot it is "gone" again. Any ideas?

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

mlprod wrote:

- The aggregate device with both of them also works. But what should I do with the Drift settings in the Audio Midi Setup app?

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

Regards
Matthias Carstens
RME

60 (edited by mlprod 2023-01-19 10:06:05)

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

MC wrote:

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

Yes they are in sync with the included molex cable. Thanks.

MC wrote:

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

Doesn't work unfortunately. And also nothing happens when I start the settings app...
Any ideas?

Edit: Firmware of the HDSPe has been updated to 92 before hand. But is says current version 92, Legacy and new version 92, DriverKit. Maybe because I chose "allow downgrade" I dont know. But, is that a problem?

61 (edited by kol.ut.shan 2023-01-19 10:41:08)

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

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

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

Wow thanks a million kol.ut.shan! It worked!

But, now total mix wont show the AIO Pro for some reason...
The device is there and working but nothing in Totalmix.

What else to try?

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

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

64 (edited by mlprod 2023-01-19 14:10:50)

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

kol.ut.shan wrote:

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

Yes indeed I do, and it works in Reaper as well...

RME?

Edit 1: Another issue that drives me nuts is that I cannot figure out a way for channel numbers in core audio stay the same for x1 and x2 sample rates. No way to remove channels from Audio Midi Setup I guess?

Edit 2: Starting for example a YouTube video while playing fromt the DAW (having the MADI FX be the default MacOS output device out from a channel not used in DAW) interupts the audio stream from the DAW briefly. Might have to revert back to legacy driver unfortunately.

65

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

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

Regards
Matthias Carstens
RME

66 (edited by mlprod 2023-01-19 19:10:55)

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

After installing 1.06 it is now HDSPe MADI FX that is not showing up in Total Mix instead...=)

Edit: I went back to the kernel drivers now, everything works perfectly. No skipping channel numbers when changing from 96 to 48 etc, no dropouts when using system audio on the same device and of course both units in total mix.

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

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

68

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

mlprod wrote:

After installing 1.06 it is now HDSPe MADI FX that is not showing up in Total Mix instead...=)

Edit: I went back to the kernel drivers now, everything works perfectly. No skipping channel numbers when changing from 96 to 48 etc, no dropouts when using system audio on the same device and of course both units in total mix.

Thanks for the feedback. We will check these details.

Regards
Matthias Carstens
RME

69

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

drvdd wrote:

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.

Regards
Matthias Carstens
RME

70

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

mlprod wrote:

Edit: I went back to the kernel drivers now, everything works perfectly. No skipping channel numbers when changing from 96 to 48 etc

I am sorry to not have listed this change in the readme, but - the old way of working never made sense, the only reason it behaved like that was that it was not possible to reset all device properties in real-time. This is different now, so all cards now behave like they do under Windows ASIO, in the only logical and correct way - they show the exact number of available channels for every sample rate.

I also don't know what the advantage is to see dead and unusable channels in Double and Quad Speed. When Audio MIDI Setup shows 192 channels at 192 kHz that don't exist, then it is as confusing as useless. In our opinion the new DK driver is doing the correct thing. BTW, also performance wise, as these dead channels had to be handled by CoreAudio all the time.

Regards
Matthias Carstens
RME

71 (edited by mlprod 2023-01-20 13:35:40)

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

MC wrote:
mlprod wrote:

Edit: I went back to the kernel drivers now, everything works perfectly. No skipping channel numbers when changing from 96 to 48 etc

I am sorry to not have listed this change in the readme, but - the old way of working never made sense, the only reason it behaved like that was that it was not possible to reset all device properties in real-time. This is different now, so all cards now behave like they do under Windows ASIO, in the only logical and correct way - they show the exact number of available channels for every sample rate.

I also don't know what the advantage is to see dead and unusable channels in Double and Quad Speed. When Audio MIDI Setup shows 192 channels at 192 kHz that don't exist, then it is as confusing as useless. In our opinion the new DK driver is doing the correct thing. BTW, also performance wise, as these dead channels had to be handled by CoreAudio all the time.

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?

72

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

mlprod wrote:

After installing 1.06 it is now HDSPe MADI FX that is not showing up in Total Mix instead...=)

We were able to reproduce with the combination of MADI FX and AIO Pro only one card will show up in TM FX. Hopefully fixed in the next version.

Edit: see below, version 1.07 fixes this.

Regards
Matthias Carstens
RME

73 (edited by kol.ut.shan 2023-01-21 13:27:36)

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

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

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

Just wondering what experience others are having with MIDI on the new DK drivers? As per my previous post, after an hour or two of light use (master keyboard input to Multifaceted), my Mac system was grinding to a halt.

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

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.

76

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

The MIDI hang was solved 4 days (#65) before your above post (#74), so not sure why you mention this here.

Regards
Matthias Carstens
RME

77

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

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

Regards
Matthias Carstens
RME

78 (edited by Purusha 2023-01-27 11:13:29)

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

MC wrote:

The MIDI hang was solved 4 days (#65) before your above post (#74), so not sure why you mention this here.

I haven't had chance to re-test MIDI on the newer driver MC, I've been testing the audio.

I was asking what the experience of others might have been on the MIDI issue, before I get chance to re-configure my system and test myself.

I mentioned it here, because we're discussing the beta here - right?

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

MC wrote:

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.

80 (edited by Purusha 2023-01-27 11:19:15)

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

mlprod wrote:

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.

Can I double-check on your scenario? Are you saying that the card/unit order may change and therefore possibly swap the order of aggregated channels? ...or is it channels on a card/unit being re-ordered? ...or something else?

Also interested in your results re: dropouts on aggregated cards/units. Steinberg, for one DAW company, have been very insistent that they don't support nor recommend aggregation, but it is a standard mechanism in MacOS. It's the only way of getting my 3 multifaces to present the full set of IO to a DAW. Which MacOS version and hardware are you using?

81 (edited by mlprod 2023-01-27 12:17:34)

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

Purusha wrote:
mlprod wrote:

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.

Can I double-check on your scenario? Are you saying that the card/unit order may change and therefore possibly swap the order of aggregated channels? ...or is it channels on a card/unit being re-ordered? ...or something else?

Also interested in your results re: dropouts on aggregated cards/units. Steinberg, for one DAW company, have been very insistent that they don't support nor recommend aggregation, but it is a standard mechanism in MacOS. It's the only way of getting my 3 multifaces to present the full set of IO to a DAW. Which MacOS version and hardware are you using?

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.

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

mlprod wrote:

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.

Ah OK. I always separate system sound onto a dedicated interface. In my case, my monitor via Displayport.

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

Purusha wrote:
mlprod wrote:

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.

Ah OK. I always separate system sound onto a dedicated interface. In my case, my monitor via Displayport.

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.

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

mlprod wrote:

At least on all my macs.

Not seeing that issue here.

I've just been testing the MIDI input. So far, so good.

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

Purusha wrote:
mlprod wrote:

At least on all my macs.

Not seeing that issue here.

I've just been testing the MIDI input. So far, so good.

Only audio here.

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

mlprod wrote:

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!

Thoughts on this @MC ?

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

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.

88

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

The basic sample rate is always set by the application. The cards won't - and shouldn't - change clocks on their own.

Regards
Matthias Carstens
RME

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

MC wrote:

The basic sample rate is always set by the application. The cards won't - and shouldn't - change clocks on their own.

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

90

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

mlprod wrote:
MC wrote:

The basic sample rate is always set by the application. The cards won't - and shouldn't - change clocks on their own.

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

Not being able to slave means no synchronisation means click and pops. This relates to identical sample rates with complex setups like audio interfaces that would control / change the system audio settings as well as the DAWs and players - causing total havoc if they would follow any ramdomly found external sample rate. A different example is a stand-alone DAC, that one should and will follow all incoming SPDIF sample rates automatically. And doesn't screw anything else by doing so.

Regards
Matthias Carstens
RME

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

MC wrote:
mlprod wrote:
MC wrote:

The basic sample rate is always set by the application. The cards won't - and shouldn't - change clocks on their own.

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

Not being able to slave means no synchronisation means click and pops. This relates to identical sample rates with complex setups like audio interfaces that would control / change the system audio settings as well as the DAWs and players - causing total havoc if they would follow any ramdomly found external sample rate. A different example is a stand-alone DAC, that one should and will follow all incoming SPDIF sample rates automatically. And doesn't screw anything else by doing so.

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.

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

mlprod wrote:

[the 1.07 driver seems to work well, no problems whatsoever yet.

For what it's worth, it's working well for me. I now have Cubase back (after some considerable time!), which is a big plus point.

93

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

mlprod wrote:

Okay, I guess this just didn't fit my intended setup, I need total sync follows on all devices.

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.

Regards
Matthias Carstens
RME

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

MC wrote:
mlprod wrote:

Okay, I guess this just didn't fit my intended setup, I need total sync follows on all devices.

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.

I see!
As for 1.07 driver I just did a "dropout test" which basically means printing an analog loop while doing "stuff" at the same time to stress the system. This can be playing music from spotify and youtube, shuffling lots of data to/from the internet and even running things like geekbench and cinebench.
Not saying these are realistic things to do while printing, BUT the DK driver does dropout from time to time (not often but still) while the kernel driver was basically immune to any other processes in the Mac. My amateur guess would this has to do with kernel vs user space...but is there anything you can do to make this more stable in that regard?

95 (edited by Jperkins 2023-02-17 01:38:01)

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

mlprod wrote:
MC wrote:
mlprod wrote:

Okay, I guess this just didn't fit my intended setup, I need total sync follows on all devices.

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.

I see!
As for 1.07 driver I just did a "dropout test" which basically meas printing an analog loop while doing "stuff" at the same time to stress the system. This can be playing music from spotify and youtube, shuffling lots of data to/from the internet and even running things like geekbench and cinebench.
Not saying these are realistic things to do while printing, BUT the DK driver does dropout from time to time (not often but still) while the kernel driver was basically immune to any other processes in the Mac. My amateur guess would this has to do with kernel vs user space...but is there anything you can do to make this more stable in that regard?

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.

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

@Jperkins
Yes I went back to the kernel driver and now it is basically impossible to  provoke a dropout no matter what I do at the same time. Will stay kernel for now.

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

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.

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

...afaik on ventura it's still possible to install the old version...

99 (edited by Jperkins 2023-03-04 15:26:30)

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

Scheffkoch wrote:

...afaik on ventura it's still possible to install the old version...

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.

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

MIDI over MADI with HDSPe MADI card and MIDI Remote leads to beachball when trying to quitt MIDI Remote.
Also Audio-MIDI Setup hangs with beachball. Shutting down the computer only possible with long pressing power button.
With the old driver, everything is fine.

UFX+, FireFace 802 FS, Digiface USB
12 Mic, M1610 pro, Micstasy
MacBookPro M1
Logic Pro X