Originally Posted by DreamWarrior
Just saw this -- how is additional bandwidth available on ARC? As we've both said, it seems that, in its current implementation, the ARC end-points are implemented as S/P-DIF ports. So, wouldn't its bandwidth, currently, be limited to S/P-DIF's DL and PHY layer specification?
Did you mean that because negotiation exists, there may be more bandwidth available to ARC in a future revision of HDMI? Said revision would need to negotiate the use of a different protocol, possibly over the same two ARC pins in the HDMI cable (or maybe over the HEC pins), before that bandwidth could be made available, though, no?
Sorry, I'm not trying to nitpick, but at the end of the day, I think it's best to keep it succinctly said that ARC = S/P-DIF; if you can't send it over S/P-DIF then you can't send it over ARC (in its current incarnation) -- end of story.
Well, there is a difference between a short trace on a PCB (from the SoC to the ARC transmitter), and a 6 foot RCA cable. Also, the TV SoC could even use the more robust I2S interface to send the audio to the ARC transmitter.
And, yes, I was referring to the negotiation as well. ARC can negotiate a 192 kHz connection, if both sides know they can support it. SPDIF, as optical or RCA, can just hope and pray that the currently transmitted audio is actually receivable at the other end. Especially RCA cables can not normally carry 192 kHz audio, even 96 kHz is sometimes a stretch, at a bit rate of 64 times the sample rate. Therefore you'll rarely find more than 48 kHz audio as an option for SPDIF outputs.
ARC could theoretically support an audio rate of 768 kHz, good enough for TrueHD, but that is usually even too much for the wires in the HDMI cable. Also, it gets into a grey area with the HDCP license agreement requirements, when you send lossless audio.
Future extensions are certainly a possibility, which could add more reliability, higher bandwidth, and content protection.