The problem with audio/video delay goes back a long way, but things have reversed here.
The problem was that there is latency in the video chain, measured in multiples of the frame period. Video gets buffered up by frame in many places, and the delay can become irksome. When we used DVD/BluRay players as the prime source both the video and audio came off the disk at the same time in the one data stream. The video then went through multiple steps of decompression and various processing steps to improve the quality. Most of these steps work on an entire frame, so it was easy to get quite a few frames worth of delay. TVs did their own processing on the input, and added a frame or two (at least) as well. So AVRs (and TVs, players) all provided a simple delay on the audio to get the sync back. This is easy, as the data rate is low compared to video.
Now we have the opposite issue. Processing of audio becomes the pacing item. So we want to delay the video. AVRs have pretty much moved away from any video processing. There just isn't any need. There is no capability in an HDMI switch (which is all most AVRs have inside now) to delay video. So if you want to delay the video longer than the existing processing chain you have to look elsewhere.
Obviously a HTPC, if it has locally stored content, is able to access that content at arbitrary offsets, and can offset the audio and video in either direction with any desired offset.
Streaming boxes are more interesting. Internally all streamers must include some buffering. Some have a lot. The potential exists for all of them to provide near arbitrary offsets, but whether any provide what is needed, and useful control, is another matter.
An interesting problem is that streaming devices can mess with the video formats, and can uncompress at various rates and resolutions. This can result in different video processing delays, something that seems to cause some amount of grief when aligning audio on some systems.
The problem was that there is latency in the video chain, measured in multiples of the frame period. Video gets buffered up by frame in many places, and the delay can become irksome. When we used DVD/BluRay players as the prime source both the video and audio came off the disk at the same time in the one data stream. The video then went through multiple steps of decompression and various processing steps to improve the quality. Most of these steps work on an entire frame, so it was easy to get quite a few frames worth of delay. TVs did their own processing on the input, and added a frame or two (at least) as well. So AVRs (and TVs, players) all provided a simple delay on the audio to get the sync back. This is easy, as the data rate is low compared to video.
Now we have the opposite issue. Processing of audio becomes the pacing item. So we want to delay the video. AVRs have pretty much moved away from any video processing. There just isn't any need. There is no capability in an HDMI switch (which is all most AVRs have inside now) to delay video. So if you want to delay the video longer than the existing processing chain you have to look elsewhere.
Obviously a HTPC, if it has locally stored content, is able to access that content at arbitrary offsets, and can offset the audio and video in either direction with any desired offset.
Streaming boxes are more interesting. Internally all streamers must include some buffering. Some have a lot. The potential exists for all of them to provide near arbitrary offsets, but whether any provide what is needed, and useful control, is another matter.
An interesting problem is that streaming devices can mess with the video formats, and can uncompress at various rates and resolutions. This can result in different video processing delays, something that seems to cause some amount of grief when aligning audio on some systems.