When tuning in to a channel either with a tv viewing program or via recording
via mencoder occasionally I receive static for the audio instead of the expected
tv program audio.
Why use my words when someone else can explain it so much better?:D
Needless to say it's incredibly annoying especially when I want to record a tv
show and it comes out as static.
""" I've done some investigation of this, since the static issue was annoying
me (as was the delay for the scan), by insmod'ing with audio_debug=1.
At least for me it seems that the audio carrier scan almost always fails
and falls back to some sort of default (value passed in, value last
detected, or the compile time default (fortunately 5.5 MHz for PAL).
Sometimes the audio carrier scan finds something; it seems about half the
time if finds something it finds 5.5 MHz, and the other half the time it
finds something else (6 MHz or 6.5 MHz). When it finds something else,
you get static. If it finds something else, it'll keep using that until
another scan works (unless you've set a scan-failed default).
Since as David Z says, New Zealand is always using 5.5 MHz, all this
scanning and failing and sometimes getting the wrong results and getting
static is rather a waste of time... """
In terms of getting the audio back to what it should be instead of the static
one had to change channel until it changes back, which can take an awefully
large amount of channel changes at times.
Problem present in default ubuntu warty kernel for i386 and 2.6.10-5-k7 and most
likely every other 2.6.x kernel version.
When tuning in to a channel either with a tv viewing program or via recording
via mencoder occasionally I receive static for the audio instead of the expected
tv program audio.
Why use my words when someone else can explain it so much better?:D
Needless to say it's incredibly annoying especially when I want to record a tv
show and it comes out as static.
""" I've done some investigation of this, since the static issue was annoying
me (as was the delay for the scan), by insmod'ing with audio_debug=1.
At least for me it seems that the audio carrier scan almost always fails
and falls back to some sort of default (value passed in, value last
detected, or the compile time default (fortunately 5.5 MHz for PAL).
Sometimes the audio carrier scan finds something; it seems about half the
time if finds something it finds 5.5 MHz, and the other half the time it
finds something else (6 MHz or 6.5 MHz). When it finds something else,
you get static. If it finds something else, it'll keep using that until
another scan works (unless you've set a scan-failed default).
Since as David Z says, New Zealand is always using 5.5 MHz, all this
scanning and failing and sometimes getting the wrong results and getting
static is rather a waste of time... """
There's much more on the problem here: lists.naos. co.nz/pipermail /wellylug/ 2004-May/ 006632. html
http://
In terms of getting the audio back to what it should be instead of the static
one had to change channel until it changes back, which can take an awefully
large amount of channel changes at times.
Problem present in default ubuntu warty kernel for i386 and 2.6.10-5-k7 and most
likely every other 2.6.x kernel version.