On Thu, 2009-09-03 at 15:48 -0500, Chris Kennedy wrote: > 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; > > > > Does it fix the audio for you when putting that a little higher > up where the digitizer is initialized? Like this.... > > if (atomic_read(&itv->capturing) == 0) { > /* Clear all Pending Interrupts */ > ivtv_set_irq_mask(itv, IVTV_IRQ_MASK_CAPTURE); > > clear_bit(IVTV_F_I_EOS, &itv->i_flags); > > /* Initialize Digitizer for Capture */ > v4l2_subdev_call(itv->sd_video, video, s_stream, 0); > ivtv_msleep_timeout(300, 1); > ivtv_vapi(itv, CX2341X_ENC_INITIALIZE_INPUT, 0); > v4l2_subdev_call(itv->sd_video, video, s_stream, 1); > > /* Audio input reset */ > ivtv_audio_set_io(itv); > } > > > Looking at this, it seems it would be more logical to put there (if > it still fixes the issue) because otherwise it would do this each > capture type start up (like when VBI starts or any other types). > I've noticed when resetting the audio input it has a drop in audio > for a half second or so. So this to me would be less intrusive, > just wondering if it works before the capture start command is > given to the firmware and when interrupts are not yet cleared. > > I'm going to try this and see if it prevents my audio from getting > tinny. I'm starting to think this really mostly only happens on > capture start, but may rarely happen in the middle of capturing, so > in that case this wouldn't fix it. In that case the things Andy said > about looking for a possible signaling through interrupt from the > chip would be necessary it seems, otherwise an external script like > I'm using. > > Also what does your tuner setup look like when it gets tinny, > the output of v4l2-ctl -T? I'm really curious if it's always > the same as I see here, or if it can vary, mine is always this... > "Available subchannels: mono lang2" when bad and no lang2 when good.
I recall Sigmund had mentioned his symptoms happen for Line-in audio and FM radio. Although FM comes from the tuner it's at AF, so both are via I2S input, if I'm not mistaken. Regards, Andy > Thanks, > Chris > > 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. > > >> > > >> 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 > _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
