Andy Walls wrote: > 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)? >
the tuner should be loaded, i know it was before because the 23kernel on the slave was setup before i installed sat to tune to cable tv and was never changed, after checking the config, the tuner seems to be built in cat .config | grep TUNER # CONFIG_TUNER_3036 is not set # CONFIG_TUNER_TEA5761 is not set CONFIG_VIDEO_TUNER=y it looks like the ivtv option forces the tuner module to be built and selects it as built in. Kevin > > >> 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
