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.
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
--
Chris Kennedy
[email protected]
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
