On Wed, Sep 02, 2009 at 01:43:28PM +0200, Sigmund Augdal wrote: > On Wed, Sep 2, 2009 at 11:46 AM, Sigmund Augdal <[email protected]> wrote: > > > Hi, > > > > I'm throwing in my comments here as this discussion seems relevant for my > > problem. I too experience a tinny audio problem with my PVR-150 card. I've > > seen this both with FM audio and line in. The problem is that the audio > > becomes distorted when I start a new capture about 15% of the time. It > > sounds like there is a high pitched or white noice on top of the ordinary > > audio signal. This remains there until I run v4l2-ctl --set-audio-input 1 > > (or 0 in case I'm using FM tuner). I spent most of yesterday digging into > > this problem and I'd like to share my findings in case they could be > > helpful, or in case someone has any comments on them. > > > > * Firstly I've noticed that at the beginning of almost every capture there > > is a very short glitch in the audio (about one second). When the audio works > > fine this distortion goes away as said after about a second, when the audio > > goes to the bad state the sound gets gradually worse for 3-4 seconds then > > stays bad until --set-audio-input 1 is called. Running --set-audio-input > > before the situation is stable does not seem to work (not very thoroughly > > tested though). The amount of noise in the stable error condition changes a > > bit from time to time. > > > > * Some experimentation shows that it is the last function call in > > ivtv_audio_set_io that makes the problem go away: > > ivtv_call_hw(itv, itv->card->hw_audio, audio, s_routing, input, output, 0); > > As I understand it this maps to cx25480_s_audio_routing. I've had little > > luck figuring out which part of this function (and the stuff it calls) > > actually fixes the problem, because disabling parts of it tends to return in > > no audio whatsoever. > > > > * I tried changing the driver so that ivtv_audio_set_io is called each time > > a capture is started (by disabling the check for unchanged input in > > ivtv_s_input), however this does not seem to solve the problem > > > > * Looking at the audio registers using v4l2-dbg I found some interresting > > differences: > > --- registers-ok2 2009-09-01 16:25:59.774303146 +0200 > > +++ registers-fail 2009-09-01 16:23:47.232906508 +0200 > > @@ -64,8 +64,8 @@ > > Register 0x000008ef = 7fh (127d 01111111b) > > Register 0x000008f0 = fch (252d 11111100b) > > Register 0x000008f1 = ah (10d 00001010b) > > -Register 0x000008f2 = 0h (0d 00000000b) > > -Register 0x000008f3 = 88h (136d 10001000b) > > +Register 0x000008f2 = 50h (80d 01010000b) > > +Register 0x000008f3 = 99h (153d 10011001b) > > Register 0x000008f4 = 88h (136d 10001000b) > > Register 0x000008f5 = 88h (136d 10001000b) > > Register 0x000008f6 = 55h (85d 01010101b) > > > > I am not able to comprehend what these registers are about from the > > datasheet, but they seem to indicate some fifo over/underflow. Writing 0xff > > to these registers resets them to the value they have in the OK state, but > > it does not affect the problem. My gutfeeling say it could be related to > > enabling audio output from the cx25843 before enabling reception in the ivtv > > chip and that some timing issue makes sure it only some times actually > > overflows the fifo. > > > > This simple change seems to remove the problem for me. I still don't know > exactly what the problem is or why this fix works, but it seems to work for > me. It is basically just an automated way of doing the manual workaround. > > diff -r 7c23abfe445f linux/drivers/media/video/ivtv/ivtv-streams.c > --- a/linux/drivers/media/video/ivtv/ivtv-streams.c Mon Aug 31 02:03:28 2009 > -0300 > +++ b/linux/drivers/media/video/ivtv/ivtv-streams.c Wed Sep 02 13:33:58 2009 > +0200 > @@ -42,6 +42,7 @@ > #include "ivtv-yuv.h" > #include "ivtv-cards.h" > #include "ivtv-streams.h" > +#include "ivtv-routing.h" > > static const struct v4l2_file_operations ivtv_v4l2_enc_fops = { > .owner = THIS_MODULE, > @@ -599,6 +600,7 @@ > else > ivtv_clear_irq_mask(itv, IVTV_IRQ_MASK_CAPTURE); > > + ivtv_audio_set_io(itv); > /* you're live! sit back and await interrupts :) */ > atomic_inc(&itv->capturing); > return 0; > > Best regards > > Sigmund Augdal > > > > > > > > Best regards > > > > Sigmund Augdal > > > > > > On Sun, Aug 30, 2009 at 4:30 AM, Andy Walls <[email protected]> wrote: > > > >> On Sat, 2009-08-29 at 20:39 -0500, Chris Kennedy wrote: > >> > >> > I'm wondering too if it's signal dependent, could be something in the > >> > signal triggers this behavior, perhaps my signal changed recently and > >> > the new kernel was coincedental. Also I have seen it twice in a month > >> > on 4 interfaces, I only really look at one interface daily of those, > >> > so it in theory could have happened before and I just never was lucky > >> > enough to catch it. I did go for 4+ months though before without > >> > seeing it, so seems like it did change with the kernel change, but also > >> > the machine changed too (although it's an exact duplicate) so again it > >> > could be some signal thing or even hardware/cards that are slightly > >> > different. > >> > >> Well the "tinny audio" problem - and this looks like it - is almost > >> certainly signal dependent. > >> > >> We don't really muck with the audio registers once tuned to a channel. > >> The audio microcontroller is the only control program modifying the > >> non-publicly documented audio related registers. In my mind, a change > >> in the broadcast signal (between programs, or program/commerical > >> boundary?) has to be causing it to readjust. Sometimes that > >> readjustment is not right apparently. > >> > >> The questions to answer really are: > >> > >> 1. How do we automatically detect the condition before the audio is > >> badly affected? > >> > >> 2. What to do about it, when we detect it? > >> > >> > >> The answer to #2 is pretty straightforward in my mind: reset the audio > >> microcontroller. That's what your '--set-audio-input=0' essentially > >> does. Perhaps there may need to be an extra step of waiting for the > >> "video present" status to show up, but the corrective action is still > >> the same. > >> > >> The answer to #1 is probably hard. It may be easier to assume that > >> whenever the audio microcontroller detects an audio format or mode > >> change on its own (not initiated by the linux driver), we should check > >> and take some corrective or preventative action. > >> > >> > >> All that might not be an option, if the IRQ_N of the CX25843 isn't wired > >> up. > >> > >> > >> Let me know if you find a pattern in the errant condition.
I had this happen again tonight, upon a capture start it seems that the audio was bad. So I got snapshots of the registers when I know it was bad, and after I fixed it, all manually. So these register captures may be more helpful then the last ones since I had turned off my fix script. Thanks, Chris > >> > >> Regards, > >> Andy > >> > >> > >> > >> _______________________________________________ > >> ivtv-devel mailing list > >> [email protected] > >> http://ivtvdriver.org/mailman/listinfo/ivtv-devel > >> > > > > > _______________________________________________ > ivtv-devel mailing list > [email protected] > http://ivtvdriver.org/mailman/listinfo/ivtv-devel -- Chris Kennedy [email protected]
bad_audio_regs.bz2
Description: Binary data
good_audio_regs.bz2
Description: Binary data
_______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
