Saa7134-alsa

How to use alsa or oss with saa7134

Starting with kernel 2.6.15, the module saa7134-alsa lets you use ALSA to get sound directly from your capture card. From 2.6.16 you can use this module with more than one capture card.

In kernel 2.6.16, the saa7134-oss module is also separated out, and the two modules are treated in much the same way; you can build both and switch between them, though both cannot be loaded at once.

Insmod parameters

Now that both alsa and oss DMA sound have been separated out as distinct modules, it is no longer necessary (though it is not forbidden) to include the insmod parameter "alsa=1" or "oss=1".

On the other hand, on the 2.6.16 kernel, it's not safe to use the parameter "disable_ir=1" to turn off the infrared system for the remote -- that caused an oops. This is fixed in 2.6.17.

In the case of more than one card, you can use something like this:

saa7134 card=2,2,2,2 tuner=43,43,43,43 video_nr=1,2,3,4 vbi_nr=1,2,3,4 radio_nr=1,2,3,4 

In dmesg, you should see this type of content murmuring:

input: saa7134 IR (LifeView FlyVIDEO30 as /class/input/input5
tuner 5-0061: chip found @ 0xc2 (saa7133[3])
tuner 5-0061: type set to 43 (Philips NTSC MK3 (FM1236MK3 or FM1236/F))
tuner 5-0063: chip found @ 0xc6 (saa7133[3])
saa7133[3]: i2c eeprom 00: 69 51 38 01 10 28 ff ff ff ff ff ff ff ff ff ff
saa7133[3]: i2c eeprom 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[3]: i2c eeprom 20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[3]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[3]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[3]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[3]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[3]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[3]: registered device video4 [v4l2]
saa7133[3]: registered device vbi4
saa7133[3]: registered device radio4

To then load the new driver that lets you get sound off the PCI bus via ALSA or OSS, you would normally just issue "sudo modprobe saa7134-alsa" or "sudo modprobe saa7134-oss". You can also deliberately assign the enumeration; for instance, for four cards, do this for alsa:

sudo modprobe saa7134-alsa index=1,2,3,4

Again, dmesg approves:

saa7134 ALSA driver for DMA sound loaded
saa7133[0]/alsa: saa7133[0] at 0xf5006000 irq 19 registered as card 1
saa7133[1]/alsa: saa7133[1] at 0xf5007000 irq 20 registered as card 2
saa7133[2]/alsa: saa7133[2] at 0xf5004000 irq 21 registered as card 3
saa7133[3]/alsa: saa7133[3] at 0xf5005000 irq 22 registered as card 4 

If instead you use OSS, issue this to determine enumeration:

sudo modprobe saa7134-oss dsp_nr=1,2,3,4 mixer_nr=1,2,3,4

You should see this in dmesg:

saa7134 OSS driver for DMA sound loaded
saa7133[0]: registered device dsp1
saa7133[0]: registered device mixer1
saa7133[1]: registered device dsp2
saa7133[1]: registered device mixer2
saa7133[2]: registered device dsp3
saa7133[2]: registered device mixer3
saa7133[3]: registered device dsp4
saa7133[3]: registered device mixer4

Note that if you use saa7134-oss in Debian, and build your kernel with ALSA as modules, you may need to add saa7134 to the OSS-module-list to keep your OSS emulation under ALSA (cf. #359851):

echo saa7134 >> /usr/share/linux-sound-base/OSS-module-list

If OSS emulation is not working, some applications (such as VLC) that expect ALSA sound devices won't be able to find the legacy OSS devices created by saa7134-oss.

If your ALSA is built into the kernel rather than as modules, you won't need to worry about this.

Insert modules on boot

To insert the modules with these parameters on boot, you can create a file called /etc/modprobe.d/saa7134 with the following lines (adjust card and tuner numbers as required):

options saa7134 card=2,2,2,2 tuner=43,43,43,43 video_nr=1,2,3,4 vbi_nr=1,2,3,4 radio_nr=1,2,3,4 
install saa7134 /sbin/modprobe --ignore-install saa7134; /sbin/modprobe saa7134-alsa
options saa7134-alsa index=1,2,3,4

Your distribution may require you to put these lines into /etc/modprobe.conf; this is not a good idea in Debian, since the files in /etc/modprobe.d will then be ignored.

If instead you use OSS, these lines will load the modules for four cards:

options saa7134 card=2,2,2,2 tuner=43,43,43,43 video_nr=1,2,3,4 vbi_nr=1,2,3,4 radio_nr=1,2,3,4 
install saa7134 /sbin/modprobe --ignore-install saa7134; /sbin/modprobe saa7134-oss
options saa7134-oss dsp_nr=1,2,3,4 mixer_nr=1,2,3,4

Note that once you've entered this information inside /etc/modprobe.d, your subsequent manual insertions will also make use of this information. Scripts, for instance, need not repeat it.

These instructions are of course specific to kernels 2.6.16 and later, as earlier kernels do not have separate DMA modules.

For kernels before 2.6.16, DMA sound via OSS is activated simply by the insmod parameter "oss=1".

Set permissions

Make sure your users are added to the group "audio" to get access to them -- in Debian, if your user name is "tv", you would use

adduser tv audio

List your capture devices

To get a list of your alsa capture devices, issue

arecord -l

You should see your regular sound card and the capture card(s):

**** List of CAPTURE Hardware Devices ****
card 0: CK8S [NVidia CK8S], device 0: Intel ICH [NVidia CK8S]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: CK8S [NVidia CK8S], device 1: Intel ICH - MIC ADC [NVidia CK8S - MIC ADC]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: SAA7134 [SAA7134], device 0: SAA7134 PCM [SAA7134 PCM]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 2: SAA7134_1 [SAA7134], device 0: SAA7134 PCM [SAA7134 PCM]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 3: SAA7134_2 [SAA7134], device 0: SAA7134 PCM [SAA7134 PCM]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 4: SAA7134_3 [SAA7134], device 0: SAA7134 PCM [SAA7134 PCM]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

Configure the cards to record

Set the cards to record on channel 1 and max volume, using for instance

alsamixergui -c 1

for each of the cards.

Watch with mplayer

You should now be ready to watch live tv with mplayer, using something like this:

These are for rf connections:

US broadcast or satellite:

mplayer tv://$channel -tv driver=v4l2:device=/dev/video0:chanlist=us-bcast:alsa:\
adevice=hw.1,0:amode=1:audiorate=32000:forceaudio:volume=100:immediatemode=0:norm=NTSC

If you're using a satellite box, $channel should probably be set to 3 or 4. If that doesn't work, try the US cable TV setup below. If you're getting your broadcast off the air, you can run the scantv utility to detect stations and set $channel to the local channel for your area.

US cable:

mplayer tv://"insert channel" -tv driver=v4l2:device=/dev/video0:chanlist=us-cable:alsa:\
adevice=hw.1,0:amode=1:audiorate=32000:forceaudio:volume=100:immediatemode=0:norm=NTSC

Here again you can run the scantv utility to detect the channels available from your provider, or you can use your provider's channel table.

Europe cable:

mplayer tv://"insert channel" -tv driver=v4l2:device=/dev/video0:chanlist=europe-west:alsa:\
adevice=hw.1,0:amode=1:audiorate=32000:forceaudio:volume=100:immediatemode=0:norm=PAL

Note the norm= and chanlist= parameters. Adjust as required for your location.

If "adevice=hw.1,0" doesn't work, try simply "adevice=hw.1". Some tuners require "adevice=hw.2" -- for instance, on a board with nforce 3 250/gb chipsets. If others experiance this with other boards, please update.

Record with mencoder

It may be simpler to get sound during recording than during playback. I get good sound using this, where $DEV is the number of the device node:

mencoder -tv driver=v4l2:device=/dev/video$DEV:fps=30000/1001:chanlist=us-bcast:\
audiorate=32000:alsa:adevice=hw.$DEV:input=0:amode=1:normid=4:width=576:height=432 \
-ovc x264 -x264encopts threads=2:bitrate=500:bframes=2:subq=1:me=1:frameref=4:8x8dct \
-oac mp3lame -lameopts cbr:br=64 -endpos $TIM -o $DIR/$FIL.avi tv:// > /dev/null

So the alsa device is simply called hw.1 -- not hw.1,0. The line is taken from the channel script. You may find you need to use hw.2 instead, depending on the audio hardware on your system.

Neither ffmpeg nor transcode as yet have ALSA support.

Because so many applications still appear to have difficulties accessing ALSA's odd device enumeration, the OSS module for DMA sound continues to be useful. You can also use ALSA's OSS emulation with saa7134-alsa to get /dev/dspX devices for OSS-aware applications.

ALSA audio with other applications

To hear the audio through ALSA using tvtime (or other programs that don't support it directly), run the following command after starting tvtime:

arecord -D hw:1,0 -r 32000 -c 2 -f S16_LE | aplay -

It basically records at 32kHz Stereo from the SAA7134 ALSA source (hw:1,0 or change accordingly), and plays it through your default ALSA output. Look at the options from aplay to change your output.

There might be a delay between the video and the audio. To avoid it, specify a device for aplay (not the 'default' device):

arecord -D hw:1,0 -r 32000 -c 2 -f S16_LE | aplay -D surround41

In order to get full surround sound from the stereo TV audio output, edit your /etc/asound.conf or ~/.asoundrc file as described in ALSA FAQ028 (http://alsa.opensrc.org/FAQ028) and use this device:

arecord -D hw:1,0 -r 32000 -c 2 -f S16_LE | aplay -D ch51dup

I don't know how to use ALSA directly with xawtv, motv, kdtv, tvtime, or zapping; if you do, please add it in here!

If using arecord still causes a delay between the video and the audio, try using sox:

sox -r 32000 -w -t alsa hw:1,0 -t alsa hw:0,0

Recent versions of sox no longer accept "-w" option, so just omit it. You can also use "--buffer" option to improve A/V synchronization, as the default 8KB buffer causes audio to lag significantly. On my system 2KB buffer is optimal:

sox --buffer 2048 -r 32000 -t alsa hw:1,0 -t alsa hw:0,0

Sox might get you mono sound, while all the alsa solutions cause delays. A combination has been known to work:

arecord -D hw:1,0 -r 32000 -c 2 -f S16_LE | sox -q -c 2 -r 32000 -w -t wav - -t alsa hw:0,0

If sox doesn't have alsa support, you can try this instead:

arecord -D hw:1,0 -r 32000 -c 2 -f S16_LE | play -q -c 2 -r 32000 -w -t wav -

Alternatively you can use alsa's oss-emulation with sox, which seems to result in way better latency then all the above:

sox -q -c 2 -s -w -r 32000 -t ossdsp /dev/dsp1 -t ossdsp -w -r 32000 /dev/dsp