While there are some who think a silent TV is perfect, it's rather inconvenient when it happens when you've tried to record something you wanted to see and only find out there's no audio when you choose to watch the recording.
I've been recording the television that I want to watch onto a computer for at the last 6 years, using a frame-buffer-only analogue card (with the Philips SAA7134 chip -- in this case a "shop branded" card, which seems to be a LifeView FlyVIDEO3000 clone). It's worked reliably for years (particularly once I upgraded to a CPU fast enough to encode 25 frames per second in real time), through several operating system upgrades, with just minor tweaks to my recording script (I use a shell script and cron to record programs, since that was close to state of the art when I started -- these days I'd use Myth TV, a well developed Linux PC based video recording system; see the wikipedia page for more detail).
When I upgraded my TV recording box from Debian Etch to Debian Lenny, the TV recording stopped working properly -- with no audio, and I think no video. I found fairly quickly that if I used the Linux kernel from Debian Etch (2.6.24, the "Etch and a Half" kernel then the TV recording would still work, and so I stayed with that solution (just using the older kernel) for several months until I had more time to investigate. More recently I wanted to be able to use some other updated drivers in the newer Linux kernel, and finally made time to dig into the problem.
After a few hours investigation it turns out that there was not one but two issues with the TV recording scripts when run against the Debian Lenny kernel:
The Debian Lenny kernel, and udev, detected an additional audio device (the other TV card I have in the machine, to start doing DVB-T recording) -- which is branded FreeView in New Zealand -- and that meant the scripts were pointing at the wrong audio input.
The index numbers for specifying the TV Norm had changed, so that the index number the script was using which used to mean PAL B/G now referred to a variant of NTSC so the decoding of individual TV frames didn't work and nothing useful was recorded.
The first problem was fixed relatively easily by forcing ALSA, the Linux sound drivers, to allocate a fixed card ID to the SAA7134 audio input -- in this case the card ID that was being automatically chosen with the Debian Lenny kernel, so that it'd (hopefully) be standardised on all the Linux kernels on that machine from now on. To do this put:
alias snd-card-2 saa7134_alsa
options saa7134_alsa index=2
into /etc/modprobe.d/saa7134 (or other suitable file
in /etc/modprobe.d), and either reboot or unload/reload
the SAA7134 related modules. (I rebooted many times during the testing
so I could check that it was working on both old and new kernels.)
To check the settings are working it's very useful to run:
arecord -l
aplay -l
to list the detected devices and their IDs. (The ALSA guide to
multiple cards also has
lots of useful hints.) (It was also necessary to use
alsamixer to make sure that the "Line 1" input was
both turned up, and enabled as the capture port; I tweaked that
part of my recording script to set things appropriately, which
I think also removed my last dependency on OSS, the old Linux sound
system.)
The second problem took a lot longer to find, and I eventually noticed the issue thanks to a forum post about mplayer TV sound pointing the "norm" parameter out. The problem is that in the "Etch and a Half" 2.6.24 kernel the SAA7134 driver provides:
Selected driver: v4l2 name: Video 4 Linux 2 input author: Martin Olschewski comment: first try, more to come ;-) Selected device: LifeView FlyVIDEO3000 Tuner cap: STEREO LANG1 LANG2 Tuner rxs: MONO STEREO Capabilites: video capture video overlay VBI capture device tuner read/write streaming supported norms: 0 = PAL; 1 = PAL-BG; 2 = PAL-I; 3 = PAL-DK; 4 = NTSC; 5 = SECAM; 6 = SECAM-DK; 7 = SECAM-L; 8 = SECAM-Lc; 9 = PAL-M; 10 = PAL-Nc; 11 = PAL-60;
and in the Debian Lenny 2.6.26 kernel the SAA7134 driver provides:
Selected driver: v4l2 name: Video 4 Linux 2 input author: Martin Olschewski comment: first try, more to come ;-) Selected device: LifeView FlyVIDEO3000 Tuner cap: STEREO LANG1 LANG2 Tuner rxs: MONO STEREO LANG1 LANG2 Capabilites: video capture video overlay VBI capture device tuner read/write streaming supported norms: 0 = NTSC; 1 = NTSC-M; 2 = NTSC-M-JP; 3 = NTSC-M-KR; 4 = PAL; 5 = PAL-BG; 6 = PAL-H; 7 = PAL-I; 8 = PAL-DK; 9 = PAL-M; 10 = PAL-N; 11 = PAL-Nc; 12 = PAL-60; 13 = SECAM; 14 = SECAM-B; 15 = SECAM-G; 16 = SECAM-H; 17 = SECAM-DK; 18 = SECAM-L; 19 = SECAM-Lc;
Note how there are many more options just two kernel versions later,
and particularly how the index numbers for them have changed pretty
much completely. Which means that when normid=1 is used
it means "PAL B/G" on the 2.6.24 kernel, and "NTSC-M" on the 2.6.26
kernel, which are completely incompatible. Unfortunately one of the
things I found, at least historically, was that it was necessary to
hard code the exact type of TV signal expected in order that the audio
carrier would be properly detected. And at least historically (to the
best of my recollection) that had to be done via a hard coded number.
Fortunately having found this problem, and the hint mentioned
above, I
discovered that newer versions of the encoding software support a
"norm=PAL-BG" option which allows specifying the
relevant value by name rather than number. And with that change
it now works reliably on both kernels (and hopefully on into the
future). (The Linux TV guide to the
SAA7134 also
suggests choosing the TV norm by name, although they use the generic
class of signal -- NTSC, PAL, etc -- and allow the rest to be
auto-detected, which was what I had problems with early on.)
With both of these items sorted out I now appear to be able to record TV with both the older "Etch and a Half" kernel (2.6.24) and the newer Debian Lenny kernel (2.6.26). Which means I have newer drivers to try with the Hauppauge WinTV-NOVA-T-500 card which has two DVB-T tuners; the Myth TV notes on the Nova-T 500 will hopefully be useful, as should the Linux TV page on the Nova-T 500. From other reports the card appears to work reliably in Linux given reasonable signal strength and the right drivers and options. (In particular the "extra option for Australian users" given at the end of the MythTV page seems to be necessary in New Zealand too.)
And now for something completely different: during my trip to the USA I found a fascinating arcade of electronic amusement machines, all in working order. Recently Metafilter pointed to the Pinball Ninja which is the (photo) blog of a US based person who is attempting to repair 500 amusement machines (mostly pinball) during 2010 -- and document all the repairs with copious marked up photos. For anyone interested in electro-mechanical design, electronics repair, or the sorts of faults one gets in 30 year old hardware it makes for absolutely fascinating reading. The write up of repairs on one of his own machines is a good example, but he's also repaired Ten Pin Bowling Machines, Jurassic Park pinball (multiple times; there are more) and plenty more. The repairs are a range of mechanical fixes (eg cleaning contacts, bending relay contacts back into place) and electrical fixes (eg, burnt out coils, transistors, and other parts), and it's interesting to see that the switch decode matrix is functionally identical to early computer keyboard decoding -- just made out of relays, rather than electronic circuits. The extensive use of DIL chips warms my heart in these days of surface mounted everything.