[ivtv-users] Tinny Audio problem on ivtv 1.0.3

Andy Walls awalls at radix.net
Tue Jul 1 03:00:10 CEST 2008


On Sun, 2008-06-29 at 23:57 -0300, Kevin Blair wrote:
> Humm, well ill look into  adjusting the latency on the pci bus though i
> have played with that before with no luck but i have little to know how
> on doing that,

Since you may have a mix of PCI and PCIe devices things are a little
different than what I know for sure.  So going with what I know for a
straight PCI bus here's the general concept:

The latency timer lets the card know how many PCI bus cycles it is
allowed to stay on the PCI bus at any one time when it is acting as bus
master.  Aside from 1 to 3 overhead cycles of the clock cycles in a PCI
bus transfer, 32 bits can be transferred in each PCI bus cycle.  The PCI
bus runs at 33 MHz (usually) or 30.3 nanoseconds per cycle.

If a device isn't allowed enough bus cycles in it's latency timer, then
it can't transfer useful amounts of data when it gets granted the bus.
If a device gets a lot of bus cycles granted in its latency timer, then
it can hog the bus and starve off other devices that need to do
transfers.  So setting latency timers is a balancing act between
individual device needs and the needs of all devices in the system that
could possibly be working in parallel.

The device manufactures store recommendations is the PCI config data
known as MIN_GRANT, the minimum latency timer value in units of 8 bus
cycles (nominally 250 ns but actually 242.4 ns), and MAX_LAT the maximum
time, in units of 8 bus cycles, that the device can tolerate between
consecutive transfers when the device has more data to transfer than can
be handled in one cycle.  Note that on my PVR-150, Hauppauge has seemed
to have accidentally swapped the values for MIN_GNT and MAX_LAT.


>  but to rule out both kernel/driver/firmware conflict and
> to check and make sure that the drives stop failing(dont want to lose
> data no matter what the cause is), i disable ivtv in the master myth
> system so if a drive fails again it has nothing to do with ivtv,

Eliminating variables is always a good troubleshooting technique.


>  and
> update the system in the slave to the same kernel and ivtv version on
> the master and enable the tuner (i have had it disabled while trying to
> work this out on the master first) i found that with the same driver
> version and kernel version i get the same audio issue (only hardware
> that is simmiler is the tuner) so i tryed the register setting
> # v4l2-dbg -r type=i2cdrv,chip=cx25840,reg=0x810,val=1
> register 0x810 set to 0x1
> # v4l2-dbg -r type=i2cdrv,chip=cx25840,reg=0x810,val=0
> register 0x810 set to 0x0
> and it does fix the audio like set audio trick, i cant find any older
> version for the audio chipset

You are beholden to a firmware bug then.  There's not much to be done to
prevent the problem from occurring (unless you feel like reverse
engineering 8051 microcontroller code that manipulates undocumented ASIC
hardware).

If you search for older or newer Hauppauge Windows drivers for the
PVR-150 and PVR-500 you may find different Mako firmware versions.

>From various driver upgrades for my PVR-150, I happen to have these
lying around:

-rw-r--r-- 1 root root  14264 2005-04-20 10:56 HcwMakoB.ROM-060418.2.0.43.24108
-rw-r--r-- 1 root root  11628 2006-10-27 16:35 HcwMakoC.ROM-050728.2.0.34.23209
-rw-r--r-- 1 root root  12282 2005-06-30 18:33 HcwMakoC.ROM-050915.2.0.35.23258
-r--r--r-- 1 root root  16382 2006-02-09 11:54 HcwMakoC.ROM-060418.2.0.43.24108


>  and the older version of the encoder
> chipset that i can find does not work. so that does not work,

Since the soft reset of the CX28543 fixed the problem, the encoder isn't
to blame anyway.


>  and for
> the other suggestions im not sure where to start on those.

For suggestion 3 of forcing the TV audio standard there is already code
in

linux/drivers/media/video/cx25840/cx25840-core.c:input_change() 

and

linux/drivers/media/video/ivtv/ivtv-driver.c:ivtv_process_eeprom()

for forcing the audio standard for some NTSC boards to BTSC. Look for
the variable pvr150_workaround.  You may be able to add your tuner model
to the switch statement in ivtv-driver.c:ivtv_process_eeprom() to see if
that works to solve your problem.

Regards,
Andy

> on the note on the drives its a driver issue, i couldn't even initially
> build the array from the live cd till i built an install with the 2.6.25
> kernel, i have lots of cooling, and a 1000w power supply(planned for
> large power demand) as for bus and latency i have no idea where to start
> there but if i can identify that as an issue and i cant resolve it ill
> need to move to a hardware raid pcie controller
> 
> 
> Kevin
> 
> Andy Walls wrote:
> > On Sat, 2008-06-28 at 19:18 -0300, Kevin Blair wrote:
> >> ok ill give that a try, though i think i may have another direction that
> >> could be the issue, i had a suspicion but since i had a very similar
> >> issue with out ivtv affecting things i didnt think so, but due to the
> >> failure i just had and recovered from, i am suspecting it may be!
> >>
> >> i noticed a point on one of the ivtv posts about ivtv and sata drives,
> >> now over all i have had little issue and nothing directly relating to
> >> that post so i didnt think it was related, but i have a raid5 array with
> >> 4 drives setup, and i have bin having an intermittent issue of one of
> >> the drives fails out (SDC) and goes non responcive, and i had an issue
> >> building the array (same issue) when building the array with an older
> >> kernel driver, but with the newer 2.6.25 kernel i dont have the building
> >> issue but every so often the drive fails and my raid array goes
> >> degraded, not a big deal and not that often, reboot remove and add drive
> >> and it rebuilds and it works fine, but now i have the "temp
> >> set-audio-input fix" i had enabled, dissabled for testing and i didnt
> >> enable it again, and there was a recording starting the same time the
> >> drives failed, and not just one went out but 3 out of the 4 went out,
> >> but since they simply went offline and not bad, i was able to recover
> >> with no data lost, any chance that it could be an incompatibly with the
> >> sata_mv libata driver for the chipset:
> >> 00:0e.0 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3)
> >> 00:0e.1 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3)
> >> 00:0e.2 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3)
> >> and ivtv causeing both my drives to fail out and ivtvs bad audio?
> > 
> > PCI bus load for disk I/O and an ivtv capture simultaneously could cause
> > an error on the PCI bus that adversely affects disk operations.
> > 
> > Using lspci, you should review your PCI bus latency settings against
> > each card's MIN_GRANT (minimum desired latency timer setting) and
> > MAX_LAT (maximum interval the device should be held off the bus), and
> > thus the overall throughput of the shared PCI bus that each device wants
> > when most active.  You should also look for Parity Errors, System
> > Errors, and Master and Slave aborts on the PCI bus as these can indicate
> > problems.
> > 
> > 
> > ivtv bad audio would be independent of disk problems though.  Here's a
> > simple block diagram of how broadcast TV audio moves through a PVR-150:
> > 
> > 
> > Antenna --> Tuner ---> CX25843 -----> CX23416 ----> PCI Bus ---> Memory
> >         RF        SIF          I2S(?)         MPEG          MPEG
> > 
> > 
> > The the tinny audio is likely happening inside the CX25843, when the
> > microcontroller firmware program inside modifies how it demodulates
> > analog Sound Intermediate Frequency (SIF), probably because the firmware
> > audio standard autodetection routines may have a bug.  There is also a
> > chance that the CX23416 is doing something wrong with the digital I2S
> > serial audio stream, but this also would be a firmware bug.
> > 
> > Audio digitization, demodulation, filtering, and encoding is well
> > removed from the PCI bus.  If you've commanded an MPEG capture and the
> > audio starts out OK, no PCI bus error is going to change that audio to
> > sound differently (tinny) unless you're actively trying to command the
> > ivtv board to change it's audio related processing.
> > 
> > 
> > 
> > 
> >> attached is the syslog file of the errors outputed pertaining to the
> >> drive failures if its of any use to see if this is the issue, also all
> >> the drives have bin checked to see that they are good drives, and sdc
> >> has bin replaced with a good offline spare i had last time i had a
> >> failure to rule out bad drives.
> > 
> > I cannot really comment on your drives or mobo chipset without a lot
> > more research.  Suffice to say, make sure power and cooling are up to
> > the job.
> > 
> > Since the PCI bus is a shared resource (although PCIe legs aren't), an
> > analysis of PCI bus timing and typical demand by your devices will let
> > you know your potential for PCI bus bottlenecks.  Doing raid in software
> > to individual SATA controllers (as opposed to a hardware RAID
> > controller) is going to chew up a bit of PCI bus bandwidth during disk
> > access, I'd imagine.  Throwing video capture on the shared PCI bus on
> > top of software RAID will stress things further during disk access.
> > 
> > Just my $0.02.
> > 
> > Regards,
> > Andy
> > 
> >> Thank you so much for any help if this is the cause of both of my issues.
> >>
> >> Kevin
> >>
> >>
> >> Andy Walls wrote:
> >>> On Thu, 2008-06-26 at 10:41 -0300, kaziya at experimental-networks.org
> >>> wrote:
> >>>> ok, here is the debug reports, i did the fallowing, i got the system to be
> >>>> producining the bad audio
> >>>> and generated the log status file, and a debug file, then i used the
> >>>> set-audio-input switch which
> >>>> brought the audio to being normal, and generated another set of logs and
> >>>> debug logs
> >>>> since this is little difference in the log status i am only posting the
> >>>> diff of the 2, as for the debugs
> >>>> im not sure what you need so im posting the full log of both and a diff.
> >>> I've looked at the diff's.  Some comments are in line below.  Basically
> >>> the significant differences are in the audio decoder register block of
> >>> the cx28543.  Unfortunately most of the differences are in
> >>> undocumented/reserved register regions.
> >>>
> >>> The ones in the AC'97 audio codec register region very likely don't
> >>> matter as ivtv and PVR-150's don't use this interface.
> >>>
> >>> The undocumented registers in the range 0x880-0x89f being different tell
> >>> me the audio micrcontroller is doing something differently in the two
> >>> cases, but that may or may not be the cause of the tinny audio.
> >>>
> >>>
> >>>> please let me know if you need any more information thanks for the help.
> >>> The next time you get tinny audio, could you use v4l2-dbg to set
> >>> register 0x810 to 1 and then back to 0.  This toggles the SOFT_RESET of
> >>> the audio microcontroller, and should get it to try and redetect the
> >>> audio standard.  (IIRC the driver does this as one of the steps when
> >>> switching inputs.)  If that fixes things, you will have then verified
> >>> that the audio microcontroller firmware in the cx25843 is getting
> >>> confused.
> >>>
> >>>
> >>> If that is the case you have some courses of action which are limited
> >>> because the firmware source is not available:
> >>>
> >>> 1. Experiment with different versions of the Mako (cx2854x) firmware to
> >>> see if there is one that doesn't produce the tinny audio problem. 
> >>>
> >>> 2. Try to reliably detect tinny audio from within a program polling the
> >>> ivtv driver, and when you detect the tinny audio condition, run a
> >>> utility to reset the audio microcontroller or take some other corrective
> >>> action.
> >>>
> >>> 3. Since you know the TV standards you normally capture, limit the
> >>> auto-detection of audio standard to the one you capture.  I don't think
> >>> v4l2-ctl supports this right now, and the driver may not currently
> >>> easily support anything other than autodetection of audio standard.
> >>> (I'd need to do more research on this.)
> >>>
> >>>
> >>> [snip]
> >>>> Diff of the 2
> >>>> -----------------------Start-----------------------------
> >>>> --- ivtv.good.dbg       2008-06-25 21:52:06.659558323 -0300
> >>>> +++ ivtv.bad.dbg        2008-06-25 21:51:19.185396931 -0300
> >>>> @@ -6,7 +6,7 @@
> >>>>            00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
> >>>>  00000100: 33 84 00 d0 00 dc 04 07 0f 04 0a 18 fe e2 2b 00
> >>>>  00000110: e5 d6 98 00 00 8c 07 00 02 00 00 00 00 00 00 00
> >>>> -00000120: 00 00 01 10 87 b6 30 50 f8 93 11 a0 ff 5f 20 11
> >>>> +00000120: 00 00 01 10 87 b6 b0 50 f8 93 11 a0 ff 5f 20 11
> >>>                                ^^
> >>> This may not matter: GPIO0 was 0 for good, 1 for bad
> >>>
> >>>>  00000130: 00 00 00 00 02 18 0a 00 00 00 00 00 00 00 36 00
> >>>>  00000140: 04 f0 00 00 10 32 54 76 00 00 00 00 00 00 00 00
> >>>>  00000150: 00 00 00 00 00 00 00 00 00 e1 86 10 00 e1 86 06
> >>>> @@ -18,7 +18,7 @@
> >>>>  00000230: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >>>>
> >>>>            00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
> >>>> -00000400: 01 e2 04 00 2e 25 10 00 00 80 00 00 00 91 7d 00
> >>>> +00000400: 01 e2 04 00 2e 25 10 00 00 80 00 00 00 81 7d 00
> >>>                                                     ^^
> >>> This doesn't matter: Video field was odd (good) vs. even (bad)
> >>>
> >>>>  00000410: bf 07 ff 7f 00 7e 00 00 00 00 08 00 00 00 08 00
> >>>>  00000420: 7e 7e 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >>>>  00000430: 00 00 00 00 00 00 00 00 00 00 00 00 06 00 f0 ff
> >>>> @@ -26,7 +26,7 @@
> >>>>  00000450: 01 00 00 03 0d c4 08 26 77 88 00 54 00 00 00 00
> >>>>  00000460: 02 14 0a 34 6e ca 36 06 e7 00 00 08 20 f6 84 02
> >>>>  00000470: 7a 00 2d 5b 1a 70 1e 1a 1f 02 50 66 1f 7c 08 00
> >>>> -00000480: db 02 00 00 00 00 60 42 1a 32 06 f8 dc 40 10 00
> >>>> +00000480: b0 03 00 00 00 00 60 42 1a 2f 06 f8 dc 40 10 00
> >>>              ^^^^^                      ^^^^^
> >>> Vid Field count doesn't matter   Vid AGC value probably doesn't matter
> >>>        
> >>>>  00000490: 8a 02 3f cd 00 03 1f 16 22 00 00 00 14 00 50 14
> >>>>  000004a0: 0f 02 1c 00 00 00 00 00 00 00 00 00 00 00 00 00
> >>>>  000004b0: 00 00 00 00 03 00 00 00 01 00 00 00 00 00 00 00
> >>>> @@ -40,8 +40,8 @@
> >>>>  00000850: 55 5f a1 00 30 00 00 00 00 00 00 00 3e 70 00 80
> >>>>  00000860: b8 01 ca 00 00 00 00 01 00 00 00 00 00 00 00 00
> >>>>  00000870: 00 00 00 00 00 00 00 00 7e 05 7e 05 88 45 a2 06
> >>>> -00000880: da 07 3c 0b e1 ca 03 40 30 70 30 70 bd 01 65 00
> >>>> +00000880: da 07 3c 0b e1 ca 03 40 30 70 30 70 da 01 64 00
> >>>                                                  ^^    ^^
> >>> Internal/reserved audio microcontroller registers differ
> >>>
> >>>> -00000890: 24 f4 03 40 30 70 30 70 85 0c 21 02 4f 01 ba 04
> >>>> +00000890: 24 f4 03 40 30 70 30 70 d3 0c 00 01 5b 01 16 05
> >>>                                      ^^    ^^^^^^^^    ^^^^^
> >>> Internal/reserved audio microcontroller registers differ
> >>>
> >>>>  000008a0: 78 06 d6 12 87 51 00 00 de 53 03 00 b1 01 00 00
> >>>>  000008b0: d0 f3 00 00 00 00 00 00 c8 00 ff 0f 1f 00 0f 00
> >>>>  000008c0: 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 0f
> >>>> @@ -53,9 +53,9 @@
> >>>>  00000920: 00 48 3d f5 05 05 00 00 00 00 00 00 00 00 00 00
> >>>>  00000930: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >>>>  00000940: 00 00 00 00 00 00 00 00 00 2e 3f 4a 00 33 64 ff
> >>>> -00000950: 10 00 00 ff 03 10 40 07 00 08 02 ff 00 00 00 00
> >>>> +00000950: 00 00 00 ff 03 10 40 07 00 08 02 ff 00 00 00 00
> >>>              ^^
> >>> This probably doesn't matter: internal AC'97 codec register differs
> >>>
> >>>>  00000960: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >>>>  00000970: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >>>>  00000980: 00 00 00 00 00 00 00 00 00 3f 00 3f 00 3f 00 3f
> >>>>  00000990: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >>>> -000009a0: 00 00 00 00 00 00 00 00 01 00 00 00 12 00 00 80
> >>>> +000009a0: 00 00 00 00 00 00 00 00 01 00 00 00 0e 00 00 80
> >>>                                                  ^^
> >>> This probably doesn't matter: internal AC'97 codec register differs
> >>>> -------------------------END------------------------------
> >>>
> >>> Regards,
> >>> Andy
> >>>
> > 
> 
> 
> _______________________________________________
> ivtv-users mailing list
> ivtv-users at ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-users
> 




More information about the ivtv-users mailing list