Having got softdevice working recently (with Matrox G450 TV out), I've used it to watch a couple of films I've recorded. On one of them it seemed fine, but on the other there was a noticeable delay between audio and video. Every so often the picture would go sort of jerky for a few seconds as if it were dropping frames to try to get back in sync, but failing. The amount of delay seemed fairly consistent. I had a similar problem with MPlayer (except the periods of jerking) until someone told me to try -ao oss because it's buggy with alsa. Is softdevice's audio code based on MPlayer's, perhaps? libsoftmpeg's IDEAS file <http://linuxtv.org/cgi-bin/viewcvs.cgi/libsoftmpeg/IDEAS?view=markup> mentions adjusting the speed of sound playback (presumably by resampling) to avoid buffer xruns if the sound card's clock doesn't quite match the broadcast stream's. I think this resampling idea could be used to approach A/V sync from a different angle. The curent problem is that existing players are designed to play the sound at a certain rate and then sync the picture to it. That means if video playback is also synced to vblank, and you can't control the video card's clock, you have to drop or repeat frames to adjust the picture timing. If you don't bother syncing video frame changeovers to the hardware vblank it tends to cause "tearing" artifacts for progressive scan video, and is pretty disastrous for interlaced video. So seeing as there's a need to keep the video in sync with the hardware, why not base the playback timing on the video and adjust the sound to match it instead of the other way round? There are plenty of resampling libraries already available. You may still need to drop/repeat frames to keep up with a broadcast stream, but this approach could offer an improvement and avoid sound glitches from xruns if the video card's clock is a closer match to the source than the sound card's - in my PC I'd trust the Matrox more than its ?5 sound card, but users with good sound cards just may be better off with the current method. For playback of recordings though I think my idea should give smoother results. -- TH * http://www.realh.co.uk
