Linux software audio mixing with FlightGear
This article describes, with a soundcard that does not do hardware mixing, how you can run FlightGear with Festival for text-to-speech and running TeamSpeak, (and possible any other applications that use audio) at the same time, with ALSA software mixing (the dmix
plugin).
The concept
It is simple. You want to get all the applications to use ALSA dmix
plugin for PCM audio playback. According to ALSA, dmix
plugin is enabled and used by default since ALSA 1.0.9rc2. Though it seems it does not work straight away for everyone.
There are a lot of pages on the net with different customized ALSA configuration (e.g. .asoundrc
) to use "dmix" by default. This article's approach is NOT to touch any ALSA configuration file, but simply per-application setup.
In general, for applications written with ALSA support, usually what you need is to get is to use the device "plug:dmix"
. For example, with the ALSA command line player aplay
, you run:
aplay -D "plug:dmix" test.wav
For applications which does not have ALSA support (i.e. using OSS), you have a few choices:
aoss
- A wrapper script to run any application to use ALSA OSS. This works using simply via
LD_PRELOAD
to preloadlibaoss.so
. It *seems* to usedmix
if available automatically.
esd
- A software audio mixing daemon, typically shipped with GNOME. You can use its wrapper
esddsp
with other applications. You could run:
esd -d plug:dmix
artsd
- Another software audio mixing daemon, typically shipped with KDE. You can use its wrapper
artsdsp
with other applications. You could run:
artsd -d -D plug:dmix
However, not all apps work with all these wrappers. For example, festival does not seem to work properly with aoss
and artsd
. If possible it's a good idea to try all three approaches to get an OSS application to do ALSA.
esd
does not seem to handle recording properly. So if you have an OSS application which does audio recording (say TeamSpeak), esd
/ esddsp
will probably not work.
OSS? ALSA?
So how do you tell whether an application uses OSS or ALSA? There are a few simple ways.
Usually if an application uses the audio device via /dev/dsp
(or /dev/dsp0
, /dev/dsp1
, etc), then it is probably using OSS. With ALSA, you normally specify an audio device using a string, which might look something like "hw:0,0
" or "plug:dmix
", or sometimes "ALSA:default
", depending on the application itself.
ldd
ldd
prints what shared libraries an application depends on.
Take aplay
again as an example, you do:
$ ldd /usr/bin/aplay linux-gate.so.1 => (0xffffe000) libasound.so.2 => /usr/lib/libasound.so.2 (0x40037000) libm.so.6 => /lib/tls/libm.so.6 (0x400f9000) libdl.so.2 => /lib/tls/libdl.so.2 (0x4011f000) libpthread.so.0 => /lib/tls/libpthread.so.0 (0x40123000) libc.so.6 => /lib/tls/libc.so.6 (0x40135000) /lib/ld-linux.so.2 (0x40000000)
Note the libasound.so.2
, which is the ALSA library, which *possibly* means aplay
*CAN* use ALSA. It does not have to, however. It's up to an application to use whatever audio support it wants to use. An example would be applications like mplayer
and xine
, which can do audio playback using many different audio libraries/approaches (OSS, ALSA, ESD, ARTS, and more).
strace
strace
is a rather powerful tool, which traces and prints system calls of a running application.
Take mpg123
as an example, you do:
$ strace -f -e open /usr/bin/mpg123 -q test.mp3 open("/etc/ld.so.cache", O_RDONLY) = 3 open("/lib/tls/libm.so.6", O_RDONLY) = 3 open("/lib/tls/libc.so.6", O_RDONLY) = 3 open("/dev/dsp", O_WRONLY) = 3 open("test.mp3", O_RDONLY) = 3 open("/dev/dsp", O_WRONLY) = 4 open("/dev/dsp", O_WRONLY) = 4
This shows all calls to the system call open()
of this running instance of mpg123
. As you can see it is opening /dev/dsp
, which hints it is using OSS.
For an ALSA application, you will see a lot of open()
calls to devices like /dev/snd/controlC0
, /dev/aloadC2
, /dev/snd/pcmC0D0p
, etc. (Try strace
with aplay
!)
FlightGear to use ALSA
FlightGear uses OpenAL (via SimGear) for audio playback, and OpenAL has ALSA support.
To get OpenAL to use a particular ALSA device, put these in your ~/.openalrc
(define devices '(alsa)) (define alsa-out-device "plug:dmix")
Festival to use ALSA
There are two ways to get Festival to use ALSA.
ESD
Festival supports a couple of audio method for playback, and one of them is ESD support. To have it use ESD by default, put this in your ~/.festivalrc
:
(Parameter.set 'Audio_Method 'esdaudio)
And then run festival
as usual. So:
festival --server
Of course, you'll have to make sure your ESD is running, for example:
esd -d plug:dmix
If for some reasons this does not work, you could always try using esddsp
, which means you would be running:
esddsp festival --server
Using the Audio_Command
parameter
You can configure festival to run another application for playing audio. In this case, we could use aplay
to help us. In your ~/.festivalrc
put:
(Parameter.set 'Audio_Command "aplay -D plug:dmix -q -c 1 -t raw -f s16 -r $SR $FILE") (Parameter.set 'Audio_Method 'Audio_Command)
$SR
is the sampling rate, and $FILE
is the audio data file generated by festival for playback.
TeamSpeak
TeamSpeak works nicely with aoss
. It also works with artsdsp
(so you have to run artsd as well).
It does not work with esd
/ esddsp
, because esd
does not seem to handle recording properly.
To run TeamSpeak, do:
aoss TeamSpeak
or, using artsd, do:
artsd -d -D plug:dmix
where the -d
is to enable full-duplex operations.
Then you run TeamSpeak:
artsdsp TeamSpeak