Altitude 32 is not accepting 96kHz audio from Nucleus+

I’m trying to figure out why my Altitude 32 is not accepting a 96kHz signal from the Nucleus+. I’ve iterated through various settings, but the Nucleus+ does not want to send anything above 48kHz.

Under the DSP menu, It doesn’t show the option of sending 96kHz either.

Here are my device setup settings:

In your device settings I do not see the max sample rate setting?
Not sure why but have no knowledge of the Altitude32 tbh
However if Roon is downsampling everything to 48 it will be because that is the max sample rate it has identified the unit can handle, wrongly or rightly I think.
This is what I would expect to see…

Hi @Steve_Bjorg,

The fact that you do not see the “Max sample rate (PCM)” setting in Device Setup tells me that the device is reporting to Roon that it has a maximum sample rate of 48kHz.

I recommend reaching out to Trinnov support, they should be able to get this figured out.


Thanks, I already reached out to Trinnov to setup a call.

Do you know how quickly the Nucleus+ will see the change? Do I need to remove the device and add it back? Do I need to reboot the Nucleus+?

If I’m using the Roon device settings to diagnose the issue, then I just want to make sure I don’t do a silly user error where the Nucleus+ uses cached/stale device information after the original issue in the Trinnov has been addressed.


I noticed that as well. So the absence of “Max sample rate (PCM)” implies a limit of 48kHz?

Hi @Steve_Bjorg,

When an enabled Roon Ready device is discovered by the core it automatically sends a list of its “supported formats” to the Roon Core. All that should be required to get the format support updated is a reboot of the Trinnov.



Thanks for the answer. Just to confirm I got it right: by virtue of rebooting the Trinnov, it will re-announce itself on the network, and at that point its current capabilities will be picked up by the Nucleus+.

In short, I need to reboot the Trinnov every time I change a setting to see if it works, correct?

Hi @Steve_Bjorg,

Close, but not exactly.

When a device is discovered it communicates its vendor and model information, its supported formats list, what type of volume control it has, and support for convenience switching / transport controls / metadata.

These are things that rarely change, if ever. If they do change, there exists a mechanism for a device to “restart” it’s RAAT component to pick up the new changes.

The reason why I suggested that a reboot may be necessary resolve this issue is that the Trinnov is likely in a bugged or invalid state for this issue to have occurred out-of-the-blue.

For things like Trinnov DSP settings (optimizer, crossovers, EQ, etc), these are communicated back to the Core in real time during playback.