[ivtv-users] Tinny Audio problem on ivtv 1.0.3

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



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



More information about the ivtv-users mailing list