Originally Posted by UndersAVS
Of course I'm interested in the forum and your comments. Don't let my branding of certain comments as chatter, or denunciation of others lead you to any other conclusion.
Repeating my stance regarding your previous comment:
- there is no certainty that the Reviewer's Onkyo measurements are inaccurate (not "real measurements") because a PC sound card was used
That certainty can exist if it passes additional tests. The problem isn't that it is a sound card, the problem is that its jitter performance is not known well enough. In general audio interfaces used for professional work perform well for jitter and everything else.
- can't conclude that the Reviewer's measurement are wrong (not "real measurements") because your results are different
Agreed. There are many possible explanations for different results when so much seems to be unknown.
- though the Reviewer states "a lot of jitter," the Reviewer's conclusion is that -90db distortion is completely inaudible
I showed how to compare jitter measurements to the thresholds of audibility for jitter as presented in standard, authoritative texts in the "Coax versus HDMI" thread that was closed.
I'm I not comprehending the significance of the difference between "low frequency jitter components that are bunched up on top of the main signal tone" which aren't easily observed in the Reviewer's graph, but apparent in your illustration?
The audibility of jitter varies with the modulating frequency, as I showed in the now closed "Coax versus HDMI" thread. I also showed how to adjust measurements that are made with different test tones.
Based upon the opinions you have given thus far, it seems that you believe engineering principles/studies cannot explain whether audibility of jitter measured -90db can be discerned, and double-blind listening tests are needed. True or false?
Well there's one little problem, and that is that analysis based on standard, authoritative texts about the audibility of jitter says that these quantities and and modulating frequencies fall well short of producing audible jitter.
One reason that HDMI jitter tends to be numerically greater is that HDMI audio is transmitted in widely separated possibly varying and therefore somewhat intermittent fairly long packets, which makes the job of the buffer on the receiving end that much harder. In a SP/DIF connection, the audio information is transmitted in small packets that follow each other closely with consistent timiing.
Therefore HDMI audio has to be buffered and reclocked no matter what format it is in.
Transition Minimized Differential Signaling (TMDS) on HDMI interleaves video, audio and auxiliary data using three different packet types, called the Video Data Period, the Data Island Period and the Control Period. During the Video Data Period, the pixels of an active video line are transmitted. During the Data Island period (which occurs during the horizontal and vertical blanking intervals), audio and auxiliary data are transmitted within a series of packets. The Control Period occurs between Video and Data Island periods.
Both HDMI and DVI use TMDS to send 10-bit characters that are encoded using 8b/10b encoding that differs from the original IBM form for the Video Data Period and 2b/10b encoding for the Control Period. HDMI adds the ability to send audio and auxiliary data using 4b/10b encoding for the Data Island Period. Each Data Island Period is 32 pixels in size and contains a 32-bit Packet Header, which includes 8 bits of BCH ECC parity data for error correction and describes the contents of the packet. Each Packet contains four subpackets, and each subpacket is 64 bits in size, including 8 bits of BCH ECC parity data, allowing for each Packet to carry up to 224 bits of audio data. Each Data Island Period can contain up to 18 Packets.
Seven of the 15 Packet types described in the HDMI 1.3a specifications deal with audio data, while the other 8 types deal with auxiliary data. Among these are the General Control Packet and the Gamut Metadata Packet. The General Control Packet carries information on AVMUTE (which mutes the audio during changes that may cause audio noise) and Color Depth (which sends the bit depth of the current video stream and is required for deep color). The Gamut Metadata Packet carries information on the color space being used for the current video stream and is required for xvYCC.
I've spent my life reading documents like this, and IMO its difficulty is about 90th percentile.
This article provides more information and some pictures which may help:
"HDMI® employs Transition Minimized Differential Signaling (TMDS) transmitted over 4 pairs of wires to carry video, audio and auxiliary data via one of three modes, called the Video Data Period, the Data Island Period and the Control Period. During the Video Data Period, the pixels of an active video line are transmitted. During the Data Island period (which occurs during the horizontal and vertical blanking intervals), audio and auxiliary data are transmitted within a series of packets. The Control Period occurs between Video and Data Island periods."
Let's start out relatively simple - with S/PDIF. S/PDIF data streams are composed of data blocks:
In S/PDIF Audio is not transmitted as a uniform continuous stream of 16 bit samples. Instead, audio data regardless of sample format is padded out into 32 bit subframes. There are 2 subframes (1 per channel) per frame. Frames are collected into groups of 192 which are called data blocks. Multichannel recordings are usually handled internally as multiple stereo streams. This frame structure creates an opportunity for jitter because there is a break in the data every 192 sample pairs. With 44.1 KHz sampling this works out to be about 230 Hz (or 250 Hz for 48 KHz).
Sometimes jitter artifacts at multiples of 230 or 250 Hz can be observed in the outputs of DACs. There is also a data structure on the CD which groups samples for the purpose of error detection and correction. This provides another opportunity for poorly designed circuitry to create jitter artifacts at other frequencies in the same general range.
So much for S/PDIF which isn't all that simple! ;-) Now lets talk about HDMI.
One of the surprises about HDMI is that its data format hasn't changed that much from the days of CRT displays. The data for each scan line is grouped together. Near the end of the scan line there is an allowance for what used to be called the retrace interval, which was required in the days of analog video processing and CRT displays to allow CRT beams to skip back to the left edge of the screen. During the retrace interval the display device blacked out or blanked the screen, so this time period could be used to hold any non-video (or in HDMI terminology Auxiliary Data which includes sound) data that needs to be transmitted. In the days of NTSC video these periods of blanked out video were used for things like closed captioning.
There are both horizontal retrace intervals which are relatively short and frequent, and vertical retrace intervals which are usually longer and far less frequent. Therefore sound data is showing at the front door of the audio circuitry in an AVR in little batches that are interrupted at both the horizontal scanning rate (one cycle for every horizontal row of pixels) and the vertical scanning rate (one cycle for every video frame or still picture that is transmitted in quick succession to create the impression of motion video.
So, poorly designed equipment can add jitter at both the overall frame rate (24, 30, or 60 Hz) and the horizontal scan rate - 480, 720, or 1080 lines per screen full of data for the most common video standards.
I've been sitting here watching people pontificate about jitter, knowing from my own studies and lab work that certain jitter frequencies will pop out over and over again due to the fact that audio data is transmitted mixed in with video data, but in various sized groups. AFAIK
nobody said nuttin', and that gives me an idea about who is posing and who actually plays. ;-)
People who understand what they need to about HDMI may realize that HDMI jitter frequencies are often keyed to video format because the audio data is mixed in with the video. Therefore, analysis of audio measurements have to take picture format into account, which unfortunately one rarely if ever sees in published test reports.