On Wed, 2009-09-02 at 11:46 +0200, Sigmund Augdal 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)
^^^^
Sample Rate Converter 3 underflowed. See figure 3-38 in the datatsheet.
This is the SRC on the I2S output to the CX23416 chip's I2S input.
If you want a technical background on sample rate converters, I found
Fritz Rothacher (who used to work for Rockwell Semiconductor, now
Conexant), posted his a Ph.D. thesis on Sample rate conversion:
http://www.guest.iis.ee.ethz.ch/~rota/
He also has a patent on effecient sample rate conversion assigned to
Rockwell Semiconductor:
http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.htm&r=1&f=G&l=50&s1=5880980.PN.&OS=PN/5880980&RS=PN/5880980
> +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 is all just speculation, but ...
My gut feeling is that, occasionally, bit banged I2C transactions to set
up the CX25843 registers through the CX23416's I2C master are silently
failing. I suspect lspci -vv will show Master or Target Aborts on the
CX23416 or the PCI bridge that the CX23416 is behind.
This appears to be some sort of sample rate conversion, AUX PLL, or I2S
clock divisor set up problem. I suspect doing the audio setup at a time
when the PCI bridges aren't busy gives a better chance of the registers
being set correctly via bit banged I2C.
A brute force check of that hypothesis would be to do a readback of the
registers that are being written by cx25480_audio_set_path(),
input_change(), and set_audclk_freq() to see if they get set to the
intended values. Maybe you can modify cx25840_write(),
cx25840_write4(), and cx25840_and_or() to automatically do the readbacks
by calling cx25840_read() or cx25840_read4() and log any difference.
It may also be the case that the I2S output was not properly set up in
cx25840_initialize(), if registers 0x918 and 0x919 were not successfully
set due to I2C errors.
Regards,
Andy
> 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
