RME HDSPe AES Does Not Auto-Follow Incoming AES Sample Rate?

Your DAW software should have a setting like that. In JRiver for the audio output device it lets you select between ASIO, Direct Sound or WASAPI output. The audio device's driver must support ASIO for it to show up as an output option though.

Before the Trinnov Altitude CI my signal path was:
JRiver Media Center (WASAPI, HDMI out) -> RME HDSPe AES32 (ASIO AES out) -> Xilica XD4080 DSP processors -> Benchmark AHB2 amplifiers -> Speakers

Now after adding the Trinnov it has now been extended to:
JRiver Media Center (WASAPI, HDMI out) -> Trinnov AltitudeCI-10 (HDMI in, decodes or passes PCM, 10 channel AES out) -> RME HDSPe AES32 (AES in, clocked to incoming signal, ASIO to AES outputs) -> Xilica XD4080 DSP processors -> Benchmark AHB2 amplifiers -> Speakers

The Trinnov Altitude CI is more than capable of outputting AES (regardless of the digital input being used to receive the original signal). https://www.trinnov.com/en/products/altitudeci/

It outputs AES as it is in a pro-audio home theater application. HDMI is needed to connect the PC and the Trinnov as the Trinnov performs immersive format decoding duties (something that cannot be bitstreamed over AES or Dante).

In my use case, the Trinnov Altitude CI is the AES master, and it sends its AES outputs directly into the RME HDSPe AES card.

The AES inputs in TotalMix are then sent out the AES outputs of the HDSPe AES card to the individual speaker processors (Xilica XD4080) which take AES in, do time alignment and filtering, then output an analog signal to amplifiers.

HDMI irritates us all , but it is a necessity here. The fact remains that when I play a 44.1k or 48k file, HammerFall sets the displayed sample rate correctly to match that of the AES Input that indeed syncs just fine with. However, once anything above 48kHz is played, HammerFall has to have it's Sample Rate manually set to match.

This was done via an AHK script, but I'm not sure why the HammerFall driver works this way. If it sets Sample Rate to match the sync from AES 1 for example, why not do it for 88.2kHz or 96kHz?

https://drive.google.com/file/d/1poZaNn … drive_link

https://drive.google.com/file/d/1TqBQQW … drive_link

Cabling is NOT the issue at all as I can manually set the sample rate each time (if above 44.1kHz or 48kHz), and everything is played back perfectly. The issue is clearly the way HammerFall DSP behaves. It refuses to set the Sampling Rate for a signal it has a valid Sync for on AES 1 In as show in the screen shots above.

I'm an electrical engineer, so I understand the question your cabling concern though, so happy to answer you as the wrong impedance cabling could potentially cause reflections... I am using 110 ohm 4 foot Avid Digisnakes to connect the AES out from the Trinnov to the AES in from the RME HDSPe AES card.

Everything is running its latest firmware and the latest drivers are being used:

Firmware and driver versions and additional HammerFall settings:

https://drive.google.com/file/d/1Y5N2_R … drive_link
https://drive.google.com/file/d/10RWBuZ … drive_link

Trinnov Altitude CI version:

https://drive.google.com/file/d/1hf-cAE … drive_link

TotalMix version:

https://drive.google.com/file/d/1lpAAt0 … drive_link

MC was a bit faster... The point is indeed the change across samples rate ranges, i.e. 48 to 96. 44 to 48 works, as you have observed already.

> ... Since only TotalMix touches the data ...

Just FYI, TM FX is not in the signal path, it only "controls" the recording interface.

Thanks for the responses, and good to hear a Follow Clock across all sample rates is being considered. That would solve this completely. I know I can manually change the Sample Rate setting, but when you have a playlist mixed with 176.4kHz, 88.2kHz, 44.1kHz, 48kHz, 96kHz and 192kHz, who wants to change settings in HammerFall or other software after every song?

In the meantime I'm considering writing a small background ASIO host whose only job is to follow the incoming AES rate and set the card's sample rate to match, so I don't have to set it manually or rely on my current workaround (an AutoHotkey script that sets the rate based on what's playing in JRiver via HammerFall's clock source settings dialog ComboBox).

The use case again: the Trinnov is the AES master and sends a variable rate to the HDSPe AES depending on what's playing. The card is clock slave on AES 1 In and just passes audio through to my speaker processors. There's no DAW or project in the path, so nothing is telling the card what rate to run at, which is why it sits at the wrong rate after a range crossing.

Before I write it, I want to confirm the ASIO API can actually see what I need. In another thread it was noted that when the input crosses from 48 to 96, ASIOGetSampleRate still reported 48 while the control panel correctly showed 96 as the input status. That suggests the configured rate and the detected input rate are different values, and only the latter is what I'd need to follow.

So my questions:

With Clock Source set to AES 1 In, does ASIOGetSampleRate return the configured card rate or the actual detected incoming rate?

Does the RME ASIO driver fire the sampleRateDidChange callback when the AES input crosses a sample rate range (for example 48 to 96), and does it deliver the true detected rate in that callback?

Is the true detected input rate (the value shown as the AES 1 In sync frequency in the Settings dialog) exposed anywhere through the ASIO API, or only in the Settings dialog itself?

If the detected rate isn't available through ASIO, then a host application can't follow it...

Thanks again for the help.

Thanks so much. I will keep my AHK script that changes the sample rate based on what's playing in JRiver, but it's kind of a kludge... what if I use different software to play something back, etc...

Sadly I don't receive emails from the RME forum (using gmail.com), but if you need a beta tester, please reach out. I'd be happy to test a beta version and report the results.

Sorry for the delay. Do to the gmail forum issue, I just saw this an hour ago after manually checking the forum.

This works great and does exactly what I needed. Even one off drivers are rock solid when they come from RME

Seriously, this is just insane turnaround and engagement by a very talented engineer who co-founded one of my favorite audio companies. Just so you know, I am extremely picky, but have to say I consider your products to be world class.

There's probably not too many six figure home theaters running RME gear, but there really should be. I've used that HDSPe AES card since 2018 in my theater, and I really wouldn't change anything if it wasn't for all the Atmos and DTS-X media I have, and the desire to finally decode it.