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. 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
