Elytone VID 1X1. Mini immersive surround processor with Dante output.

[Highfidelity]

The same thing is required even if the audio inside the AVP is sent to internal Dacs, or AES/EBU outs. Because the audio needs to be in sync with the video. Then there’s also the issue of high jitter from the HDMI chips. ASRC can both sync the A/V and clean up jitter.

 

[welwynnick]

The same thing is required even if the audio inside the AVP is sent to internal Dacs, or AES/EBU outs. Because the audio needs to be in sync with the video. Then there’s also the issue of high jitter from the HDMI chips. ASRC can both sync the A/V and clean up jitter.

The AVP doesn't know whether the audio and video are in sync, that's the job of the source, whether it's a player, streamer or receiver. The AVP can compensate for it's own internal video processing delays, but it can't correlate the separate streams. The user can apply a manual time delay to the audio if they perceive that the video is lagging (but not leading).

It’s also possible to send HDMI over fiber optics from several TV eARC ports to a single AVP. And remote switch them to remap the output to the AVP. So a single AVP can handle multiple rooms.

Are you sure about that? I looked at a lot of AVRs and AVPs, and they all had one eARC HDMI port, which is an output (and eARC input).

Using AES3 for a setup like this would be a nightmare.

Agreed

The way eARC works is the clock from the AVP is sent back to the TV to clock sync the TV to the AVP.
The reason most AVP’s have multiple HDMI inputs is so when you run the hdmi sources through them and then connect the TV to the AVP hdmi out it syncs the video to the audio.
This is how all AVP’s work to sync the audio and video regardless if they have analog outs, AES or Dante.

Are you sure about that? With eARC, the TV is the source, so the TV is the master clock, and the AVP has to synchronise to that.
I never paid any attention to eARC until Amir tested the Fosi ZD3, Luxsin X9 and Bluesound Node Icon, which are high quality DACs with HDMI eARC connections. They all measured the same with eARC input as with spdif, USB and ethernet inputs, which was a first. Up until then, every device he tested with HDMI input had poor performance compared to stereo DACs, with no exceptions. eARC isn't very well documented (I can't download HDMI specs any more) but I take it to work like AES3 / IEC-60958 but with multiple audio channels multiplexed onto a single physical channel, and presumably with the audio clock embedded into the audio data (if this is wrong please provide evidence ). The point is that eARC is an audio input, and both the audio data and audio clock are necessarily being sent from the TV to the AVP, not the other way round. With "normal" HDMI implementations, yes, both the video and the audio are being sent forwards, obeying the usual clocking hierarchy that I've talking about all along without much clarity. As it happens the audio clock is derived from the video clock on HDMI, which has crippled the sound quality of AVRs and AVPs for many years, and was the original reason for my wanting an Atmos processor with digital audio outputs - just to get away from HDMI. Though I think there are actually five reasons. I'm pursuing four of them, and you're pursuing the fifth one, and that's fine.

 

[welwynnick]

Boy, this is right in my domain.
This is at the core of what creates interesting issues with HDMI -> AoIP.
Unless you are in production, a HDMI source is a free running clock intermittent. And AoIP needs a stable clock.
Taking the HDMI timing and pushing that out to AoIP would not be wise - or very stable downstream.
So generally, all cases of HDMI -> Dante/AES67 will be going through some form of ASRC.

Many thanks gdickins.
Do you happen to know if the same applies to the Arvus H24D when using the AES/EBU outputs?

 

[MCH]

The AVP doesn't know whether the audio and video are in sync, that's the job of the source, whether it's a player, streamer or receiver. The AVP can compensate for it's own internal video processing delays, but it can't correlate the separate streams. The user can apply a manual time delay to the audio if they perceive that the video is lagging (but not leading).

Are you sure about that? I looked at a lot of AVRs and AVPs, and they all had one eARC HDMI port, which is an output (and eARC input).

Agreed

Are you sure about that? With eARC, the TV is the source, so the TV is the master clock, and the AVP has to synchronise to that.
I never paid any attention to eARC until Amir tested the Fosi ZD3, Luxsin X9 and Bluesound Node Icon, which are high quality DACs with HDMI eARC connections. They all measured the same with eARC input as with spdif, USB and ethernet inputs, which was a first. Up until then, every device he tested with HDMI input had poor performance compared to stereo DACs, with no exceptions. eARC isn't very well documented (I can't download HDMI specs any more) but I take it to work like AES3 / IEC-60958 but with multiple audio channels multiplexed onto a single physical channel, and presumably with the audio clock embedded into the audio data (if this is wrong please provide evidence ). The point is that eARC is an audio input, and both the audio data and audio clock are necessarily being sent from the TV to the AVP, not the other way round. With "normal" HDMI implementations, yes, both the video and the audio are being sent forwards, obeying the usual clocking hierarchy that I've talking about all along without much clarity. As it happens the audio clock is derived from the video clock on HDMI, which has crippled the sound quality of AVRs and AVPs for many years, and was the original reason for my wanting an Atmos processor with digital audio outputs - just to get away from HDMI. Though I think there are actually five reasons. I'm pursuing four of them, and you're pursuing the fifth one, and that's fine.

I believe you are confusing eARC with ARC. Of those 3 devices, only the Node Icon has eARC input, but even then, Amir only measured the ARC input.
Note that ARC and eARC are very different hardware wise, and it is normal that ARC measures the same than SPDIF because it is basically a SPDIF signal sent over HDMI.

edit: I am not aware of amir having ever measured an eARC input, but I might be wrong. I think there was a discussion about his setup being capable or not of doing it. Not that I would expect it to measure different from SPDIF, but just to clarify

 

[welwynnick]

... and it is normal that ARC measures the same than SPDIF because it is basically a SPDIF signal sent over HDMI.

And so is eARC, which runs on two wires (14 & 19) and ground, instead of one (19). But it runs at a much higher rate.

You're right about the DACs being ARC. It was such a shock that anything using HDMI could work so well.

Do you know of any other HDMI ARC tests other than those three done by Amir?

 

[MCH]

And so is eARC, which runs on two wires (14 & 19) and ground, instead of one (19). But it runs at a much higher rate.

You're right about the DACs being ARC. It was such a shock that anything using HDMI could work so well.

Do you know of any other HDMI ARC tests other than those three done by Amir?

I am sure there must be some here in the forum but I can't remember now...
You can also check minidsp website, they have devices with ARC and eARC inputs and they post measurements, there is also a forum, maybe someone measured and posted something.

 

[Highfidelity]

The AVP doesn't know whether the audio and video are in sync, that's the job of the source, whether it's a player, streamer or receiver. The AVP can compensate for it's own internal video processing delays, but it can't correlate the separate streams. The user can apply a manual time delay to the audio if they perceive that the video is lagging (but not leading).

Are you sure about that? I looked at a lot of AVRs and AVPs, and they all had one eARC HDMI port, which is an output (and eARC input).

Agreed

Are you sure about that? With eARC, the TV is the source, so the TV is the master clock, and the AVP has to synchronise to that.
I never paid any attention to eARC until Amir tested the Fosi ZD3, Luxsin X9 and Bluesound Node Icon, which are high quality DACs with HDMI eARC connections. They all measured the same with eARC input as with spdif, USB and ethernet inputs, which was a first. Up until then, every device he tested with HDMI input had poor performance compared to stereo DACs, with no exceptions. eARC isn't very well documented (I can't download HDMI specs any more) but I take it to work like AES3 / IEC-60958 but with multiple audio channels multiplexed onto a single physical channel, and presumably with the audio clock embedded into the audio data (if this is wrong please provide evidence ). The point is that eARC is an audio input, and both the audio data and audio clock are necessarily being sent from the TV to the AVP, not the other way round. With "normal" HDMI implementations, yes, both the video and the audio are being sent forwards, obeying the usual clocking hierarchy that I've talking about all along without much clarity. As it happens the audio clock is derived from the video clock on HDMI, which has crippled the sound quality of AVRs and AVPs for many years, and was the original reason for my wanting an Atmos processor with digital audio outputs - just to get away from HDMI. Though I think there are actually five reasons. I'm pursuing four of them, and you're pursuing the fifth one, and that's fine.

eARC is bidirectional. Atmos processing along with post-processing in the AVP introduces latency. When eARC is used, a clock in sync with the AVP after post-processing is sent back to the TV via eARC to sync the timing of the audio from the AVP to the TV video.

In traditional AVP’s with multiple HDMI and HDMI switching, they always have an HDMI output. And you connect this output to the TV. In this case the AVP syncs the audio and video and sends the in sync video to the TV.

If we look at the Audiocontrol DPR-16 for example, it has 4 HDMI inputs plus an eARC port. So it allows the option of doing things traditionally by connecting the sources to the AVP and then going out to the TV via the HDMI output. Using this method the clock sync is handled in the AVP. But it also has eARC. In this case all sources can be connected to the TV and clock sync is handled by the AVP clock being sent to the TV via eARC.

In order for a single processor to handle multiple zones you would need an external HDMI switch. And run the eARC port from multiple TV’s to the eARC port on the AVP. When you want to switch zones, switch the ports on the switch. And turn the speakers (that are already mapped properly in Dante controller) on in the other rooms.

Try doing this with analog or AES3 outs and see how it works out.

 

[Highfidelity]

It’s my strong belief that 16 channel Atmos is enough unless you plan on spending well in excess of $1000000 on the theatre. Because most theatre projects have a budget ceiling. Let’s say that budget is $500000. What do you think would yield a better end result? Spending double on the amps/speakers and 5x on the processor for 32 channels. Or spending over double on the amps/speakers and using a 16 channel processor and 16 speakers? I’ll always recommend higher quality components and less channels.

In the past before AES67 output AVP’s this was always an issue. Because going with only 16 channels meant the sound quality would be compromised because the Dacs were worse quality in the AVP’s. This no longer matters with AES67. If using active speakers the only limiting factors are the Dacs/amps in the active speakers. Not the AVP.

The only caveat is if the AVP messes things up in the digital domain with mediocre SRC. I suppose once the Hyperion line is available as well as fully functional VID 1X1 based units, I’ll be able to compare.

 

[Highfidelity]

I suppose I over-simplified the explanation of how the eARC syncs the TV with the AVP clock after post-processing latency is added. Here’s precisely how it works:

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.

 

[Highfidelity]

For anyone interested, I conducted some research and came up with some fun facts on the limitations of only having eARC as the HDMI interface on AVP’s.

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 VID 1X1 will never be able to use any post-processing that exceeds 9600 taps. As the only HDMI source is eARC based. Where the Audiocontrol DPR-16 with 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.

Edit: corrected some typos

 

[Highfidelity]

Regarding Atmos processing latency alone it’s only 8-12ms. So for the geeks here’s a graph representing Atmos+FIR post-processing latency at different taps:

 

[apgood]

Looks like Storm Audio adopted the exact same Elytone NAP1 DSP module used on the VID-1X1, for use in their 35 channel ISP 32 Elite processor.

Networked Audio Processor (NAP1)｜Networked Audio Processing｜Audio Solutions｜Elytone

NAP1 is a breakthrough in miniaturization and audio performance: a comprehensive audio system driven by a powerful multi-core application processor with on board memory, and power circuitry - all in a module about the size of a business card. NAP1 is designed to integrate networking, processing...

www.elytone.com

So when a solid implementation based on the VID-1X1 hits the market, it will share the same DSP as the highest end SHARC based 35 channel Atmos processor on the market.

Evidence below:View attachment 473871View attachment 473872View attachment 473874View attachment 473873

Yes StormAudio's ADEC appears to use NAP1

 

[welwynnick]

Can you explain what we're looking at there?

 

[Highfidelity]

Looks a lot like this board to me

It was already a dead giveaway as it clearly says NAP1 adapter on the bottom left

Dead accurate call by Audiovibes, but nobody would believe him. Example:

Possible solution for DTS/Dolby/Atmos+eARC+HDCP to AES/EBU - via Dante? (for Okto DAC8PRO etc)

New news as of last week. Targeting Q4 https://www.ecoustics.com/products/audiocontrol-hyperion/ SInce there will be plenty of glitches when released anyway, I'd wait at least another 6 months after release before buying anything like that.

www.audiosciencereview.com

 

[Highfidelity]

Looks like Audiovibes was right about everything he said in this forum. But was met with hostility from those who thrive on inaccurate information and scoff at accurate information. I’m not surprised he stopped posting.

 

[apgood]

Can you explain what we're looking at there?

It is numbering that you can see on the StormAudio ADEC board if you look under the heat sink from an angle.

Along with a few numbers you can see NAP1 R02 which suggests it is using NAP1 board