On Sun, 2009-07-19 at 00:30 +0530, Ravi A wrote: > On Sat, Jul 18, 2009 at 6:19 AM, Andy Walls<[email protected]> wrote: > > On Fri, 2009-07-17 at 19:16 -0400, Andy Walls wrote: > >> On Sat, 2009-07-18 at 02:35 +0530, Ravi A wrote: > >> > On Tue, Jul 14, 2009 at 6:07 AM, Andy Walls<[email protected]> wrote: > > > >> > It so happens the driver/utility is setting the input back to Y0 > >> > (default, white connector) whenever video format is changed - > >> > > >> > $sudo v4l2-ctl -s pal > >> > sets MUX input to Y0 from wherever it was. However - > >> > $sudo v4l2-ctl --log-status > >> > still shows the input to be Line-In! > >> > > >> > $sudo v4l2-ctl -i1 > >> > $sudo v4l2-ctl -i2 > >> > sets the input back to Y1 and sound re-appears. > >> > > >> > Is this how the behavior should be? > >> > >> Nope. Good observation, this is the bug. I checked the source code of > >> ivtv-gpio.c and the version history, and it's a bug that's been in the > >> ivtv driver since before it was in the mainline kernel. > >> > >> It should be striaght-forward to fix the behavior, but I'll have to take > >> a look and make sure there's not some odd board that needs something > >> special. I'll have a patch ready soon. > > > > Ravi, > > > > I have pushed a patch to > > > > http://linuxtv.org/hg/~awalls/ivtv > > > > > > The bug was ancient. It looks like it arose from an old method of > > setting the tuner back to TV when exiting from FM radio mode. It had > > the side effect of changing the audio input of a GPIO audio mux back to > > the tuner whenever the video standard was changed when you were not in > > radio mode. > > > > Apparently no one with a card with a GPIO audio mux ever changed the > > standard when set to Composite or SVideo. > > > > > > > >> > When MUX is set properly and sound is present, the volume was still a > >> > bit low and it seemed very noisy - something like zero-crossing > >> > distortion. I could improve it a bit by setting volume all the way > >> > high. > >> > sudo v4l2-ctl -c volume=65535 > >> > Setting bass and treble to '0' helped to reduce the distortion/noise > >> > significantly although the volume still seemed low > >> > sudo v4l2-ctl -c bass=0 > >> > sudo v4l2-ctl -c treble=0 > >> > > >> > If I can get v4l2-dbg to read/set registers maybe I can try more > >> > experiments for the audio quality. > > > > Yes, it will give you the flexibility to experiment will all sorts of > > audio settings. > > > > Regards, > > Andy > > > > > > > Hi Andy, > > With the latest patch, the MUX control becomes stable and the audio > stays put with video standard changes! > > Now that the audio is stable, I notice some possible issue with the > PLL VCO center frequency adjustment patch. Both e8fcd13e4ae7 and > d7e1eb4b17d8 show some skips/gaps in both video and audio (Composite > input). After 10 seconds of playing with mplayer the following is > output - > "Your system is too SLOW to play this! .. blah" > and after another 10 seconds a continuous stream of "Too many video > packets in the buffer: (4096 in 8007268 bytes)... blah" appear. > Patches 82a264ea2784 and 7ea3e7b9a657 do not show this, both video and > audio are smooth.
Oops. The CX23416 firmware seems to be assuming a crystal value of 28.636363 MHz for the CX2584x, where the CX23418 firmware assumes a crystal value of 28.636360 MHz for it's internal A/V decoder. (I wish they had both assumed the correct value of 28.63636363... MHz.) I'll have to get out my spreadsheet and recompute the values. I'll push a patch tonight. I'll also try to test with my PVR-150 (but might not get to testing it tonight). Regards, Andy > I was able to finally read some registers after compiling the latest > v4l2-dbg. I will try tweaking audio registers using 82a264ea2784 next. > > Regards > Ravi _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
