> OK, here are some simple tests to do: > > I assume that there are two states: audio is OK or audio is tinny. What > I'd like to see is the output of the following commands for each state: > > ivtvctl --log-status > ivtvctl -G > ivtvctl -Z > > I also need to know what you did to switch from one state to another > (ivtvctl -q0 I assume). > > I don't think I've ever had reports about this from PAL/SECAM country, > so for now I assume it is NTSC specific. If anyone from PAL/SECAM has > the same problem, then please report this asap. > > Hans > > On Tuesday 14 March 2006 08:00, John Biundo wrote: >> Hello, >> >> I posted a question on this topic to the user list, but got no >> response. I just noticed that there was a recent thread on the topic >> on this list. I would have replied to that thread, but I just joined >> the list, so that wasn't available. >> >> I wonder if some of the guys chatting on the recent thread might be >> able to answer a few questions. >> >> It was noted that using ivtvctl -q0 sometimes cleared up the problem. >> Someone noted that they use a brute force script to do this every 15 >> seconds or so. This technique doesn't work for me because it >> actually seems to randomly *toggle* the state of the problem. In >> other words, if the problem is NOT occurring, sometimes this command >> will trigger it. So a brute force method may very well turn a "good" >> recording into a "bad" (tinny) one. >> >> Any comments on this? I'm running ivtv 0.4.2, so if there was a >> patch or a change post 0.4.2 required to use this trick, please let >> me know. >> >> On a related note, does anyone know of any way, short of listening to >> the recording, to detect the state of the audio? In other words, >> this problem occurs often (in mythtv) while recording, so I don't >> know the audio is bad until I playback the recording. I'd like to >> devise a script that pokes the ivtvl -q0 *only* if the audio is in a >> bad state. Any clues on whether this is possible and how to do it? >> >> Another issue for me was that this command would also produce a short >> but noticeable pause or interruption in the audio. So running it >> every few seconds produced a very noticeable and irritating periodic >> audio dropout. Is anyone successfully using a brute force script and >> *not* noticing this? >> >> Finally, I wanted to mention that I'm willing to throw some time at >> this if anyone can let me know what kind of data I could provide that >> might help with debugging. I noticed another recent post by Hans V >> that he was planning to investigate this problem, so I hope this post >> is timely, and that I might be able to help provide clues to >> diagnosing the problem. >> >> Thanks in advance. >> >> John >>
Happens to me on PAL on the s-video input (as reported previously in the thread Sun, February 19, 2006 10:09 pm), going to tuner input and then back to s-video fixes it for me in 0.4.2. Not had a chance to put any debug in (too busy for the next 3 weeks) but since 0.4.0 works for me I'm saying with that for the time being. Is this the same problem others are reporting or are they talkig about tuner audio. -- Robin Gilks _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
