You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The latest feature includes Calibration Offset Support for the Observation Algorithm. #95 - Q3
To add a calibration offset to the observation algorithm, users need to obtain a calibration recording. This requires recording the test media for calibration, which should be played back on a PC using the same camera intended for the DPC tests. Using a PC ensures that any offset introduced by the device itself is avoided.
It is crucial to maintain consistency in the audio connection method from the PC playing the A/V sync test media to the camera, as well as during the actual WAVE tests from the Device Under Test (DUT) to the camera. For example, if a 3.5mm audio cable is used for the A/V sync test, the same 3.5mm cable should be used for recording audio from the DUT to the camera.
For devices without a 3.5mm audio jack, such as those relying on HDMI ARC for audio, replicating the same setup on a PC can be challenging because most PCs do not support HDMI ARC natively.
I believe maintaining the same audio connection method is critical, as different connections could introduce varying offsets. Could anyone help to confirm if comparing a 3.5mm audio jack with HDMI ARC might result in any different audio latency/offset or not please?
Latency:
3.5mm Audio Jack: Generally has lower latency, which might be beneficial for synchronization purposes.
HDMI ARC: Can introduce a small amount of latency, but is this negligible that we can ignore please?
If the delay on HDMI ARC is negligible, we can recommend that users capture the test media using a 3.5mm audio jack.
The text was updated successfully, but these errors were encountered:
Normally default settings should ensure TV digital audio outputs (e.g. ARC) are in-sync with video, exactly the same as analogue audio outputs (e.g. 3.5mm headphones jack).
Additional latency could be caused by the need to decode the digital audio output, when a TV outputs audio in a bitstream format (e.g. AC-3).
This can be avoided by ensuring the TV digital output format is always uncompressed stereo PCM.
So to answer your question:
Might comparing a 3.5mm audio jack with HDMI ARC result in any different audio latency/offset or not ?
When properly configured, no, there should be no difference in latency.
The latest feature includes Calibration Offset Support for the Observation Algorithm. #95 - Q3
To add a calibration offset to the observation algorithm, users need to obtain a calibration recording. This requires recording the test media for calibration, which should be played back on a PC using the same camera intended for the DPC tests. Using a PC ensures that any offset introduced by the device itself is avoided.
It is crucial to maintain consistency in the audio connection method from the PC playing the A/V sync test media to the camera, as well as during the actual WAVE tests from the Device Under Test (DUT) to the camera. For example, if a 3.5mm audio cable is used for the A/V sync test, the same 3.5mm cable should be used for recording audio from the DUT to the camera.
For devices without a 3.5mm audio jack, such as those relying on HDMI ARC for audio, replicating the same setup on a PC can be challenging because most PCs do not support HDMI ARC natively.
I believe maintaining the same audio connection method is critical, as different connections could introduce varying offsets. Could anyone help to confirm if comparing a 3.5mm audio jack with HDMI ARC might result in any different audio latency/offset or not please?
Latency:
If the delay on HDMI ARC is negligible, we can recommend that users capture the test media using a 3.5mm audio jack.
The text was updated successfully, but these errors were encountered: