# HR21 Audio Out of Sync



## Dog88 (May 17, 2007)

I just upgraded to the DirecTV HR21 HD DVR and the picture quality is great but the audio is out of syn on certain channels (the 500's).

The installer said this is caused when the cable run from the dish to the receiver is over 100 feet. I don't this this is logical since the sync problem is only on certain channels and not others. The picture quality and satellite signal strength is near 100%.

1) So, my question is can a long cable run cause an audio sync problem only on certain channels?

2) Any ideas on how to fix this problem other than getting a home theater with audio delay adjustment? That would be a pain to adjust when flipping from one channel to another.

Thanks


----------



## TyroneShoes (Sep 6, 2004)

Dog88 said:


> ...The installer said this is caused when the cable run from the dish to the receiver is over 100 feet. I don't this this is logical since the sync problem is only on certain channels and not others....
> 
> 1) So, my question is can a long cable run cause an audio sync problem only on certain channels?
> 
> ...


In a world of incredibly ignorant installers, this explanation takes the cake. Cable length has absolutely nothing to do with it.

Without getting too deep, if you think about this for just a second, we are talking about packetized digital delivery, where streaming files are stitched back together once received, and then written to the HDD. The resultant file on the HDD is actually very similar to (virtually the same as) the file sent to the uplink exciter, meaning if there was a problem with the lipsync on your HDD, that problem must have existed before the signal was ever even streamed to you, since the audio and video are locked together at encode all the way to decode.

The cable (dish to STB) is just one of many elements in the chain, but is definitely in the part of the chain where files are still encoded, so that can have no effect whatsoever.

Your proposed solution, if somewhat inelegant, is one that actually works pretty well. I set mine at 40 ms and it seems to keep all lipsync to a tolerable level. It can get noticeable when large enough, but a reduction of about 40ms seems to be a happy medium where I don't notice it very often.

Actually, my suspicion is that the lipsync has always been there, and that the addition of a HD DVR (this model in particular) adds a little error of its own, the same way certain new HD displays add a little more delay than analog ones do. It might have just pushed everything into the zone where you begin to notice it.


----------



## Dog88 (May 17, 2007)

Thank you for the explanation.


----------



## Jim Abbett (Nov 6, 2005)

You can sometimes get it closer to being in sync by hitting the list and exit buttons in sequence a few times.


----------



## stevel (Aug 23, 2000)

There have been many reports of lipsync issues on the new MPEG4 channels, but not all of them and not all the time. My experience is that the situation has improved somewhat over the past several months but has not gone away. I don't think it's a problem in the receiver, but I'm far from certain on that.

Even with the HR10, I had to set my receiver's audio delay to 40-50ms - this is a common issue with HDMI connections. However, the MPEG4 channels sometimes have much higher delays, so one setting does not fit all.


----------



## joed32 (Jul 9, 2005)

2) Any ideas on how to fix this problem other than getting a home theater with audio delay adjustment? That would be a pain to adjust when flipping from one channel to another.

When I did it on my AV receiver i fixed it for CSI Miami. and never had to touch it again.


----------



## TyroneShoes (Sep 6, 2004)

Earlier I posted that adding 40ms of delay made pretty much all sources tolerable. I may have spoken too soon.

I don't usually watch recordings on my HR20, which I have had for a couple months, it usually only records SD shows and backups of what I record OTA on my two HR10s, so I just might not have noticed, but last night I was trying to get through "Lipstick Jungle" (probably not going back there again), and I noticed that I needed 90ms to correct lipsync (this on a HD LIL MPEG4/OTA channel). Of course nothing those broads were saying made much sense anyway, but I'll let it die a natural 7-ep death.

OTA recordings on this channel historically have done well with 40ms of correction. I did not have an opportunity to check anything else, but is there anyone here who feels like possibly the HR2x or the new MPEG4 channels have a lot more video delay (thus more lipsync error) than typical HR10 recordings?

Maybe they should have entitled this show "Lipsync Jungle". Ha ha. get it? he he. get it? (OK, Ty, we get it...go lay back down).


----------



## stevel (Aug 23, 2000)

There is no "fix" for this problem available to the end user, unless you can readjust the audio delay as needed.

Yes, the MPEG4 channels have much more delay - some of them, anyway. And not all the time. There is extensive discussion of this topic at dbstalk.com.


----------



## TyroneShoes (Sep 6, 2004)

stevel said:


> There is no "fix" for this problem available to the end user, unless you can readjust the audio delay as needed.
> 
> Yes, the MPEG4 channels have much more delay - some of them, anyway. And not all the time. There is extensive discussion of this topic at dbstalk.com.


Using a local delay is not regarded as a "fix", but a common and usually effective workaround.

Without studying the issue of the new channels closely, my take on it had been based on the common practice of getting a channel "on the air" and then tweaking the smaller issues after the fact. It seems to be common that when HD channels launch, there is a period of adjustment where the engineers discover there is a lipsync problem, order equipment to compensate for the problem, and finally receive and install it. My hope was that this was what was plaguing the new HD channels on DTV, most of which would not even exist had DTV not given them a place to launch.

But maybe I was jumping to an incorrect conclusion. An OTA channel has typically already fixed any lipsync issues it might have had, so I was surprised to see that the M4 version of this channel had 50ms more of error in it than the M2 version. DTV is reencoding, but that is unlikely the problem. It seems like the HR2x itself is where the extra video delay is coming from.

If so, that is not good, because it means it likely won't ever get better, and it aggravates the issue for folks who receive some M2, some M4, and some OTA channels if some have significantly more delay than others or use both HR10's and HR2x's (meaning no happy medium can be set on an AVR). I hope the USB tuner for the 21 doesn't make things even worse.

And I STILL may be speculating in the wrong direction. I guess an experiment is in order.


----------



## joed32 (Jul 9, 2005)

TyroneShoes said:


> Using a local delay is not regarded as a "fix", but a common and usually effective workaround.
> 
> Without studying the issue of the new channels closely, my take on it had been based on the common practice of getting a channel "on the air" and then tweaking the smaller issues after the fact. It seems to be common that when HD channels launch, there is a period of adjustment where the engineers discover there is a lipsync problem, order equipment to compensate for the problem, and finally receive and install it. My hope was that this was what was plaguing the new HD channels on DTV, most of which would not even exist had DTV not given them a place to launch.
> 
> ...


On my Onkyo AVR you can set up each input separately. I would think that most would be that way.


----------



## JANVideo (Aug 29, 2000)

This audio sync problem has a tremendous amount of variablility and is supposed to be solved by the latest HDMI 1.3 spec, but all devices in that chain have to support this feature and I don't know of any displays that use that at this time. (The HDMI signal will contain a correction parameter that will guarantee audio sync).

In the meantime, the problem is that the broadcast station some times does not correctly transmit in correct sync, the cable or satellite head end can add some delay, and the display you are using adds delay of it's own. 
Sometimes the receiver processing the audio decode can also add delay.

The sync problem is caused by the amount of time that the video stream needs to process the video. It is always much larger than the time needed to process the audio, so the audio will almost always preceed the video. So you need to delay the audio to match the video. Another problem is that each different source you use may need a different amount of delay. 

I use an outboard switcher/scaler (DVDO VP30). This device allows me to set a separate delay for each input I use. So I use 120ms for an HR10-250, 60ms for an HR20, 80ms for a Tivo Series 2, 100ms for the DVD input, 50ms for the DVD recorder. The only time I see slight variations are from each of the different tv channels I might tune using the various DVRs.
Joel


----------



## stevel (Aug 23, 2000)

The HDMI 1.3 spec does not "solve" the problem. It only provides the ability to communicate audio delay timing over the HDMI link.

The DVR should know the timing involved and impose its own delay to put the audio and video in synch.


----------



## TyroneShoes (Sep 6, 2004)

JANVideo said:


> This audio sync problem has a tremendous amount of variablility and is supposed to be solved by the latest HDMI 1.3 spec, but all devices in that chain have to support this feature and I don't know of any displays that use that at this time. (The HDMI signal will contain a correction parameter that will guarantee audio sync).
> 
> In the meantime, the problem is that the broadcast station some times does not correctly transmit in correct sync, the cable or satellite head end can add some delay, and the display you are using adds delay of it's own.
> Sometimes the receiver processing the audio decode can also add delay...


As you demonstrate, there are a lot of places in the chain where error can creep in. There is no way an HDMI spec can "guarantee" that it will correct for error that creeps in upstream, because there is no way for the HDMI spec to examine the audio for markers that it can use for correction, as currently they don't exist.

SMPTE, however, IS trying to find a way to fix this, and by doing just that, which would consist of origination-point content having markers added to the bit stream in the form of metadata. If all equipment in the chain up to and including the uplink monitor and correct any measurable error, that will fix the problem, which is a big undertaking, and impossible to do downstream without some way of decoding that new metadata. If that capability were put into the local consumer decoder, we would probably have a system that works, at least for content that has the original markers spliced in at origination.



JANVideo said:


> ...
> The sync problem is caused by the amount of time that the video stream needs to process the video. It is always much larger than the time needed to process the audio, so the audio will almost always preceed the video. So you need to delay the audio to match the video...


 Well, you sort of have it. The delay is caused by two things. The first is frame-syncs, which store video in a buffer for up to two frames before clocking it back out (independent of audio, which marches right along unimpeded). The number of frame-sync boxes in the typical processing chain has grown exponentially in the last decade or so, and the delay is cumulative. At some point it becomes noticeable.

There is yet even more delay in a consumer display. In a manner similar to that in frame syncs, for 1080i, for instance, it has to store the first field in a buffer while it waits for the second frame to be delivered, then stitches that back together as a progressive frame. The result is a bit more delay, and possibly enough more to push the delay into the zone of perception (you can have a lot of delay before it's even noticed, and that "last straw" makes it obvious).

The second place error can creep in is due to MPEG encoding. MPEG is somewhat elastic, and when video that is hard to encode is encountered, the resultant decode is slowed just a tiny bit. Over time, this can be significant. If you try to encode video snow, which is very hard to encode, you can have as much as 7 seconds of accumulated delay in 24 hours. I know this because I have first-hand experience with it. We "net-delay" video for broadcast, and if the signal on line goes to snow after the program ends this can be the result the next day if the server recording is not restarted.

Good broadcasters fix the delay before it leaves the facility. Cable and satellite aren't as vigilant, as they have many more streams to worry about and to buy delay equipment for, so they may just look the other way. DTV obviously looks the other way at closed captioning, and probably at lipsync as well.

Dual broadcast of HD and SD complicates things. Fix the delay in the analog signal and it may then be off even further for the digital signal. Once analog shuts off, I predict a lot of delay problems for OTA will be ameliorated.


----------

