On Fri, 2008-11-07 at 01:06 -0500, Jeff Campbell wrote: > A quick question: > > Was this audio problem present from the start of the driver > development or is their a significantly earlier version that doesn't > have this problem? I'd like to help hunt for "what might have > changed" if there was a time when the audio was smooth when reading > (non-cached) direct from the driver to a player.
It's always been there for me. "Always for me" means since I first got the HVR-1600 in early Feb 2008. > Thanks, > > -Jeff > > On Thu, Nov 6, 2008 at 10:56 PM, Jeff Campbell <[EMAIL PROTECTED]> > wrote: > Andy, Hans, > > I'm trying to wrap my head around this stuttering audio issue. > I think it is likely the same reason the TS off the driver is > not usable right now. > > If it is a buffering issue, and given that the stream is muxed > when it is read in to the driver buffers from the chip, how is > it that the video is so stable? I have near perfect video > with the current driver, reading direct from the device, but > in less than a minute of playing it with mplayer I get 10s of > drift between the video decoded and the audio decoded. You need to separate out what is application (mplayer) induced and what is not (i.e. what is driver induced). From my observations it appears that mplayer plays the "audio" it has on hand and will then cut the audio waiting for the video to catch up. The net effects to me appear to be smooth video with choppy audio that happens in advance of the video. Those are just my perceptions. I have not examined mplayer's source. > Is it possible there is some kind of sampling rate issue with > the audio stream before it ever hits the driver read buffer? We set up the cx18 AV core to do the proper sample rates similar to the cx25840 driver. I made a change where I actually made sure the audio sample clock (the AUX_PLL) is over the long term locked to the video sample clock in an effort to fix this problem. So going into the encoder the audio samples are going at the nominal rate with minor jittering by the hardware to stay locked to the video samples to maintain a constant rate of audio/video samples on a frame by frame basis. See the CX25840/1/2/3 data sheet and cx18-av-audio.c and look for the EN_AV_LOCK comments. The only real improvement here could be to run the PLL's in the middle of there range at 400 MHz (200-600 MHz) as opposed to the 300 MHz or so I know we run the AUX_PLL when using 32 ksps. After that, it's up to the APU and CPU on the CX23418 to handle it properly. > I understand that the video has both PTS and DTS stamps, which > helps a player put the stream back together for decode and > presentation, but I would expect to see errors if the video > was wildly out of order or ahead or behind schedule materially > and I see almost no complaints about the video. The audio > only has PTS stamps. That's interesting. Note that if you capture to a file with "cat /dev/video0 > foo.mpg" and then "mplayer foo.mpg" you get very smooth playback. The stream is ultimately well-formed, it's a matter of delivery and decoding in real-time.. > Just thinking out loud, but to get up to an apparent 10s of > drift between the video and audio seems like the problem must > be before the buffered reads in the driver given that the > frames being read contain both video and audio? Again, you would need to separate out how much of that 10s is application induced. Regards, Andy > _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
