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.)
i started doing that, i dont know c++ that well so i can only go so far,
but i went through the loaded modules and the diffrences that i found
where minimal the changes of the order of dependant modules, and thats
all i found so far.
like for example
--- linux-2.6.25-gentoo-r2/drivers/media/video/ivtv/ivtv.mod.c
2008-05-20 06:35:14.128780278 -0300
+++ linux-2.6.24-gentoo-r3/drivers/media/video/ivtv/ivtv.mod.c
2008-04-27 14:39:03.817332821 -0300
@@ -15,11 +15,11 @@
};
static const char __module_depends[]
-__used
+__attribute_used__
__attribute__((section(".modinfo"))) =
"depends=cx2341x,videodev,tveeprom,v4l2-common,i2c-core,v4l1-compat,i2c-algo-bit";
MODULE_ALIAS("pci:v00004444d00000803sv*sd*bc*sc*i*");
MODULE_ALIAS("pci:v00004444d00000016sv*sd*bc*sc*i*");
-MODULE_INFO(srcversion, "C4EAC297617EACC9E996BAF");
+MODULE_INFO(srcversion, "ADCB9C3B36B3572E0E4F094");
> 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.
ok now this i need to clarify, ivtv picks loads and uses the cx2341x
module, is the cx28544 handeled by this module or is it a seprate
module(just to confirm) and both bleeding edge loads this aswell as the
2.6.23 kernel version.
>
> 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.
i looked up the changes, the changes may or may not be in the copy of
the bleeding edge driver i downloaded(done the same time frame i
downloaded my copy), maybe he just fixed it ill download a new copy of
bleeding edge and see if it fixes it.
Kevin
> 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
