Loading...

ivtv-devel@ivtvdriver.org

[Prev] Thread [Next]  |  [Prev] Date [Next]

Re: [ivtv-devel] Fwd: [UNKNOWN IVTV CARD] (cx23416) AverMedia M113-C Ravi A Sat Jul 18 15:00:07 2009

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.

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