[ivtv-users] Tinny Audio problem on ivtv 1.0.3

Kevin Blair kaziya at experimental-networks.org
Wed Jul 2 16:25:48 CEST 2008


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.

as for the as of 30 min ago, bleeding edge driver the changes did not 
resolve the tinny audio issue.

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
>>>
>>>
> 



More information about the ivtv-users mailing list