Audiocontrol Hyperion Processor

[welwynnick]

The clocking issue we were discussing with the VID 1X1 was only because it uses a software based Dante implementation. The Storm, Trinnov, Audiocontrol and Lyngdorf systems all use hardware based Dante/Ravenna boards. So they can be used as the Grandmaster or leaderclocks in the network. Where software based implementations must slave to leaderclocks that are located in other pieces of gear on the network.

No, that's the answer to a different question.
You're talking about what is the clock master in the network, and I'm talking about what is the clock master in the system. In the context of a Hyperion processor, which is an Atmos processor that can support a variety of AV sources and sinks and a Dante network, the system clock master is almost always the source (i.e. not the processor).

 

[Highfidelity]

Getting back to the topic of this thread, assuming the APR-16 does what the specs say, it should be an excellent one box solution that should help one avoid many of the complications from multi box and computer based solutions.

And it also has the same Dante electronics in it as well if one wants to upgrade later, or experiment and compare with PC based DSP and external DACs, active speakers with Dante input etc.

 

[welwynnick]

Getting back to the topic of this thread, assuming the APR-16 does what the specs say, it should be an excellent one box solution that should help one avoid many of the complications from multi box and computer based solutions.

Agreed, and my fingers are crossed, but I have a sneaky feeling that the specs may relate to the SPDIF or toslink input, rather than HDMI.

 

[Highfidelity]

No, that's the answer to a different question.
You're talking about what is the clock master in the network, and I'm talking about what is the clock master in the system. In the context of a Hyperion processor, which is an Atmos processor that can support a variety of AV sources and sinks and a Dante network, the system clock master is almost always the source (i.e. not the processor).

When the processor uses a hardware based board, the masterclock in the AVP becomes the clock source for all downstream audio over IP components on the network.

 

[welwynnick]

When the processor uses a hardware based board, the masterclock in the AVP becomes the clock source for all downstream audio over IP components on the network.

Exactly. But not the upstream ones.
Maybe one day we will have players connected to the network instead of HDMI, but not today.

 

[Highfidelity]

Agreed, and my fingers are crossed, but I have a sneaky feeling that the specs may relate to the SPDIF or toslink input, rather than HDMI.

Why would the input matter? All of the digital inputs will go into the DSP where all clocks are aligned, and the ASRC in the ES9039Q2M’s will eliminate all of the jitter present on the incoming I2S.

 

[Highfidelity]

Exactly. But not the upstream ones.
Maybe one day we will have players connected to the network instead of HDMI, but not today.

You seem to lack a clear understanding of how this technology works regardless of how clearly I explain it to you across multiple threads. You seem to think I don’t understand how this technology works when I helped develop the board used in both the Storm EVO and Steinway Lyngdorf MP-60. On top of that drop receipts that I understood Trinnov could never make software based audio over IP work years before they admitted it wouldn’t. I’m done trying to teach you. My posts are for people who can understand clear logic when presented to them.

 

[welwynnick]

Why would the input matter? All of the digital inputs will go into the DSP where all clocks are aligned, and the ASRC in the ES9039Q2M’s will eliminate all of the jitter present on the incoming I2S.

Why would the input matter? That's rhetorical. It does matter. You're assuming that jitter is the only problem. All the AVRs and AVPs tested here on ASR have returned relatively poor performance. The best are the MiniDSP Flex & SHD, and NAD M33. Looking at their tests, the results were obtained using spdif or toslink input. Every other device that was tested using an HDMI input has worse performance. I sincerely hope the APR-16 achieves it's specified performance from it's HDMI inputs, and live up to our hopes.

 

[welwynnick]

You seem to lack a clear understanding of how this technology works regardless of how clearly I explain it to you across multiple threads. You seem to think I don’t understand how this technology works when I helped develop the board used in both the Storm EVO and Steinway Lyngdorf MP-60. On top of that drop receipts that I understood Trinnov could never make software based audio over IP work years before they admitted it wouldn’t. I’m done trying to teach you. My posts are for people who can understand clear logic when presented to them.

You don't seem to realise that you might be the person who doesn't understand.

 

[Highfidelity]

Why would the input matter? That's rhetorical. It does matter. You're assuming that jitter is the only problem. All the AVRs and AVPs tested here on ASR have returned relatively poor performance. The best are the MiniDSP Flex & SHD, and NAD M33. Looking at their tests, the results were obtained using spdif or toslink. Every other device that was tested using an HDMI input has worse performance. I sincerely hope the APR-16 achieves it's specified performance from it's HDMI inputs, and live up to our hopes.

You’re basing this on the lack of understanding how the clocking works in modern properly designed AVP’s, and the ASRC in the ES9039Q2M. Build a few DACs based on the ES9039Q2M and pro and report back. Jitter before the dac chip is no longer an issue.

 

[Highfidelity]

You don't seem to realise that you might be the person who doesn't understand.

Better email Storm and Lyngdorf and tell them their AVP’s don’t work then. After that call Trinnov and Audiocontrol. They obviously need to be schooled.

 

[Highfidelity]

I’ll repeat once again on this thread how the TV video is in sync with the audio in an AVP. And this is the same case whether we are talking about an HDMI v1.0 based AVP from 2008, AVP-16, or DVP-16. The TV connects to the HDMI outputs of the AVP! Because of this the TV isn’t the source. The sources are the HDMI based devices connected to the HDMI inputs of the AVP. And inside the AVP, the ASRC aligns the clocks from all inputs to the clock of the HDMI output back to the TV, compensating for the latency introduced by the DSP. When hardware based audio over IP boards are introduced, the hardware based audio over IP boards get a feed from the exact same ASRC clock that is fed to the HDMI outputs. Therefore aligning all the clocks of the HDMI outs, and the “grandmaster”or “Leaderclock” in the audio over IP network. The end results are all audio over IP based devices on the network (DAC’s active speakers etc) are within nanosecond sync with the video output coming from the HDMI output port on the AVP.

Now let’s discuss how the clocking works if eARC is used from a connected TV, if the TV is used as a switching device for all source gear (Apple tv, blueray player, PS5 etc). This is important as the Hyperion line of AVP’s have this option as well:

The AVP (as eARC receiver) processes audio (e.g., Atmos decoding, room correction), introduces latency, and uses CMDC to inform the TV of the delay. The TV then adjusts its video timing to match. This isn't a literal "clock signal" sent back (eARC doesn't transmit video or clocks bidirectionally), but rather synchronization metadata derived from the AVP's internal clock. The embedded clock in DMAC ensures low-jitter audio delivery (<0.25 UI peak-to-peak). And it does this continuously in real time. So let’s say you enable Dirac ART on the fly with a movie playing. And let’s say the Dirac adds 100ms of additional latency. The metadata feed to the tv via eARC will instantly let the TV know this and it will instantly and seamlessly delay the video the additional 100ms to compensate.

Based on the maximum safe and stable amount of latency compensation via eARC on all the top brands of TV’s, the maximum compensation an AVP manufacturer would want to utilize is 100ms. Beyond that you can run into stability issues with some TV’s. 100ms latency means the maximum taps you can use in FIR based post-processing/room correction is 9600 @ 48kHz.

So if a manufacturer wanted to go beyond 9600 taps, yet maintain lip sync with the video, it’s essential to have the source connected to the AVP, then connect the TV to the HDMI out like all traditional AVP’s since 2006. When done this way any amount of latency can be compensated for.

For example the Trinnov Altitude is capable of having the room correction set all the way up to 32768 taps. If not compensated for this would add 341ms of latency. The Storm EVO with Dirac ART can be cranked up to 8192 taps. Adding 85ms of latency. Both of these settings would be beyond the tolerable threshold of human lip-sync tolerance (which is around 40ms) if the latency wasn’t compensated for internally with the internal HDMI switching/buffering.

For this reason a box like the DPR-16 connected via eARC will never be able to use any post-processing that exceeds 9600 taps. Where the Audiocontrol DPR-16 connected via its 4 HDMI input ports and HDMI out could theoretically compensate for far higher latency. Of course the internal DSP would need to have the power to run it as well. And it’s unknown at this time what they’re using for DSP inside.

Hopefully this clears things up. But if any industry gurus want to explain better please chime in.

 

[PGAMiami]

I’ll repeat once again on this thread how the TV video is in sync with the audio in an AVP. And this is the same case whether we are talking about an HDMI v1.0 based AVP from 2008, AVP-16, or DVP-16. The TV connects to the HDMI outputs of the AVP! Because of this the TV isn’t the source. The sources are the HDMI based devices connected to the HDMI inputs of the AVP. And inside the AVP, the ASRC aligns the clocks from all inputs to the clock of the HDMI output back to the TV, compensating for the latency introduced by the DSP. When hardware based audio over IP boards are introduced, the hardware based audio over IP boards get a feed from the exact same ASRC clock that is fed to the HDMI outputs. Therefore aligning all the clocks of the HDMI outs, and the “grandmaster”or “Leaderclock” in the audio over IP network. The end results are all audio over IP based devices on the network (DAC’s active speakers etc) are within nanosecond sync with the video output coming from the HDMI output port on the AVP.

Now let’s discuss how the clocking works if eARC is used from a connected TV, if the TV is used as a switching device for all source gear (Apple tv, blueray player, PS5 etc). This is important as the Hyperion line of AVP’s have this option as well:

The AVP (as eARC receiver) processes audio (e.g., Atmos decoding, room correction), introduces latency, and uses CMDC to inform the TV of the delay. The TV then adjusts its video timing to match. This isn't a literal "clock signal" sent back (eARC doesn't transmit video or clocks bidirectionally), but rather synchronization metadata derived from the AVP's internal clock. The embedded clock in DMAC ensures low-jitter audio delivery (<0.25 UI peak-to-peak). And it does this continuously in real time. So let’s say you enable Dirac ART on the fly with a movie playing. And let’s say the Dirac adds 100ms of additional latency. The metadata feed to the tv via eARC will instantly let the TV know this and it will instantly and seamlessly delay the video the additional 100ms to compensate.

Based on the maximum safe and stable amount of latency compensation via eARC on all the top brands of TV’s, the maximum compensation an AVP manufacturer would want to utilize is 100ms. Beyond that you can run into stability issues with some TV’s. 100ms latency means the maximum taps you can use in FIR based post-processing/room correction is 9600 @ 48kHz.

So if a manufacturer wanted to go beyond 9600 taps, yet maintain lip sync with the video, it’s essential to have the source connected to the AVP, then connect the TV to the HDMI out like all traditional AVP’s since 2006. When done this way any amount of latency can be compensated for.

For example the Trinnov Altitude is capable of having the room correction set all the way up to 32768 taps. If not compensated for this would add 341ms of latency. The Storm EVO with Dirac ART can be cranked up to 8192 taps. Adding 85ms of latency. Both of these settings would be beyond the tolerable threshold of human lip-sync tolerance (which is around 40ms) if the latency wasn’t compensated for internally with the internal HDMI switching/buffering.

For this reason a box like the DPR-16 connected via eARC will never be able to use any post-processing that exceeds 9600 taps. Where the Audiocontrol DPR-16 connected via its 4 HDMI input ports and HDMI out could theoretically compensate for far higher latency. Of course the internal DSP would need to have the power to run it as well. And it’s unknown at this time what they’re using for DSP inside.

Hopefully this clears things up. But if any industry gurus want to explain better please chime in.

This was extremely helpful. Thanks. Let’s hope the APR-16 makes full use of the x86 like processing power it claims to have,

 

[welwynnick]

You’re basing this on the lack of understanding how the clocking works in modern properly designed AVP’s, and the ASRC in the ES9039Q2M. Build a few DACs based on the ES9039Q2M and pro and report back. Jitter before the dac chip is no longer an issue.

Who said anything about jitter? All I said was that HDMI is worse than other inputs. I never mentioned anything about jitter.

In years gone by, I was quite as obsessed with jitter as you are with AOIP. I used to bang on about it incessantly.

https://www.avforums.com/threads/why-is-digital-audio-analogue.421910/

https://www.avforums.com/threads/there-is-no-such-thing-as-digital-audio.429835/

People kept insisting it was a solved problem, and I was convinced that it wasn't. Stereo equipment manufacturers lead the way in minimising jitter, but AV gear trailed behind. Some of it still does, but now I'm convinced that the best AV gear has solved the problem, and I said as much here.

The ability of the MP-40 (and presumably MP-60) to isolate itself from the digital audio nightmare that is AV and HDMI is better than all other equipment that I've ever seen. The end result isn't as good as the best stereo gear, but it's probably good enough to be a non-issue. In other words, "bits are bits" has come true, and it's not sensitive to the source.
Here's the MP-40 performance with three completely different input sources and connections: HDMI, USB and Roon streaming. In each case the noise is low, there's no power supply or digital video breakthrough, and the distortion is benign, correlated and tapering. More importantly, each test result is almost identical, showing that the architecture is robust and jitter has been minimised.

So yes, it's doesn't have to be jitter.

 

[Highfidelity]

Because it’s only jitter that causes the THD+N to degrade in poorly designed products when the HDMI port is used. Because those HDMI interface chips introduce high jitter. And when the jitter is high enough, the THD+N degrades. It’s not the data getting corrupted in the I2S that causes it. This is where properly engineered ASRC’s come into play. In properly designed gear the jitter the DAC chip sees is equal between all digital input choices. And on top of that when you use the ES9039Q2M in ASYNC mode it eliminates 100% of all incoming jitter. Even when you feed it the dirtiest I2S lines imaginable the performance from the analog outputs is flawless.

 

[Highfidelity]

Since I have a close relationship with the head engineer over at ESS, I was the first person to get my hands on the ES9039Q2M eval boards other than ESS for their own internal testing. Original test setup.

 

[PGAMiami]

This was extremely helpful. Thanks. Let’s hope the APR-16 makes full use of the x86 like processing power it claims to have,

Would you expect the APR-16 would use longer latency filters when the HDMI source is connected directly to it as opposed to via eARC?

Audiolense 60k tap filters with 1-2 hz resolution sound quite good and fix many bass problems even with no absorption. Question would be whether Dirac ART can control the bass with less taps when rear wall absorption is present.

 

[Highfidelity]

It likely uses the same filters either way because even at the top settings the latency is probably under the 100ms latency max for eARC compensation. Heavier FIR takes lots of DSP power. And at the price point of the APR-16, I wouldn’t expect more GFLOPS of DSP power available than a processor like the $24000 Storm Evo.

 

[PGAMiami]

It likely uses the same filters either way because even at the top settings the latency is probably under the 100ms latency max for eARC compensation. Heavier FIR takes lots of DSP power. And at the price point of the APR-16, I wouldn’t expect more GFLOPS of DSP power available than a processor like the $24000 Storm Evo.

They claim x86 processing power in their ARM chips. Isn’t that enough? That’s all my Roon system has and it has no problem running big convolution filters.

But back to the other question, with ARTs MIMO technology that uses absorption, do you need single hz resolution?

 

[Highfidelity]

They claim x86 processing power in their ARM chips. Isn’t that enough? That’s all my Roon system has and it has no problem running big convolution filters.

But back to the other question, with ARTs MIMO technology that uses absorption, do you need single hz resolution?

Where did you read about those details? It’s possible the ARM chips are used for other things than DSP. The Trinnov CI also uses ARM chips and FPGA’s, but they’re used for other functions other than the DSP.

Regarding the ART algorithms I’ve never looked into the fine details of the algorithm. I prefer to manually tune rooms with my own DSP. And since I use 4th order active crossovers which put all the drivers back in phase, there’s very little to correct in my setups. Dirac is mainly a bandaid to correct flaws introduced by passive crossovers. I haven’t found any room correction to date that doesn’t degrade the sound more than improve it in my systems. The Trinnov on the other hand is an excellent measurement tool to quickly verify if time, phase, and frequency response is optimized in the system. So I plan to buy a CI just to use as a measurement tool. And manually fine tune in my own DSP until I’m able to achieve the Trinnov target curve without running the audio through the Trinnov correction.