Hi,
i have finaly had some time, i created a diff kernel tree of the 23 kernel
that works and the 25 that has the tinny audio.
i didnt notice anything that stood out, but when i reviewed cx25840-core.c
i noticed that it had what looked like code thats changing registers, with
that in mind and knowing the register thats causing issues i searched it,
and in that file i found 2 lines that where added changeing register 0x810
this is the diff block pertaining, and it just so happens to be working
with the microcontrollor as andy was saying how ever if i understand it,
it is doing the same as andy said changing the register to 1 and then to
0.
@@ -251,8 +364,13 @@
}
cx25840_and_or(client, 0x401, ~0x60, 0);
cx25840_and_or(client, 0x401, ~0x60, 0x60);
+ cx25840_and_or(client, 0x810, ~0x01, 1);
- if (std & V4L2_STD_525_60) {
+ if (state->radio) {
+ cx25840_write(client, 0x808, 0xf9);
+ cx25840_write(client, 0x80b, 0x00);
+ }
+ else if (std & V4L2_STD_525_60) {
/* Certain Hauppauge PVR150 models have a hardware bug
that causes audio to drop out. For these models the
audio standard must be set explicitly.
@@ -281,11 +399,7 @@
cx25840_write(client, 0x80b, 0x10);
}
- if (cx25840_read(client, 0x803) & 0x10) {
- /* restart audio decoder microcontroller */
- cx25840_and_or(client, 0x803, ~0x10, 0x00);
- cx25840_and_or(client, 0x803, ~0x10, 0x10);
- }
+ cx25840_and_or(client, 0x810, ~0x01, 0);
}
static int set_input(struct i2c_client *client, enum cx25840_video_input
vid_input,
@@ -296,9 +410,22 @@
another odd thing i found so far is the cx25840-firmware.c referances
#define FWFILE_CX23885 "v4l-cx23885-avcore-01.fw"
another firmware (which i have yet to find) and another chipset
and for cx25840-audio.c, nothing again that i would know to note, but for
the register 0x810 the order commands are run have changed, other wise
very simmiler.
if you want any of these diffs, or to download a tarball off the kernel's
diff tree (made a script to build a kernel tree matching the 2 kenels and
diff the files from the 2 and put it in the new tree)
since i know very very little c/c++ im at a loss for what im looking for,
though what i will try for a start, is copy the 23 sources of the cx25840
module and over write the 25 kernel version, not sure if it will work, but
its my best way to isolate where the issue source is, if some one has a
better idea please let me know, i wount be doing this that soon.
Thanks
Kevin
> On Wed, 2008-07-02 at 11:25 -0300, Kevin Blair wrote:
>> Ok correction on modules in usage,
>> with the 2.6.25 kernel and bleeding edge driver the modules used are as
>> fallows:
>> # lsmod
>> Module Size Used by
>> tuner_simple 11600 1
>> tuner_types 13376 1 tuner_simple
>> tda9887 8964 1
>> tda8290 11652 0
>> wm8775 4844 0
>> cx25840 22988 0
>> tuner 21512 0
>> ivtv 115812 0
>> videodev 29248 2 tuner,ivtv
>> v4l1_compat 11844 1 videodev
>> firmware_class 6400 2 cx25840,ivtv
>> compat_ioctl32 896 1 ivtv
>> cx2341x 9476 1 ivtv
>> v4l2_common 8448 5 wm8775,cx25840,tuner,ivtv,cx2341x
>> tveeprom 10436 1 ivtv
>>
>> and on the 2.6.23 kernel with internal modules loaded it lsmod is:
>> # lsmod
>> Module Size Used by
>> wm8775 4684 0
>> cx25840 21712 0
>> ivtv 112080 0
>> firmware_class 6784 2 cx25840,ivtv
>> cx2341x 10052 1 ivtv
>> tveeprom 13456 1 ivtv
>>
>> i was looking on the wrong system and it didnt have the cx25840 module
>> loaded.
>
> Under 2.6.23 you don't have the tuner modules loaded. Without those
> loaded you may not have SIF coming out of the tuner to cause the audio
> microcontroller firmware to try and react to SIF audio changes and
> change audio settings. That could explain why 2.6.23 is not giving you
> problems. Or are your tuner drivers built into the kernel under your
> 2.6.23 configuration (invaliding my above train of thought)?
>
>
>
>> as for the as of 30 min ago, bleeding edge driver the changes did not
>> resolve the tinny audio issue.
>
> I didn't think they would. Sorry if I caused confusion talking about
> how the firmware load of the cx28543 core for the cx18 driver was fixed.
> I am unaware of any modifications being made for the cx28540 driver
> loading firmware.
>
>
> I won't be answering email until at least Monday or Tuesday. Good luck.
>
> Regards,
> Andy
>
>>
>> Kevin
>>
>> Andy Walls wrote:
>> > On Wed, 2008-07-02 at 01:20 -0300, Kevin Blair wrote:
>> >> well i did a simpler test, since i know that with the 2.6.25 kernel
>> >> driver or bleeding edge driver i get the bad audio, and i have moved
>> the
>> >> testing to my slave system which is not dependant on running a 2.6.25
>> >> kernel i backsteped it to a 2.6.23 kernel it was previously running,
>> and
>> >> the ivtv driver from that kernel, and i have not bin able to recreate
>> >> the tinny audio issue(after for going in and out of live tv for over
>> >> half an hour and no issue i dont think it will happen because usually
>> i
>> >> can get the tinny audio in 5 min of testing), the only thing that has
>> >> changed is kernel and ivtv driver, all i did was boot it up on the
>> old
>> >> build of the 2.6.23 kernel which used the old setup on the slave
>> (before
>> >> i built the 2.6.25 kernel and installed the bleeding edge driver) so
>> it
>> >> would appear that something that changed since the 2.6.23 kernel
>> driver
>> >> which is causing this, correct me if im wrong.
>> >
>> > Overall, I cannot say you are wrong, you have found a causal
>> > relationship.
>> >
>> > The question is where is the problem: the ivtv driver, the cx28540
>> > module, the i2c drivers, or the firmware image request process?
>> (Doing
>> > a great big recursive diff of the kernel and driver source code would
>> > show you what's changed, but maybe not easily show what the problem
>> is.)
>> >
>> > It still appears to be audio microcontroller related to me. I am
>> > unaware of anything else that could regularly tries to change the
>> audio
>> > settings in the cx28543 chip (unless a user application is requesting
>> it
>> > - maybe turn on ioctl debugging in ivtv to see). And since resetting
>> > that microcontroller makes the problem go away, it really stands out
>> as
>> > an actor in the problem.
>> >
>> > Hans just made a fix to the firmware download to the AV core in the
>> > CX23418 for the cx18 driver (it has a very similar core and firmware
>> to
>> > the CX28543). He noted that the firmware download had byte errors by
>> > doing read backs of the bytes just written to the chip. If something
>> > changed that introduces byte errors in the download of firmware to the
>> > cx28540, that could obviously cause the audio microcontroller firmware
>> > to act funny.
>> >
>> >
>> > You've found a causal relationship, but the root cause is still
>> unknown.
>> > To find the root cause, I can only think of two methodologies:
>> > inspection and analysis of the differences between the source code
>> > version (likely a big job but it is a deterministic process), or
>> making
>> > some hypotheses and testing those hypotheses (smaller jobs but not
>> > guaranteed to provide an answer).
>> >
>> > Regards,
>> > Andy
>> >
>> >> Kevin
>> >>
>> >> Andy Walls wrote:
>> >>> On Tue, 2008-07-01 at 01:34 -0300, Kevin Blair wrote:
>> >>>> i dont be leave it produced the tinny audio before, but
>> >>>> several things have changed (went from coax to svideo/rca input,
>> >> since i cannot remember for the life of me the detail but the more i
>> >> think about it im sure it was working fine and since on the slave
>> >> downgrading fixes it, so i took a step back looked at the history i
>> >> have, being i had the master system built since the beginning of
>> march
>> >> and did not have any issues with audio but i did have issues with
>> >> sata_mv which i upgraded from a 2.6.24 kernel to a 2.6.25 kernel when
>> it
>> >> became stable at the beginning of may, so for almost 2 months it was
>> >> running fine, based on the time i had it built and running and the
>> time
>> >> i upgraded to the .25 kernel, and few days after i installed the .25
>> >> kernel i was posting on the board with the issue. so it must be one
>> of
>> >> the changes from the 2.6.24 and the 2.6.25 kernel that is causing it.
>> >>
>> >>> Kevin,
>> >>>
>> >>> That is an interesting bit of information. So here's a new
>> hypothesis:
>> >>>
>> >>> The audio micontroller firmware is changing the digital audio
>> baseband
>> >>> processing settings in the CX28543, corrupting the settings for line
>> in
>> >>> audio, when it thinks it detects a TV audio standard change coming
>> in
>> >>> from the tuner SIF audio input.
>> >>>
>> >>> If that is true, then simple solutions could be
>> >>>
>> >>> 1. stop the audio standard detection microcontroller firmware from
>> >>> running when you've switched to an audio input other than the tuner.
>> >>>
>> >>> or
>> >>>
>> >>> 2. connect an RF TV signal source to the tuner and tune the card to
>> an
>> >>> active TV station before making the switch to the svideo or
>> composite
>> >>> input.
>> >>>
>> >>>
>> >>>
>> >>> #2 is something you can try on your own to see if it eliminates the
>> >>> tinny audio.
>> >>>
>> >>> #1 you can try manually by commanding the ivtv driver to switch to
>> the
>> >>> line in input and then stopping the audio microcontroller by setting
>> bit
>> >>> 4 (bit 0 is the lsb, bit 7 is the msb) of register 0x803 of the
>> CX28543
>> >>> to 0 with v4l2-dbg. v4l2-ctl --log-status will then show the audio
>> >>> microcontroller as stopped. When the audio microcontroller is
>> stopped,
>> >>> nothing should be automatically changing the processing of input
>> audio.
>> >>>
>> >>> The problem with doing #1, is that it takes quite a few steps to get
>> the
>> >>> audio microcontroller started properly again, and it's probably not
>> a
>> >>> good idea to try it manually. If you can verify that stopping the
>> audio
>> >>> microcontroller after switching to non-tuner inputs solves the onset
>> of
>> >>> tinny audio, then work can be done on the cx28540 driver to
>> incorporate
>> >>> this solution.
>> >>>
>> >>> Regards,
>> >>> Andy
>> >>>
>> >>>> Kevin
>> >>>
>> >>>
>> >
>>
>
>
_______________________________________________
ivtv-users mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-users
