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
