Matt Anderson wrote:
> Is there any way to prevent audio from being played over speaker-out and line-
> out while lavrec is recording? I've tried the -m option, and verbose
> says 'Mute audio output durring recording' yet the sound still comes out over
> speaker-out and line-out (and thus the RCA connectors on the back of the
> Marvel box).
> My goal is to be able to schedule jobs recording in the background (sliently)
> while being able to play other video's (and their respective audio) at the
> same time. Would this require two sound cards, one for recording, the other
> used by everything else for sound output? Or is there something I'm missing?
> I'm using a soundblaster live value with the -U option.
Yes. Use the command:
aumix -S -l 0 -i 34 -l R
just before lavrec to mute any playback of sound coming from the external
line input, while at the same time setting the capture (recording source)
to that same input and setting the record level to a level that prevents
saturation (34 for me, I'd be interested to hear what it is for others).
The above command also saves the previous mixer settings so that they
can be restored after recording by the
command. I find this combination useful becasue recording will not
then leave the mixer in a state in which the sound in the TV app was
muted and the capture source was moved away from the microphone
(which for me needs a capture level of 100).
Sound playback by aviplay etc. uses the "PCM" channel, so the above
mixer settings should not affect this.
Also, if you're interested in scheduling TV recordings, check out
my "tvr" script at http://mrj.bpa.nu/tvr . Two notes on this:
1. I tried the latest version of the EMU10K1 Soundblaster Live
drivers (0.19a vs. 0.18 in Kernel 2.4.18) and found that
-U/--use-read is still needed to prevent one's system from
2. Sometimes the recording fails because of the audio ring buffer
overflow error that a number of other people are getting.
I haven't been able to work out any circumstances that make
the error more likely to happen -- it seems to happen at random
times -- though I don't think it's ever happend with interactive
recording, only with "--batch" recordings. Sometimes the
recording will go for about 10 seconds before it fails, but
usually it fails in less than a second, only leaving a handful
of video frames. Has anyone done some detective work on this?