[ivtv-users] Tinny Audio problem on ivtv 1.0.3

Kevin Blair kaziya at experimental-networks.org
Fri Jul 4 04:38:10 CEST 2008



Andy Walls wrote:
> On Wed, 2008-07-02 at 11:10 -0300, Kevin Blair wrote:
> 
>>> 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
> 
> You can ignore the *.mod.c files; those are autogenerated as part of the
> build process for modules.
> 
> You can probably focus your efforts initially for differences in the
> ivtv, cx25840, i2c-core, and  i2c-algo-bit modules.  Then if nothing
> strike you as really different, expand your search from there.
> 
ok, well for this, ill go with making a second copy of the sources, 
doing a make clean to get rid of all of the modules and files that i 
dont need to look at, then generate a diff source tree to work from.

this may be several days before i have anything useful so i probably 
wount be posting anything till end of next week, unless i come up with a 
  cause to the issues.

Kevin
> 
>>> 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.
> 
> The CX25840, CX25841, CX25842, and CX25843 audio/video digitizer decoder
> chips are all handled by the cx25840 module.  The CX28543 chip can
> handle A/V standards used the world over; the others handle subsets of
> the set of worldwide A/V standards.
> 
> The ivtv driver will load the cx28540 module for PVR cards that have a
> CX2584x chip.  The ivtv driver will also use the i2c-core module and
> usually the i2c-algo-bit module to manipulate the registers of the
> CX25843 via the I2C bus between the CX23416 and the CX25843.
> 
> 
>>> 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.
> 
> These changes only work for the cx18 driver which has a slightly
> different way of manipulating the CX28543 core registers, as on the
> CX23418 based boards, the CX28543 core is integrated into the CX23418
> chip and not a separate chip like on the CX23416 (ivtv) based cards.
> 
> My point was that since it's the same CX28543 chip core and the cx18
> driver had firmware download problems, it's not outside the realm of
> possibility that the firmware load in procedure in the cx28540 module is
> experiencing the same sort of problem, but not correcting the errors.  
> 
> Given your troubleshooting points to a change in the source somewhere
> introduced the symptoms, the firmware load routines in the cx28540
> module are at least one place in the source code where I'm guessing
> things could have changed to cause the problem.  Since that firmware
> load also relies on I2C bus transactions, changes in the i2c modules and
> the i2c routines in the ivtv module would be of interest as well.
> 
> 
> 
> If you can find suspect change sets via source code differences, that'll
> be great.  If you can't, but you can verify that shutting off the
> microcontroller firmware after switching to Line in 1 prevents the tinny
> audio problem, that'll give me enough evidence to "get off the dime" and
> look into modifications to the cx28540 module.  Drivers other than ivtv
> use the cx28540 module, so I wouldn't want to risk breaking something
> without knowing we can fix something.
> 
> 
> Regards,
> Andy
> 
>> 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
>> ivtv-users at ivtvdriver.org
>> http://ivtvdriver.org/mailman/listinfo/ivtv-users
>>
> 
> 
> _______________________________________________
> ivtv-users mailing list
> ivtv-users at ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-users
> 



More information about the ivtv-users mailing list