[wellylug] SAA7134

Ewen McNeill wellylug at ewen.mcneill.gen.nz
Mon May 3 23:31:22 NZST 2004


In message <Pine.LNX.4.58.0405032055050.6541 at localhost>, David Antliff writes:
>On Sun, 2 May 2004, Ewen McNeill wrote:
>> In case anyone's interested, the patch I've sent is enclosed below.
>> To use, simply apply the patch, recompile the module, and then
>> insmod/mopdprobe it with audio_carrier=5500.  If you set audio_debug=1
>> as well, you'll see messages about it skiping the audio scan.
>
>I took a closer look at your patch - it seems the version of the saa7134
>driver in Linux 2.6.5 is already doing something very similar:

My patch is against 2.4.26 patched with the patch-2.4.26-kraxel.gz
(downloaded from http://dl.bytesex.org/patches/2.4.26-1/).

The section that you quote does also appear in the 2.4.26 patch, however
it appears _immediately_after_ the section that the patch applies to (but
for the one word patch -- s/failed/skipped/ -- in one of the messages).
Hence I suspect that the patch should apply against the 2.6.5 code
as well without changes.

The point is that the code you quote is (a) checking if the scan succeeded
(the first test), and (b) if it didn't succeed doing various fallback
options (such as using the parameter passed in, using the last detected
value, using the first value).  Normally, but not always, that gives
you 5.500 MHz (either by scan or through the various defaults), and all
is well.

Sometimes the scan thinks its found carrier but it's got the wrong
value, typically 6.000 MHz in the cases I looked at.  At which point you
get static.  And since the second default is "value detected last time"
you'll keep on getting static until you manage to get a good 5.500 MHz
scan detection, unless you pass in audio_carrier=5500 -- in which case
you'll get the right value every time except the times when the scan
thinks it found carrier at the wrong value.  So it's better (since you
can make the static go away by changing channel usually), but not perfect.

My patch simply skips the scan completely if the value is already known
which (a) saves time (about 5-10 seconds), and (b) avoids the risk of
the scan getting the wrong value.  I wrote it precisely because
situation (b) happened to me a couple of times (and the delay was a
little annoying).  It's rather too late to discover you happened to
get the wrong carrier value on the scan when you go back to listen to 
your recorded program later on...

If you never get an invalid scan result (ie, never detection 6.000 MHz
or 6.500 MHz) then you should be fine.  However having looked at the
code I don't see any way to get static unless you get one of those
values detected.  So I'm assuming that you're seeing the same issue I
was and hence the patch might be useful to you.  YMMV.

Ewen




More information about the wellylug mailing list