HDMI audio needs plugfests and standard tests
Martin Rowe, Senior Technical Editor -- Test & Measurement World, 3/27/2009 10:30:00 AM
Tom Kite is the VP of engineering at Audio Precision. Over the last several months, Kite has seen the pluses and minuses of “plugfests,” where engineers from numerous manufacturers come together to test how well their products interoperate. While Kite acknowledges the value of plugfests, they can’t assure that your product will work with every other product that a user will connect to it. I spoke to Kite by telephone from his office in Beaverton, OR.
Q: Tom, please explain what kind of audio problems you’ve seen surface at plugfests for HDMI products.
A: Audio Precision attended an HDMI plugfest in the fall of 2008. While there, we witnessed several interoperability issues. We brought two HDMI audio analyzers with us, one to act as an audio source, the other as a sink. We saw difficulties on both ends. For example, we saw products that claimed to support certain audio formats in their EDIDs (extended display identification data) that they didn’t actually support.
Q: What is an EDID?
A: An EDID is a ROM inside a piece of HDMI sink equipment such as a TV that informs the HDMI source of what audio and video formats the sink supports. For audio, that includes the number of channels, types of codecs, and sample rates.
Q: What sort of EDID problems have you seen?
A: EDIDs are proving to be headaches. You have to set it up correctly or the source may send formats that the sink can’t handle. For example, if a sink needs 480p video but a source can deliver 1080p, and the source is responsible for downscaling the video to the 480p. If the sink doesn’t report its capabilities properly, you’re likely to get interoperability problems.
At plugfests, we found that you need to know what your product’s EDID is saying. You need to read that in English, not in hexadecimal code.
Source device manufacturers such as those who make DVD players must test their products with a wide variety of EDIDs as part of their testing. At a plugfest, you have an ad hoc collection of EDIDs. If you manufacture a player, you might have a chance to test your equipment on 30 different EDIDs, but that’s not close to covering how much an EDID can do. You also need a systematic way to test, which test equipment can do.
Q: Please give an example of a problems you’ve seen.
A: At a plugfest, I was working at the “sink” station, so people with sources came to us. One engineer, whose company had developed at SPDIF (Sony/Philips Digital Interconnect Format)-to-HDMI audio converter, brought his product to the booth. In one of its modes, it was supposed to pull all SPDIF audio bits and translate them “bit exact” to HDMI. We tested the device by generating 24-bit SPDIF audio and receiving the HDMI audio. We looked at the 24-bit HDMI audio. When we sent a digitized sine wave into the converter, we noticed that the noise level was higher than expected. That made me suspicious, so I then sent a known pseudorandom bit sequence to the converter. We looked at the bits as they came out of the converter’s HDMI port and found that the converter had truncated four bits. The engineer admitted that he had to redesign his device.
Q: Why do you use a pseudorandom bit sequence?
A: We use it because we know what the bit pattern should look like and we can identify errors by looking at the bits. The analyzer doesn’t need a copy of the incoming bit sequence because it already knows what to expect.
Q: Are the last four bits of 24-bit audio important?
A: That’s arguable, but I think that this product was to go into other products. I’m sure that its design specifications called for 24-bit pass through and it wasn’t meeting that requirement. The engineer was concerned that if it was losing the last four bits, then it might be altering the remaining bits in some other way as well. For example, if you sent coded audio through the converter, it must pass the bits through exactly as it receives them. Otherwise there would be no hope of recovering the encoded audio.
Q: Why not?
A: The last four bits in encoded audio aren’t audio bits. They contain error-checking data such as CRC (cyclic redundancy check) bits. If the receiver doesn’t receive those bits, its “game over” and the audio can’t be decoded. Even a single lost bit is enough to prevent deciding.
Q: How to you test encoded audio?
A: We use a known sequence that we encode into an audio packet. The audio packet still looks like an audio packet, but some of the payload is known. The analyzer knows that sequence and which parts of the packet contain it. You can’t replace all of a packet with a known sequence because the receiver will simply reject the packet. The analyzer knows which bits to example and check that they’re bit exact.
Q: What do those known bits look like?
A: Suppose that you’re sending audio over SPDIF. If that audio is linear, then we can send a pseudorandom bit sequence and the analyzer can check every sample and compare it to a known level. With encoded audio, the audio is in a completely different format. It’s in a layer that you can think of as riding on the SPDIF protocol. Specifically, it’s IEC 61937. The packets have different shades depending on the audio format. We sent encoded test packets over the link.
You may have a Blu-ray player with a decoder in it, which is common. Blu-ray players are being marketed on the fact that they have Dolby HD audio decoders. An audio test can tell if every audio bit is properly encoded and decoded. We’ve found some products that don’t properly encode and decode audio, which is somewhat disappointing.
Q: I see how this can result in a repeatable test and I can see where plugfests can miss things.
A: Plugfests are extremely valuable. They are the most efficient way to connect equipment to lots of other equipment. But, it’s just a first—or possibly last—step in testing.
You can’t cut corners in test. You must “stick to your guns” and maintain a rigorous test program or your product will suffer. It’s up to test engineers to convince their managers to the value of test. For example, had the SPDIF decoded and gone to market, someone would have discovered that the last four bits of each sample were being dropped.
Q: What other problems have you seen?
A: We’ve seen problems with audio level that result in “soft clipping.” We made some test disks that had known bit sequences. Dave Mathew, one of our engineers, found that some Blu-ray players won’t play all possible sample rates. Some won’t play audio sampled at 192 kbps.
Some Blu-ray players play the LFE (low-frequency effects) audio channel incorrectly. LFE is like the “.1” in 5.1 audio. It’s common for movies to have an LFE track. It should come out at a certain level and that doesn’t always happen. It’s up to the receiver to apply the right amount of gain to the LFE audio to get it right.
We also found that some HD audio decoders in some players don’t do that. Through a bit test, we found that some decoders aren’t bit exact. One common Blu-ray player seems to clip the audio by about 3% when the audio is played near its full value. The digital audio looks like it’s experiencing saturation distortion in an analog sense. That’s unusual for a digital player. The public expects true HD performance.
These are the sort of interoperability issues that come up with HDMI. The consumer doesn’t care who’s at fault, just that the audio doesn’t sound right.
HDMI audio devices need rigorous tests
04/01/2009Audio analyzer adds logic display
06/22/2009Analyze HDMI audio streams
04/15/2008Analyze HDMI audio streams
05/31/2008
-
FLIR offers IR camera for under $3000
-
Don't let the economy compromise quality (Guest commentary)
-
Danaher speeds up restructuring, acquires life-sciences businesses
-
Agilent’s Cover-Extend technology eliminates need for physical test points for in-circuit test
-
So many combinations: Testing a switch-matrix board
View All Webcasts
