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