What is the recommended connection of Roon to a Trinnov Altitude16 that is Roon Ready? HDMI, Network or both? I plan to play multi-channel Hi-Res music files using the Trinnov.
Thanks.
Hi Bruce,
Please use the Roon Ready āconnectionā which is part of your ethernet LAN. It has the best audio performance (by quite a lot) and also makes full use of the Roon Ready integration features.
Simply Enable the Altitude16 in your Roon software as an Audio Zone. The rest just works.
If you want to use the Roon HDMI video interface, select that HDMI connection and then select the Roon Ready connection (either from the Altitude or from Roon). The video will remain on the last-selected video connection, while the audio will move on to the Roon input (which utilizes our excellent clocks rather than being limited by the quality of the clock on the incoming HDMI connection).
Best,
1 Like
Thanks very much!
Hi ,
Iām having a torrid time trying to get my Altitude 32 (8/16) set up as 7.1 system currently to play fair with my Meridian speakers via their 271 Controller and connected via DB25 and also Roon connected to Audio Network (Pri) input . Basically , if I select a playlist with different formats 2.0 5.1 etc and different clock rates 16/44.1 24/96 the almighty thump of reconnection / relock between each track is very scary . I followed the guide to setting up a Roon Ready Trinnov processor and my settings are identical to no avail. Iāve replaced the DB25 cable to no effect and my dealer is lending me a replacement 271 to make sure thatās not the cause .
Is there something simple Ive missed in setup ? Changing formats on UHD discs can also cause it but it is way more frequent with Roon.
Any ideas ?
Thx
~M~
Hi Moonloop,
The digital audio data presented at our multichannel digital output is precisely the same data we send to our own DACs inside the Altitude. I do not have any first-hand experience using a 271, so I cannot help you there. But I have contacted the rest of my team to find out what they know.
I will get back to you with anything I can learn.
Best,
Jon
1 Like
Many thanks Jon , if I discover another cause I will report back . My dealer and Trinnov CS remoted in but couldnāt trace a source to the problem. I noticed that Trinnov and Meridian had a presentation recently using a similarly set up system and would love to know any recommendations arising out of it .
I would love to get sorted before Christmas.
Best
M
P.S. Really enjoyed the webinar, thx again
Hi Moonloop,
Thank you for attending the seminar! I was stuck in a hotel room at the time, with limited bandwidth. I hope the quality on your end was okay.
I received word back from one of our tech support leads. He tells me that he has been involved in troubleshooting a few systems like yours. He said that the problems varied: sometimes an amp, sometimes the speakerās built-in amp(s), once it was even a bad cable. Iām afraid this doesnāt help much.
I suggest starting with swapping out the cables since thatās probably the easiest and cheapest to investigate. Perhaps your dealer has some cables he can loan you?
Best,
Jon
1 Like
Thanks again , Jon ,
My dealer replaced the DB25 but no difference and we swopped out front and side speakers and their cables also to no avail . At this point Iām even wondering if it could be electrical as the 32 arrived only with a French plug !!!
I will swop out the 271 tomorrow and see if it helps and if it does then itās back to reading the manual for study purposes 
Have a nice weekend!
M
Hi Moonloop,
If I may, what country are you located in?
I assume you have 230v AC or it would not have started up.
Jon
Im in Ireland (UK plug) Jon and I used the power cable off my old Meridian 861 Controller so , hopefully , no problems there
~M~
Another reason to possibly select the HDMI input is to be able to use sample rates greater than 96kHz.
Wondering if anyone (maybe @Jon_Herron ?) could provide insight as to why the Altitude limits sample rates to 96kHz or less?
Hi John,
Thanks for the @mention, or I likely would have missed this question. I appreciate the help!
First of all, an explanation of how the Altitude works differently than other processors. Everyone using traditional DSP chips from the usual suppliers must run that chip at a set, specific rate (usually 48 kHz or 96kHz). Everything that comes is subjected to Sample Rate Conversion (SRC) to accommodate this requirement. Thus, whether you are listening to 16/44.1 Redbook CD or 24/384, or DSD for that matter, if there is any digital signal processing at all, the incoming signal is converted to either 48k or 96k so the chip can do its thing.
Our platform is different.
Rather than operating on a facsimile of the original signal, wherever possible we do our processing on the original data, at the original data rate. If that is impossible, we only use factor-of-two conversion (which we find is more transparent than fractional SRC).
Thus, we do our digital signal processing at various rates, depending on the nature of the incoming signal. It would be MUCH simpler for us to use SRC and do everything at a single rateā¦ it just doesnāt sound quite as good.
The Altitude32 creates all of its filters for use at 44.1, 48, 88.2, 96, 176.4 and 192 kHz.
The Altitude16 creates all of its filters to run at 44.1, 48, 88.2 and 96 kHz. The gating factor is the available CPU load. The AL32 has a bigger Intel CPU.
In both cases, when presented with something beyond what is listed, we do a factor-of-two decimation (which is quite transparent) and work with that. For example, 176.4k coming into an AL16 would be decimated to 88.2k and then processed at that rate rather than using fractional decimation at 96k.
After this more-transparent signal processing work is done, everything is once again upsampled in our DACs prior to conversion to analog.
So, the short answer (something I am not especially good at): the 96k limitation on the Altitude16 is less of a limitation than any other DSP platform out there except for the AL32, and is driven by the requisite CPU load on top of everything else we are doing.
Does that help?
1 Like
Jon,
Thanks for taking the time to respond. Iām very new to the Altitude so thanks for your help.
My first thought was that prior to the Altitude I was using a NUC running an Intel I3 as my Roon endpoint and it barely broke a sweat handling any Roon data I could throw at it. So I was interested in what the limitation for the Altitude might be.
From your response, do I infer that the Altitude performs its filtering (FIR, IIR) in the Intel CPU? From the photos of the Altitude internals I can see some DSP chips but I couldnāt see their markings so I wasnāt sure what functions they might be performing.
Iāve looked at the Altitudeās CPU load indicator and using the full optimizer on DSD 5.1 and using Auro-3D Iāve never seen the CPU load get much above 20-30%. Is the Altitude 32 able to accept Roon audio streams at 192 kHz?
Thanks for your time and insight, Happy New Year!
John
Hi John,
Yes, we do all of our digital signal processing on the multicore Intel CPU with 64-bit floating point precision. Itās all our software, so we do not have to live with design choices/limitations made by others. And, yes, we use both IIR and FIR filters.
I am not sure what āDSP chipsā you are alluding toā¦ perhaps some FPGA or other devices? All of the boards in the box are of our own design and manufacture except the military-grade PC and the HDMI board, which we purchase from outside vendors.
We try to be somewhat conservative regarding CPU load since there are so many variables that can contribute to it. As an example, some of the upmixers use a LOT of CPU, especially with higher channel counts than you describe. Not to mention everything that the Optimizer does in real time.
Yes, the Altitude can accept PCM input of 24/192 and will perform all of its operations on the original 24/192 data without SRC.
Jon
Jon,
Thanks for the insight on how the Altitude processing works. Like I said, I have had my A-16 for just two weeks and Iām trying to come up the learning curve.
Regarding the āchipsā, I was just looking at some of the interior photos on the net; I will not expose my ignorance further on this.
I would like to respectfully pull on your last comment. If the Altitude can process PCM inputs at 192 kHz and I assume that would be from either the HDMI or S/PDIF inputs, why would the Roon endpoint processing be limited to 96 kHz?
Thanks again for your insights.
John
Hi John,
Sorry, I was not clear.
One of the differences between the AL16 and the AL32 is that the latter can process signals natively up to 24/192; the former processes signals natively up to 24/96. The input source should not matter in this respect.
However, most people find that the ethernet āRoon Readyā input sounds better than SPDIF or HDMI, presumably because we are allowed to use our excellent internal clocks when using the network connection (rather than being slaved to an external clock that is subject to more jitter). The networked Roon Ready connection also provides excellent integration into the Roon ecosystem. It is the only way I listen to music now.
Regards,
Jon
Thank you Jon,
That clears up a misunderstanding that I had. I was told that the Alt-16 and Alt-32 had identical processing and that they only differed in the number of channels supported. Your explanation makes things clearer.
Thanks and Best Regards,
John
Hi again @Jon_Herron ,
Happy New Year / Decade 
Would it be possible for me to get in touch with the tech who has experience of a system like mine (T32/Meridian 271) ? Iāve got āpopsā again on Roon going from 24/96 to 24/44 pcm playback and also mystery , momentary audio dropouts during movie playback ( Computing appears on display even on my 7.1 system ) similar to the old ālayer-changeā stutter of dvd playback in days gone by ā¦
Cheers
~M~
Hi Moonloop,
I suggest contacting us via support@trinnov.com so we can work more closely with you.
Jon
Thanks Jon , Will do , best of luck at CES !
~M~