Mailing List Archive

Re: cx18: Observations about TS and AV lock, also Q on input types tested
On Fri, 2008-11-28 at 15:47 -0500, Jeff Campbell 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.

I don't mind. I have no shortage of other problems to fix in the
meantime. ;)

BTW I do appreciate thorough investigations and evidence. It saves me
time. Thank you.


> 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?

Hmm. That's the first I've heard it not working. We've had previous
reports that it was.

1 PAL from a DVD player with a PAL output, but connected to a Conexant
Rator PAL/SECAM eval board.

2. A Compro H900 user seems to have some analog front end issues with
false hsync's on very bright scenes, but it otherwise works.

3. Hans has an H900 that I assume he's tested with PAL.

I need to buy a PVR-350 one of these days to start testing with PAL.

> Does anyone have that working with the latest mainline (1.0.3)
> driver?

I have no idea.

>
> 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).

That comes in as Sound IF (SIF) into the CX18-AV-Core and is converted
to digital samples there.

The AV baseband audio gets digitized by the CS5345 chip and comes in on
one of the I2S inputs as digital samples.


> Switching from NTSC to PAL format and back for the AV inputs appears
> to result in an unusualble system and requires a reboot.

Ack. That's not good. I'd like to test. Can you give me the specific
set of v4l2-ctl commands to replicate the problem if possible?


> 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.

Hmmm. I'm not sure what may be happening. I had never considered
before that the I2S interface between the CX23418 and the CS5345 may
have something misconfigured. I guess I'll have to look at that too.



> Andy, out of curiosity, is your primary testing againt tuner input or
> do you often use the AV inputs as well?

Analog and digital tuner. If "General Hospital" (a US daytime
television drama) doesn't get recorded without fail, my wife lets me
know. :)

I do have two alternate machines to which I connect a set top box, one
has an HVR-1600 and the other has a Conexant Raptor PAL/SECAM card. I
sometimes check with those, but usually when investigating problem
reports.


> 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.

Feel free. The datasheet can be less than clear, especially on first
read. I'd also recommend digging up the CS5345 data sheet for
understanding the baseband audio digitization and multiplexing.

Regards,
Andy

> 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
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
Re: cx18: Observations about TS and AV lock, also Q on input types tested [ In reply to ]
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 <jac1dlists@gmail.com>
> 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
> ivtv-devel@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-devel


_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
Re: cx18: Observations about TS and AV lock, also Q on input types tested [ In reply to ]
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.
>
> I sent the debug=3 log entries under a different thread, nothing too
> strange appeared there.
>
> Is AV_LOCK still enabled in the driver?
>
> -Jeff
>
> On Fri, Nov 28, 2008 at 3:47 PM, Jeff Campbell <jac1dlists@gmail.com>
> 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.

Jeff and cdash,

I just checked in this patch to fix cx18_writel_expect() in my personal
v4l-dvb repo:

http://linuxtv.org/hg/~awalls/v4l-dvb/rev/215b27875810

I've already asked the v4l-dvb maintainer to pull it to the main repo.
I suspect it may fix the source of cdash's and my "no analog audio"
problem and Jeff's standards switching problem. You're welcome to try
it out before it hits the main repo.

Regards,
Andy



> 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
> ivtv-devel@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-devel


_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
Re: cx18: Observations about TS and AV lock, also Q on input types tested [ In reply to ]
A further data point - the volume control for the tuner audio (sort of)
works. Whereas the volume control for the AV inputs does not work.

On Sat, Nov 29, 2008 at 9:02 PM, Andy Walls <awalls@radix.net> wrote:

> 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 <jac1dlists@gmail.com>
> > 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
> > ivtv-devel@ivtvdriver.org
> > http://ivtvdriver.org/mailman/listinfo/ivtv-devel
>
>