Linux software audio mixing with FlightGear: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
Line 116: Line 116:




== TeamSpeak ==
== TeamSpeak to use ALSA ==


TeamSpeak works nicely with <code>aoss</code>.
TeamSpeak works nicely with <code>aoss</code>.

Revision as of 00:50, 17 June 2006

This article describes, with a soundcard that does not do hardware mixing, how you can run FlightGear with other audio applications, such as Festival for text-to-speech and running TeamSpeak 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 preload libaoss.so. It *seems* to use dmix 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 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 to use ALSA

TeamSpeak works nicely with aoss.

TeamSpeak works with artsd / artsdsp as well, but there are a few tricks you have to do, and so it's not covered here at the moment.

It does not work with esd / esddsp, because esd does not seem to handle recording properly.

To run TeamSpeak, do:

   aoss TeamSpeak