On Sat, 2008-11-29 at 19:35 -0500, Jeff Campbell wrote: > I stand corrected, the tuner input also suffers from drift. > > I checked it around 26 hours of continuous use and there was a > material drift between the audio and the video, similar to what was > seen on the AV inputs. The audio is getting ahead of the video.
OK. Seems like we can blame the encoder or apu. Both of these devices are a bit of a black box to me, aside from the limited API they expose. Do you have enough data to quantify how far ahead the audio is getting ahead of the video? Short term averages? long term averages? does it ever seem to resync? It would be nice to have some numbers if I have to make a query to manufacturers. > I sent the debug=3 log entries under a different thread, nothing too > strange appeared there. > > Is AV_LOCK still enabled in the driver? Yes. In that particular area of the driver, I can also try and get the AUX PLL to always have it's VCO run near the VCO center freq (of 400 MHz IIRC) to minimize the amount of error in the audio sample clock. I'm not sure it will have significant effect though. If I can ever get some time away from guests and family this weekend, I was also going to develop a buffering fix to allow very small transfer buffers (as small as 4 kB) between the firmware and driver, but allow more than the firmware limit of 63 buffers. That way I was hoping to get lower latency of buffer transfers to hopefully get finer "sync" (I'm not sure what to call it) between the audio and video. I'm not sure that will help either though. Regards, Andy > > -Jeff > > On Fri, Nov 28, 2008 at 3:47 PM, Jeff Campbell <[EMAIL PROTECTED]> > wrote: > Hi Andy, Hans, > > We're still hunting down the audio issues we raised a while > back. While we thought we had it beat, we have discovered > through testing that over a period of a few days we end up > with audio drift (the audio appears to get ahead of a the > video slightly). Given this, we're still investigating > itwhich is why we haven't reported back. > > We are also actively switching between different inputs > (Tuner, SVideo, Composite), as well as between NTSC and PAL > input sources. We have no yet successfully encoded a PAL > signal from a PAL DVD player. Is there any known issue with > PAL mode? Does anyone have that working with the latest > mainline (1.0.3) driver? > > A few other observations: > > The tuner audio does not appear to drift, although I am > checking that this weekend (leaving it running for 48 hours > straight). > > Switching from NTSC to PAL format and back for the AV inputs > appears to result in an unusualble system and requires a > reboot. > > The transport stream of the tuner feed appears to work > properly (no popping audio or issues), whereas the TS of the > AV inputs exhibits audio problems. If we apply the changes we > shared two weeks ago, the audio problem on the AV inputs goes > away but we eventually see the drift where the audio gets > ahead of the video. > > Andy, out of curiosity, is your primary testing againt tuner > input or do you often use the AV inputs as well? > > We are just at the beginning of digging through the data sheet > on the cx25840 to start to understand the different pathways > and how the AV lock differs between the tuner input and the > other inputs and will share any findings or questions. > > I have a wide range of input types I can test against so if > there is anything you want me to try out and report back on, > please let me know. > > -Jeff > > > _______________________________________________ > ivtv-devel mailing list > [email protected] > http://ivtvdriver.org/mailman/listinfo/ivtv-devel _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
