FlightGear wiki - User contributions [en]

Howto:Multiplayer

2008-08-03T13:29:20Z

Pigeon: /* Using fgfs from the command line */

= Using the Windows launcher / fgrun =
Select your [[aircraft]] and starting airport as normal. On the next screen, tick the "Multiplayer" box. Also tick the "AI models" box or you will not be able to see the other pilots' aircraft. Enter the callsign of your choice, enter mpserver01.flightgear.org in the "Hostname" box and 5000 into both the "in" and "out" boxes. Click run and you'll soon be flying with other pilots!

To confirm that it's working, you can go to the multiplayer map at; http://mpmap02.flightgear.org/ (in Hong Kong).
You will also notice chat messages that say "Hello" indicating pilots that are online and then as they join.
[[Image:Multiplayer.jpg|thumb|300px|Multiplayer options in [[FlightGear Wizard|FG Launcher]]]]
You may wish to use a different server (i.e. "Hostname" entry);

mpserver01.flightgear.org (in Germany)
mpserver02.flightgear.org (in Hong Kong) [T]
mpserver03.flightgear.org (in Germany) [T]
mpserver04.flightgear.org (UK)
mpserver06.flightgear.org (Sweden)

Servers marked with [T] above log all flights in the [http://fgfs.i-net.hu/modules/fgtracker/ FlighGear flight tracker].

'''Please Note:''' The multiplayer servers are interconnected; you '''do not''' need to connect to a specific server in order to see other pilots who are on that server. For best performance, you should connect to the server that is geographically closest to you or has the lowest latency (ping time).
[[Image:MP_Server.jpg|thumb|300px]]

= Multiplayer Chat =

To chat with other pilots, go to the "View" menu and select "Chat" at the bottom of the menu. Note that the other pilots may not have their chat box open, so they may not see your messages.
NOTE: Multiplayer chat is not supported by FlightGear 0.9.10 or older.

= Using fgfs from the command line =

First, for those who are very impatient and have a vague idea about what they're doing, the basic arguments to pass to fgfs for multiplayer are these;

--multiplay=out,10,server.ip.address,portnumber
--multiplay=in,10,your.ip.address,portnumber
--callsign=anything

Where portnumber is usually 5000 and your.ip.address is the ip address of the network interface being used by FG to connect to the server - even if that's a local 192.168 type address. Please note that although this limitation has been removed in the most recent versions of the FG server; you should still specify a valid (non-loopback, i.e. not 127.0.0.1) IP address to keep the FG client happy.

With the latest FlightGear (at least with OSG), you can also leave your.ip.address blank. FlightGear will then listen on all network interfaces:

--multiplay=in,10,,5000

== Now, going more slowly for those who are completely lost... ==

Try the above first, and if it doesn't work, read on.

First of all, you need to know the IP address of the network interface you'll be using for multiplayer FG. If your Internet connection is via an ADSL modem that plugs directly into your computer with a USB connection, you should be able to find your IP address by visiting http://www.whatismyip.com . Please note that your ISP might not give you the same IP address each time - if MP stops working, check this first.

Otherwise, your connection is likely via some kind of router that connects to your computer via an RJ-45, or "Ethernet" connector (similar shape to most Western telephone plugs), or by a wireless link. You need to find the IP address of that network interface.

Under linux, this can be found by logging in as root and typing "ifconfig". You may find more than one interface listed, beginning with "lo" - ignore that one. You should have something like "eth0" or "wlan0" also listed - look through this block of text for "inet addr". This will be followed directly by the number you're looking for, e.g. "inet addr:192.168.0.150"

Under Windows XP, click start, run, and type "cmd". In the terminal window which appears, type "ipconfig" This should show you your IP address - write it down.

With Windows 98, click start, run, and type "winipcfg" to get information about your IP address.

This section _ought_ to be unnecessary now with recent versions of the FG server. If you have problems though, it won't hurt to follow through.

Now, all(!) that remains is to configure your router to forward UDP port 5000 to the IP address you've just found. This is not something that can be described in step-by-step detail, because each manufacturer's configuration interfaces differ greatly. Some tips are given here - if you get stuck, ask nicely on the [irc://irc.flightgear.org/flightgear FlightGear IRC channel] for help (details on the flightgear website).

You should know how to log on to your router's configuration page, usually via a web browser. You are looking for settings pertaining to "port forwarding" "virtual server" "Forwarding Rules" or similar. When you have found the relevant settings, you need to add a rule that forwards port 5000 to the IP address you discovered earlier. If there is a choice given, ensure it is UDP ports that are forwarded. If there is no choice, you may assume that both TCP and UDP are being forwarded. Save your configuration, and most routers will probably then need to be rebooted to apply the changes.

Note: (for BSD users) If you are using a ADSL modem, you might have to put the port forward command into the ppp.conf file rather than firewall. This is because the firewall script will only run each time the machine is booted rather than the ppp line coming back online.

Finally, start FG using the command line given right at the start (if you're using the windows launcher you will find entry boxes for Multiplayer arguments - insert the relevant details there). You will end up with something like this;

fgfs --callsign=MyName --multiplay=in,10,192.168.0.2,5000 --multiplay=out,10,mpserver02.flightgear.org,5000 --airport=KSFO --runway=28R --aircraft=hunter

Choose your own callsign - this is currently limited to seven characters. 

Once you have started FG, you should, if others are flying, see messages in the terminal from which FG was started, similar to the following;

Initialising john51a using 'Aircraft/ufo/Models/ufo.xml'
FGMultiplayRxMgr::ProcessRxData - Add new player. IP: 10.0.0.36,
Call: john51a,model: Aircraft/ufo/Models/ufo.xml

You MUST give your local, behind-the-router IP address for MultiPlayer to work. Trust me on this one!

You should check that your firewall is not causing problems - either turn it off _temporarily_ or add an exception to allow incoming connections on port 5000.

If it's still just not working for you, ask nicely on the [irc://irc.flightgear.org/flightgear FlightGear IRC channel] and someone should be able to assist.
Multiplayer Map
There is a very nice online map which displays the location of online pilots at http://mpmap02.flightgear.org . You will also find this useful to check that you are successfully connecting to the server.

THE FLIGHTGEAR MULTIPLAYER ROUGH HOWTO

2006-05-27

[[Category:Howto|Multiplayer]]

Howto:Multiplayer

2007-01-16T10:56:37Z

Pigeon: /* Using the Windows launcher / fgrun */

= Using the Windows launcher / fgrun =

Select your aircraft and starting airport as normal. On the next screen, tick the "Multiplayer" box, enter a callsign of your choice, enter mpserver01.flightgear.org in the "Hostname" box and 5000 into both the "in" and "out" boxes. Click run and you're hopefully sorted!

To confirm that it's working, you can go to:
http://mpmap01.flightgear.org/ (in Germany) or http://mpmap02.flightgear.org/ (in Hong Kong) and use the multiplayer map there.

You may wish to use a different server (i.e. "Hostname" entry); currently available are:

mpserver01.flightgear.org (in Germany)

mpserver02.flightgear.org (in Hong Kong)

mpserver03.flightgear.org (East Coast USA)

mpserver04.flightgear.org (UK)

mpserver05.flightgear.org (Portsmouth, UK)

= Using fgfs from the command line =

First, for those who are very impatient and have a vague idea about what they're doing, the basic arguments to pass to fgfs for multiplayer are these;

--multiplay=out,10,server.ip.address,portnumber
--multiplay=in,10,your.ip.address,portnumber
--callsign=anything

Where portnumber is usually 5000 or 5002 and your.ip.address is the ip address of the network interface being used by FG to connect to the server - even if that's a local 192.168 type address. Please note that although this limitation has been removed in the most recent versions of the FG server; you should still specify a valid (non-loopback, i.e. not 127.0.0.1) IP address to keep the FG client happy.

Port 5000 is usually for the latest stable version of FlightGear. Currently 0.9.10

Port 5002 is mainly used for development, i.e. stable version of FlightGear might or might not work with this server, depending on the server's development stage.

== Now, going more slowly for those who are completely lost... ==

Try the above first, and if it doesn't work, read on.

First of all, you need to know the IP address of the network interface you're going to be running FG multiplayer over. If your Internet connection is via an ADSL modem that plugs directly into your computer with a USB connection, you should be able to find your IP address by visiting http://www.whatismyip.com . Please note that this address may very well change every now and again - if MP stops working, check this first.

Otherwise, your connection is likely via some kind of router that connects to your computer via an RJ-45, or "Ethernet" connector (similar shape to most Western telephone plugs), or by a wireless link. You need to find the IP address of that network interface.

Under linux, this can be found by logging in as root and typing "ifconfig". You may find more than one interface listed, beginning with "lo" - ignore that one. You should have something like "eth0" or "wlan0" also listed - look through this block of text for "inet addr". This will be followed directly by the number you're looking for, e.g. "inet addr:192.168.0.150"

Under Windows XP, click start, run, and type "cmd". In the terminal window which appears, type "ipconfig" This should show you your IP address - note it down.

With Windows 98, click start, run, and type "winipcfg" to get information about your IP address.

This section _ought_ to be unnecessary now with recent versions of the FG server. If you have problems though, it won't hurt to follow through.

Now, all(!) that remains is to configure your router to forward UDP port 5000 or 5002 to the IP address you've just found. This is not something that can be described in step-by-step detail, because each manufacturer's configuration interfaces differ greatly. Some tips are given here - if you get stuck, ask nicely on the FlightGear IRC channel for help (details on the flightgear website).

You should know how to log on to your router's configuration page, usually via a web browser. You are looking for settings pertaining to "port forwarding" "virtual server" "Forwarding Rules" or similar. When you have found the relevant settings, you need to add a rule that forwards port 5000 or 5002 (depending on which server you wish to join - add both if you like) to the IP address you discovered earlier. If there is a choice given, ensure it is UDP ports that are forwarded. If there is no choice, you may assume that both TCP and UDP are being forwarded. Save your configuration, and most routers will probably then need to be rebooted to apply the changes.

Note: (for BSD users) If you are using a ADSL modem, you might have to put the port forward command into the ppp.conf file rather than firewall. This is because the firewall script will only run each time the machine is booted rather than the ppp line coming back online.

Finally, start FG using the command line given right at the start (if you're using the windows launcher you will find entry boxes for Multiplayer arguments - insert the relevant details there). You will end up with something like this;

fgfs --callsign=MyName --multiplay=in,10,192.168.0.2,5000 --multiplay=out,10,mpserver02.flightgear.org,5000 --airport=KSFO --runway=28R --aircraft=hunter

Choose your own callsign - this is currently limited to seven characters. 
NOTE: Windows users also might have to add the option --enable-ai-models on their command line in order to see other multiplayer aircraft(or in fgrun, check the box that says "AI Models")

Once you have started FG, you should, if others are flying, see messages in the terminal from which FG was started, similar to the following;

Initialising john51a using 'Aircraft/ufo/Models/ufo.xml'
FGMultiplayRxMgr::ProcessRxData - Add new player. IP: 10.0.0.36,
Call: john51a,model: Aircraft/ufo/Models/ufo.xml

You MUST give your local, behind-the-router IP address for MultiPlayer to work. Trust me on this one!

You should check that your firewall is not causing problems - either turn it off _temporarily_ or add an exception to allow incoming connections on port 5000 and 5002.

If it's still just not working for you, ask nicely on the FlightGear IRC channel and someone should be able to assist.
Multiplayer Map
There is a very nice online map which displays the location of online pilots at http://mpmap01.flightgear.org . You will also find this useful to check that you are successfully connecting to the server.

THE FLIGHTGEAR MULTIPLAYER ROUGH HOWTO

2006-05-27

Linux software audio mixing with FlightGear

2006-12-26T10:19:11Z

Pigeon:

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 (<code>dmix</code> and <code>dsnoop</code> plugin).

== Quick start ==

* [[#FlightGear|Getting FlightGear to use ALSA, esd (Gnome), or arts (KDE)]].
* [[#Festival|Getting Festival to use ALSA]].
* [[#TeamSpeak|Getting TeamSpeak to use ALSA]].

== Audio mixing what? ==

One of the most common issues with soundcard and Linux is when you can only have one application playing sound at a time on some systems. This happens when the soundcard itself does not do audio mixing (i.e. hardware mixing).

Audio mixing allows multiple audio (PCM) streams to be "mixed" together and to be played at the same time. It is generally better and more efficient for a soundcard, if available, to do audio mixing in the hardware.

Software audio mixing is useful when you have a soundcard not capable of doing hardware mixing. Under Linux, software mixing can be done by ALSA's <code>dmix</code> / <code>dsnoop</code> plugin, or by userspace applications, like ESD and ARTS. Software uses your CPU to do the work and mixes multiple audio streams into one, before passing the audio data onto your soundcard for playback.

On Windows, software mixing is enabled by default transparently. Because of this, most people would have no idea about the capability of their sound cards in the Windows world. This is debatable whether this is good or bad, and is out of scope of this article.

With ALSA, an easy to test whether your soundcard supports hardware mixing or not would be running this following twice, say in two different terminals:

<pre>
$ aplay -D hw:0,0 test.wav
</pre>

This tells <code>aplay</code>, the ALSA audio player, to play the file <code>test.wav</code> using the first sound hardware directly, without using any plugin or any software mixing. For a soundcard without hardware mixing support, the second <code>aplay</code> would fail, and might look like this:

<pre>
$ aplay -D hw:0,0 test.wav
aplay: main:547: audio open error: Device or resource busy
</pre>

You could also find out from ALSA's driver info, by doing:

<pre>
$ cat /proc/asound/pcm
00-00: Intel ICH : Intel 82801DB-ICH4 : playback 1 : capture 1
00-01: Intel ICH - MIC ADC : Intel 82801DB-ICH4 - MIC ADC : capture 1
00-02: Intel ICH - MIC2 ADC : Intel 82801DB-ICH4 - MIC2 ADC : capture 1
00-03: Intel ICH - ADC2 : Intel 82801DB-ICH4 - ADC2 : capture 1
00-04: Intel ICH - IEC958 : Intel 82801DB-ICH4 - IEC958 : playback 1
01-00: Intel ICH - Modem : Intel 82801DB-ICH4 Modem - Modem : playback 1 : capture 1
</pre>

Notice the first line, "<code>playback 1</code>", indicating the device only supports one PCM audio playback at any time.

With a soundcard that supports hardware audio mixing, the same check looks like this:

<pre>
$ cat /proc/asound/pcm
00-00: emu10k1 : EMU10K1 : playback 32 : capture 1
00-01: emu10k1 mic : EMU10K1 MIC : capture 1
00-02: emu10k1 efx : EMU10K1 EFX : playback 8 : capture 1
</pre>

As you can see, the first line suggests this device supports 32 simultaneous PCM audio playback.

== Prerequisites ==

This article assumes you have a basic understanding and knowledge of Linux. For instance:

* <code>~/</code> refers to your HOME directory. If your user name is <code>blah</code>, then <code>~/</code> normally would be <code>/home/blah/</code>. And so <code>~/.asoundrc</code> would mean <code>/home/blah/.asoundrc</code>

* Files with names starting with a dot (".") are normally considered as hidden files. If you're using some sort of file manager application, remember to turn on or enable showing these hidden files.

* If a "dot rc" file (e.g. <code>.asoundrc</code>, <code>.openalrc</code>) does not exist, simply creates it.

This article assumes you have ALSA setup and working with your soundcard(s).

== The concept ==

It is simple. You want to get all the applications to use the ALSA <code>dmix</code> plugin for PCM audio playback, and sometimes also the <code>dsnoop</code> plugin for audio recording.

According to ALSA, <code>dmix</code> 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. <code>.asoundrc</code>) 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 <code>"plug:dmix"</code>. For example, with the ALSA command line player <code>aplay</code>, you run:

<pre>
$ aplay -D "plug:dmix" test.wav
</pre>

It's a good idea to run this to test if your <code>dmix</code> works.

For applications which does not have ALSA support (i.e. using OSS), you have a few choices:

; <code>aoss</code> : A wrapper script to run any application to use ALSA OSS. This works using simply via <code>LD_PRELOAD</code> to preload <code>libaoss.so</code>. It *seems* to use <code>dmix</code> if available automatically.

; <code>esd</code> : A software audio mixing daemon, typically shipped with GNOME. You can use its wrapper <code>esddsp</code> with other applications. You could run:
<pre>
$ esd -d plug:dmix
</pre>

; <code>artsd</code> : Another software audio mixing daemon, typically shipped with KDE. You can use its wrapper <code>artsdsp</code> with other applications. You could run:
<pre>
$ artsd -D plug:dmix
</pre>

However, not all apps work with all these wrappers. For example, festival does not seem to work properly with <code>aoss</code> and <code>artsd</code>. If possible it's a good idea to try all three approaches to get an OSS application to do ALSA.

<code>esd</code> does not seem to handle recording properly. So if you have an OSS application which does audio recording (say TeamSpeak), <code>esd</code> / <code>esddsp</code> 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 <code>/dev/dsp</code> (or <code>/dev/dsp0</code>, <code>/dev/dsp1</code>, etc), then it is probably using OSS. With ALSA, you normally specify an audio device using a string, which might look something like "<code>hw:0,0</code>" or "<code>plug:dmix</code>", or sometimes "<code>ALSA:default</code>", depending on the application itself.

=== <code>ldd</code> ===

<code>ldd</code> prints what shared libraries an application depends on.

Take <code>aplay</code> again as an example, you do:

<pre>
$ 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)
</pre>

Note the <code>libasound.so.2</code>, which is the ALSA library, which *possibly* means <code>aplay</code> *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 <code>mplayer</code> and <code>xine</code>, which can do audio playback using many different audio libraries/approaches (OSS, ALSA, ESD, ARTS, and more).

=== <code>strace</code> ===

<code>strace</code> is a rather powerful tool, which traces and prints system calls of a running application.

Take <code>mpg123</code> as an example, you do:

<pre>
$ 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
</pre>

This shows all calls to the system call <code>open()</code> of this running instance of <code>mpg123</code>. As you can see it is opening <code>/dev/dsp</code>, which hints it is using OSS.

For an ALSA application, you will see a lot of <code>open()</code> calls to devices like <code>/dev/snd/controlC0</code>, <code>/dev/aloadC2</code>, <code>/dev/snd/pcmC0D0p</code>, etc. (Try <code>strace</code> with <code>aplay</code>!)

== FlightGear ==

FlightGear uses OpenAL (via SimGear) for audio playback, and OpenAL supports ALSA, ESD and ARTS. However you have to make sure your OpenAL is built with the audio support you need. Run <code>configure --help</code> if you are building your own OpenAL.

To get OpenAL to use a particular ALSA device, put these in your <code>~/.openalrc</code>

<pre>
(define devices '(alsa))
(define alsa-out-device "plug:dmix")
</pre>

To get OpenAL to use ESD:

<pre>
(define devices '(esd))
</pre>

And to get OpenAL to use ARTS:

<pre>
(define devices '(arts))
</pre>

== Festival ==

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 <code>~/.festivalrc</code>:

<pre>
(Parameter.set 'Audio_Method 'esdaudio)
</pre>

And then run <code>festival</code> as usual. So:

<pre>
$ festival --server
</pre>

Of course, you'll have to make sure your ESD is running, for example:

<pre>
$ esd -d plug:dmix
</pre>

If for some reasons this does not work, you could always try using <code>esddsp</code>, which means you would be running:

<pre>
$ esddsp festival --server
</pre>

Test your festival server by:

<pre>
$ echo '(SayText "Hello")' | festival_client
</pre>

=== Using the <code>Audio_Command</code> parameter ===

You can configure festival to run another application for playing audio. In this case, we could use <code>aplay</code> to help us. In your <code>~/.festivalrc</code> put:

<pre>
(Parameter.set 'Audio_Command "aplay -D plug:dmix -q -c 1 -t raw -f s16 -r $SR $FILE")
(Parameter.set 'Audio_Method 'Audio_Command)
</pre>

<code>$SR</code> is the sampling rate, and <code>$FILE</code> is the audio data file generated by festival for playback.

== TeamSpeak ==

TeamSpeak works with <code>aoss</code> and <code>artsd</code> / <code>artsdsp</code>. It does not work with <code>esd</code> / <code>esddsp</code>, because <code>esd</code> does not seem to handle recording properly.

=== <code>aoss</code> ===

To run TeamSpeak, do:

<pre>
$ aoss TeamSpeak
</pre>

=== <code>arts</code> ===

You have to run <code>artsd</code> with <code>-d</code>, enabling full-duplex. So:

<pre>
$ artsd -d -D plug:duplex
</pre>

You'll need this [[ #~/.asoundrc ]] as well.

Then you have you run TeamSpeak.bin, instead of TeamSpeak, because <code>artsdsp</code> can only handle binary. You will also need to have LD_LIBRARY_PATH set to where TeamSpeak is installed. For example, if you have TeamSpeak installed at /opt/TeamSpeak/, then you should run:

<pre>
$ LD_LIBRARY_PATH=/opt/TeamSpeak artsdsp /opt/TeamSpeak.bin
</pre>

== ~/.asoundrc ==

Usually you shouldn't need a custom ALSA configuration. But just in case, here is a simple <code>~/.asoundrc</code> to get you started:

<pre>
pcm.duplex {
type asym
playback.pcm "dmix"
capture.pcm "dsnoop"
}

pcm.!default {
type plug
slave.pcm "duplex"
}
</pre>

This is the same as specifying "<code>plug:duplex</code>" as the audio device for all applications, for instance:

<pre>
$ aplay -D plug:duplex test.wav

$ arecord -D plug:duplex test.wav

$ esd -d plug:duplex

$ artsd -d -D plug:duplex
</pre>

So with this configuration, you do not have to specify which ALSA device applications should use. As long as the application uses ALSA, it will be using the <code>dmix</code> and <code>dsnoop</code> plugins.

With FlightGear/OpenAL, however, I'm not sure what the issue is, but you may still need to specify <code>alsa-out-device</code> in the <code>~/.openalrc</code>, which is:

<pre>
(define devices '(alsa))
(define alsa-out-device "plug:duplex")
</pre>

== GNOME and KDE ==

If you're using GNOME or KDE, you will probably have <code>esd</code> or <code>artsd</code> running already. In this case, you may also want to try this [[ #~/.asoundrc ]], which set <code>dmix</code> and <code>dsnoop</code> as the default to use for ALSA. You need to restart <code>esd</code> or <code>artsd</code> after making changes to <code>~/.asoundrc</code>. Make sure your <code>esd</code> or <code>artsd</code> is using ALSA, too.

(TODO: Anyone who uses GNOME or KDE could add more descriptions here, thanks)

== When things don't work ==

* Try this [[ #~/.asoundrc ]]

* <code>aoss</code> honours your ALSA configurations, and hence your <code>~/.asoundrc</code>. You want to make sure it is correct. Use <code>aplay</code> and <code>arecord</code> to test your setup.

* Any other thing to try is to temporarily rename or move away your <code>~/.asoundrc</code>, and then test everything again.

* See http://gentoo-wiki.com/HOWTO_ALSA_sound_mixer_aka_dmix (even if you're not using Gentoo). It's a pretty detailed HOWTO with ALSA audio including <code>dmix</code> and <code>dsnoop</code> configurations.

OpenSceneGraph

2006-11-16T23:21:24Z

Pigeon: /* Current Issues */

== Getting a patched version of OpenSceneGraph ==

Thanks to Mathias Fröhlich, we can use an updated OpenSceneGraph version that
contains 3 additional patches.
* most important an updated ac3d loader - that is our most used one ...
* a fix to the RGB Loader
* a small backport of OpenSceneGraph-CVS doing the right OpenGL version checks ...
OpenSceneGraph-CVS it now up to date with the required patches and should serve as well for running FlightGear. Please note that the "Producer" build system is currently in the works, you probably want to check out with the "-D 20061113" tag.

You can find that tarball at:
ftp://ftp.uni-duisburg.de/FlightGear/Misc_maf/OpenSceneGraph-20061114/OSG_OP_OT-1.2-Flightgear.tar.gz

Diff can be found at:
ftp://ftp.uni-duisburg.de/FlightGear/Misc_maf/OpenSceneGraph-20061114/OSG_OP_OT-1.2-Flightgear.diff

Mathias is working on getting the remaining patch upstream ...

And the MSVC8 win32 build dependencies for OpenSceneGraph can be found at http://www.oflebbe.de/oflebbe/FlightGear. Look out for the link to 3rdParty.zip.

If you get errors when compiling the patched OpenSceneGraph after having compiled (and installed) OpenThreads and Producer successfully (happens on Arch Linux), you may have to add the following to your 'make':

'''make PRODUCER_INC_DIR=/usr/local/include/Producer \'''
'''PRODUCER_LIB_DIR=/usr/local/lib \'''
'''OPENTHREADS_INC_DIR=/usr/local/include/OpenThreads \'''
'''OPENTHREADS_LIB_DIR=/usr/local/lib'''

== Compilation workaround ==

FIXME

Do not forget to run autogen.sh when updating sources.

=== Installing FlightGear and OSG with --prefix workaround ===

If you use --prefix to choose were to install FlightGear and do not want to install OSG globally on the system this can be done with the following method
(description for Linux):

1. Build OpenScenGraph. I do it directly in the OSG source directory without installing anything (when the next version comes I can just delete the old directory without any worries). Adjust as needed:
export OSG_BASE=$HOME/FlightGear/build/OpenSceneGraph/OSG_OP_OT-1.2-Flightgear
export OPENTHREADS_INC_DIR=$OSG_BASE/OpenThreads/include
export OPENTHREADS_LIB_DIR=$OSG_BASE/OpenThreads/lib/Linux32
export PRODUCER_INC_DIR=$OSG_BASE/Producer/include
export PRODUCER_LIB_DIR=$OSG_BASE/Producer/lib/Linux32
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$OPENTHREADS_LIB_DIR:$PRODUCER_LIB_DIR

cd OpenThreads; make
cd ../Producer; make
cd ../OpenScenGraph; make

2. Copy or (soft)link OpenThreads/include/OpenThreads into your $PREFIX/include/ directory.

3. Copy or (soft)link Producer/include/Producer into your $PREFIX/include/ directory.

4. Copy or (soft)link OpenSceneGraph/include/osg* into your $PREFIX/include/ directory.

5. Copy or (soft)link OpenThreads/lib/<system>/lib*.so into your $PREFIX/lib/ directory.

6. Copy or (soft)link Producer/lib/<system>/lib*.so into your $PREFIX/lib/ directory.

7. Copy or (soft)link OpenSceneGraph/lib/<system>/lib*.so into your $PREFIX/lib/ directory.

8. Add $PREFIX/lib to LD_LIBRARY_PATH.
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$PREFIX/lib

9. Configure and build SimGear and FlightGear with --prefix as usual.

No need to install any quickly changing software globally.

Installing with --prefix is a very nice way to keep several distinct and independent versions of FlightGear around. To start a new $PREFIX directory you'll also need to install plib in it, but that is easy. Most other needed dependencies are usually available through the package system of most Linux distributions (e.g. FreeGLUT, SDL, ALSA, etc).

FIXME: Maybe it is enough to copy only the OpenSceneGraph/include/osg* and OpenSceneGraph/lib/<system>/lib*.so stuff into $PREFIX?

== Current Issues ==

* OSG Rendering Performance is roughly up to a factor of 2 slower for some scenes. This seems to have more dramatic on the Windows MVC8 build. Rendering ist faster now...

* some buildings are with day texture, and other with night texture. i'm landing onto Paris center and, with the external view, i rotate around the aircraft. the sun position is not fixed at the same time, left side of aircraft is on shadow, with another camera position, it's the right side. that can explain why some building are day textured, and some others night textured

* Some scenes do not work: The view is black. The default scene c172p on KSFO is working, however. It seems to be a terrain/ground problem since it disappears by using the UFO. This is fixed now by the ground-cache fix in CVS (061107)'''

* There are also missing ground tiles: For instance located between EDDF and Feldberg.

* Rendering order of instruments / ... is wrong.

* At least at the present season with "--timeofday=noon", sitting at KSFO 28R, I look straight into the moon with FlightGear/PLIB, but the moon isn't there with FG/OSG

* In the external view(s) the HUD position is shifted to the left

* transparency issues:
** runway lights shine through panel:
** runway lights shine through cloud layers in an awkward way:
** 2D-cloud layers flood into cockpit
** The prop of the C172 block the view on the waves of the carrier
** The reflector gun sight on the Seahawk causes other transparent objects (carrier wake etc.) to disappear
** A new overhead window in the C172 (inside out)

* "Near clipping problem" (nearby objects are partially clipped at left and right window boarder, ie seats in C172 inside)

* Some textures are to dark, runway for instance, c172 prop disk as well.

* Runway lighting seems to have rendering artefacts on ATI Cards.

* Enhanced runway lighting option in the drop-down menu seems to have no effect - light always appear enhanced.

* compass working incorrectly

* panel hotspots are not correctly displayed in 3D panels using the 2D hotspot hack; are hidden behind 3D model geometry

* Aircraft issues
** Hurricane/Spitfire/Seafire won't start. The starter spins continuously, but the engine won't fire.

'''Fixed: 061110'''
'''Spoke too soon - not fixed - the bug is intermittent'''

With the Spit/Seafire I get

Notice: Material::getDiffuse(FRONT_AND_BACK) called on material
with separate FRONT and BACK diffuse colors.

and a segfault;

** A4F crashes FG, without any error message that I have found so far. ('''FIXED''' a4/Models/a4-blue.ac 1.18 groups are not supposed to have vertices)
** Hunter and Seahawk have lost their exhausts (of course).
** The Engage Launch-bar command (L) is broken.
** The Mixture control (M/m) seems to be broken.

* Seneca II HSI: upper instrument clipping issue for NAV/HDG flags, heading bug, pointer

* Sky/Ephemeris
** Planets visible near the sun at noon

* Clickable Hotspots
** Not visible at night

* 3D cockpit instruments (I tried C172p's and 747's) seems to be scaled depending on the size of the window. This is most obvious when I change the FOV to its max (120) using the 'X' key. E.g. when I resize FG's window so that its width is much larger than its height (say, 1024x100), instruments all become a fat oval shape. Then if I resize the window the other way (say 100x910), instruments become narrower. Screenshots: [http://pigeond.net/~pigeon/fg-osg-fat-window.png] [http://pigeond.net/~pigeon/fg-osg-thin-window.png] (20061117 pigeon)

[[List of 'compatible' aircrafts]] TO BE CONTINUED

== Missing Features ==

* 3D-billboard objects are not displayed right now (ie trees or radio masts)

* 3D clouds

* Rendering of some scenes is not perfect.

* Shadows

* Exhaust shader

* Chrome Shader

* Weather Radar

* Menu Items have no effect
** Enhanced Runway Lights
** Bump Mapped Clouds

== Miscelaneous OSG benefits ==

Mathias: "I think that we should make use in the longer term of the Producers
capabilities for multiple view installations.
But not only multipipe installs will benefit from that. The Producer will also
help to get benefit from multicore SMP machines.
For that the following article is of huge interrest:
http://www.donburns.net/OSG/Articles/OSGMP/"

== Getting the PLIB Code ==

Use the tag <tt>PRE_OSG_PLIB_20061029</tt> for checking out the branch with the plib scenegraph.

For SimGear, this works (more or less) as follows:

'''cvs -d :pserver:cvsguest@cvs.simgear.org:/var/cvs/SimGear-0.3 login'''
'''CVS passwd: guest'''
'''cvs -d :pserver:cvsguest@cvs.simgear.org:/var/cvs/SimGear-0.3 co source'''
'''cd source'''
'''cvs up -rPRE_OSG_PLIB_20061029'''

For FlightGear, you have to update both the "data" and "source" directories.

OpenSceneGraph

2006-11-11T22:29:48Z

Pigeon: /* Current Issues */

OpenSceneGraph

2006-11-11T22:27:23Z

Pigeon: /* Current Issues */

OpenSceneGraph

2006-11-11T05:05:48Z

Pigeon: /* Current Issues */

Linux software audio mixing with FlightGear

2006-07-01T05:46:10Z

Pigeon:

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 (<code>dmix</code> and <code>dsnoop</code> plugin).

== Audio mixing what? ==

One of the most common issues with soundcard and Linux is when you can only have one application playing sound at a time on some systems. This happens when the soundcard itself does not do audio mixing (i.e. hardware mixing).

Audio mixing allows multiple audio (PCM) streams to be "mixed" together and to be played at the same time. It is generally better and more efficient for a soundcard, if available, to do audio mixing in the hardware.

Software audio mixing is useful when you have a soundcard not capable of doing hardware mixing. Under Linux, software mixing can be done by ALSA's <code>dmix</code> / <code>dsnoop</code> plugin, or by userspace applications, like ESD and ARTS. Software uses your CPU to do the work and mixes multiple audio streams into one, before passing the audio data onto your soundcard for playback.

On Windows, software mixing is enabled by default transparently. Because of this, most people would have no idea about the capability of their sound cards in the Windows world. This is debatable whether this is good or bad, and is out of scope of this article.

With ALSA, an easy to test whether your soundcard supports hardware mixing or not would be running this following twice, say in two different terminals:

<pre>
$ aplay -D hw:0,0 test.wav
</pre>

This tells <code>aplay</code>, the ALSA audio player, to play the file <code>test.wav</code> using the first sound hardware directly, without using any plugin or any software mixing. For a soundcard without hardware mixing support, the second <code>aplay</code> would fail, and might look like this:

<pre>
$ aplay -D hw:0,0 test.wav
aplay: main:547: audio open error: Device or resource busy
</pre>

You could also find out from ALSA's driver info, by doing:

<pre>
$ cat /proc/asound/pcm
00-00: Intel ICH : Intel 82801DB-ICH4 : playback 1 : capture 1
00-01: Intel ICH - MIC ADC : Intel 82801DB-ICH4 - MIC ADC : capture 1
00-02: Intel ICH - MIC2 ADC : Intel 82801DB-ICH4 - MIC2 ADC : capture 1
00-03: Intel ICH - ADC2 : Intel 82801DB-ICH4 - ADC2 : capture 1
00-04: Intel ICH - IEC958 : Intel 82801DB-ICH4 - IEC958 : playback 1
01-00: Intel ICH - Modem : Intel 82801DB-ICH4 Modem - Modem : playback 1 : capture 1
</pre>

Notice the first line, "<code>playback 1</code>", indicating the device only supports one PCM audio playback at any time.

With a soundcard that supports hardware audio mixing, the same check looks like this:

<pre>
$ cat /proc/asound/pcm
00-00: emu10k1 : EMU10K1 : playback 32 : capture 1
00-01: emu10k1 mic : EMU10K1 MIC : capture 1
00-02: emu10k1 efx : EMU10K1 EFX : playback 8 : capture 1
</pre>

As you can see, the first line suggests this device supports 32 simultaneous PCM audio playback.

== Prerequisites ==

This article assumes you have a basic understanding and knowledge of Linux. For instance:

* <code>~/</code> refers to your HOME directory. If your user name is <code>blah</code>, then <code>~/</code> normally would be <code>/home/blah/</code>. And so <code>~/.asoundrc</code> would mean <code>/home/blah/.asoundrc</code>

* Files with names starting with a dot (".") are normally considered as hidden files. If you're using some sort of file manager application, remember to turn on or enable showing these hidden files.

* If a "dot rc" file (e.g. <code>.asoundrc</code>, <code>.openalrc</code>) does not exist, simply creates it.

This article assumes you have ALSA setup and working with your soundcard(s).

== The concept ==

It is simple. You want to get all the applications to use the ALSA <code>dmix</code> plugin for PCM audio playback, and sometimes also the <code>dsnoop</code> plugin for audio recording.

According to ALSA, <code>dmix</code> 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. <code>.asoundrc</code>) 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 <code>"plug:dmix"</code>. For example, with the ALSA command line player <code>aplay</code>, you run:

<pre>
$ aplay -D "plug:dmix" test.wav
</pre>

It's a good idea to run this to test if your <code>dmix</code> works.

For applications which does not have ALSA support (i.e. using OSS), you have a few choices:

; <code>aoss</code> : A wrapper script to run any application to use ALSA OSS. This works using simply via <code>LD_PRELOAD</code> to preload <code>libaoss.so</code>. It *seems* to use <code>dmix</code> if available automatically.

; <code>esd</code> : A software audio mixing daemon, typically shipped with GNOME. You can use its wrapper <code>esddsp</code> with other applications. You could run:
<pre>
$ esd -d plug:dmix
</pre>

; <code>artsd</code> : Another software audio mixing daemon, typically shipped with KDE. You can use its wrapper <code>artsdsp</code> with other applications. You could run:
<pre>
$ artsd -D plug:dmix
</pre>

However, not all apps work with all these wrappers. For example, festival does not seem to work properly with <code>aoss</code> and <code>artsd</code>. If possible it's a good idea to try all three approaches to get an OSS application to do ALSA.

<code>esd</code> does not seem to handle recording properly. So if you have an OSS application which does audio recording (say TeamSpeak), <code>esd</code> / <code>esddsp</code> 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 <code>/dev/dsp</code> (or <code>/dev/dsp0</code>, <code>/dev/dsp1</code>, etc), then it is probably using OSS. With ALSA, you normally specify an audio device using a string, which might look something like "<code>hw:0,0</code>" or "<code>plug:dmix</code>", or sometimes "<code>ALSA:default</code>", depending on the application itself.

=== <code>ldd</code> ===

<code>ldd</code> prints what shared libraries an application depends on.

Take <code>aplay</code> again as an example, you do:

<pre>
$ 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)
</pre>

Note the <code>libasound.so.2</code>, which is the ALSA library, which *possibly* means <code>aplay</code> *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 <code>mplayer</code> and <code>xine</code>, which can do audio playback using many different audio libraries/approaches (OSS, ALSA, ESD, ARTS, and more).

=== <code>strace</code> ===

<code>strace</code> is a rather powerful tool, which traces and prints system calls of a running application.

Take <code>mpg123</code> as an example, you do:

<pre>
$ 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
</pre>

This shows all calls to the system call <code>open()</code> of this running instance of <code>mpg123</code>. As you can see it is opening <code>/dev/dsp</code>, which hints it is using OSS.

For an ALSA application, you will see a lot of <code>open()</code> calls to devices like <code>/dev/snd/controlC0</code>, <code>/dev/aloadC2</code>, <code>/dev/snd/pcmC0D0p</code>, etc. (Try <code>strace</code> with <code>aplay</code>!)

== FlightGear ==

FlightGear uses OpenAL (via SimGear) for audio playback, and OpenAL supports ALSA, ESD and ARTS. However you have to make sure your OpenAL is built with the audio support you need. Run <code>configure --help</code> if you are building your own OpenAL.

To get OpenAL to use a particular ALSA device, put these in your <code>~/.openalrc</code>

<pre>
(define devices '(alsa))
(define alsa-out-device "plug:dmix")
</pre>

To get OpenAL to use ESD:

<pre>
(define devices '(esd))
</pre>

And to get OpenAL to use ARTS:

<pre>
(define devices '(arts))
</pre>

== Festival ==

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 <code>~/.festivalrc</code>:

<pre>
(Parameter.set 'Audio_Method 'esdaudio)
</pre>

And then run <code>festival</code> as usual. So:

<pre>
$ festival --server
</pre>

Of course, you'll have to make sure your ESD is running, for example:

<pre>
$ esd -d plug:dmix
</pre>

If for some reasons this does not work, you could always try using <code>esddsp</code>, which means you would be running:

<pre>
$ esddsp festival --server
</pre>

Test your festival server by:

<pre>
$ echo '(SayText "Hello")' | festival_client
</pre>

=== Using the <code>Audio_Command</code> parameter ===

You can configure festival to run another application for playing audio. In this case, we could use <code>aplay</code> to help us. In your <code>~/.festivalrc</code> put:

<pre>
(Parameter.set 'Audio_Command "aplay -D plug:dmix -q -c 1 -t raw -f s16 -r $SR $FILE")
(Parameter.set 'Audio_Method 'Audio_Command)
</pre>

<code>$SR</code> is the sampling rate, and <code>$FILE</code> is the audio data file generated by festival for playback.

== TeamSpeak ==

TeamSpeak works with <code>aoss</code> and <code>artsd</code> / <code>artsdsp</code>. It does not work with <code>esd</code> / <code>esddsp</code>, because <code>esd</code> does not seem to handle recording properly.

=== <code>aoss</code> ===

To run TeamSpeak, do:

<pre>
$ aoss TeamSpeak
</pre>

=== <code>arts</code> ===

You have to run <code>artsd</code> with <code>-d</code>, enabling full-duplex. So:

<pre>
$ artsd -d -D plug:duplex
</pre>

You'll need this [[ #~/.asoundrc ]] as well.

Then you have you run TeamSpeak.bin, instead of TeamSpeak, because <code>artsdsp</code> can only handle binary. You will also need to have LD_LIBRARY_PATH set to where TeamSpeak is installed. For example, if you have TeamSpeak installed at /opt/TeamSpeak/, then you should run:

<pre>
$ LD_LIBRARY_PATH=/opt/TeamSpeak artsdsp /opt/TeamSpeak.bin
</pre>

== ~/.asoundrc ==

Usually you shouldn't need a custom ALSA configuration. But just in case, here is a simple <code>~/.asoundrc</code> to get you started:

<pre>
pcm.duplex {
type asym
playback.pcm "dmix"
capture.pcm "dsnoop"
}

pcm.!default {
type plug
slave.pcm "duplex"
}
</pre>

This is the same as specifying "<code>plug:duplex</code>" as the audio device for all applications, for instance:

<pre>
$ aplay -D plug:duplex test.wav

$ arecord -D plug:duplex test.wav

$ esd -d plug:duplex

$ artsd -d -D plug:duplex
</pre>

So with this configuration, you do not have to specify which ALSA device applications should use. As long as the application uses ALSA, it will be using the <code>dmix</code> and <code>dsnoop</code> plugins.

With FlightGear/OpenAL, however, I'm not sure what the issue is, but you may still need to specify <code>alsa-out-device</code> in the <code>~/.openalrc</code>, which is:

<pre>
(define devices '(alsa))
(define alsa-out-device "plug:duplex")
</pre>

== GNOME and KDE ==

If you're using GNOME or KDE, you will probably have <code>esd</code> or <code>artsd</code> running already. In this case, you may also want to try this [[ #~/.asoundrc ]], which set <code>dmix</code> and <code>dsnoop</code> as the default to use for ALSA. You need to restart <code>esd</code> or <code>artsd</code> after making changes to <code>~/.asoundrc</code>. Make sure your <code>esd</code> or <code>artsd</code> is using ALSA, too.

(TODO: Anyone who uses GNOME or KDE could add more descriptions here, thanks)

== When things don't work ==

* Try this [[ #~/.asoundrc ]]

* <code>aoss</code> honours your ALSA configurations, and hence your <code>~/.asoundrc</code>. You want to make sure it is correct. Use <code>aplay</code> and <code>arecord</code> to test your setup.

* Any other thing to try is to temporarily rename or move away your <code>~/.asoundrc</code>, and then test everything again.

* See http://gentoo-wiki.com/HOWTO_ALSA_sound_mixer_aka_dmix (even if you're not using Gentoo). It's a pretty detailed HOWTO with ALSA audio including <code>dmix</code> and <code>dsnoop</code> configurations.

Linux software audio mixing with FlightGear

2006-06-17T11:03:54Z

Pigeon: /* The concept */

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 (<code>dmix</code> and <code>dsnoop</code> plugin).

== Audio mixing what? ==

One of the most common issues with soundcard and Linux is when you can only have one application playing sound at a time on some systems. This happens when the soundcard itself does not do audio mixing (i.e. hardware mixing).

Audio mixing allows multiple audio (PCM) streams to be "mixed" together and to be played at the same time. It is generally better and more efficient for a soundcard, if available, to do audio mixing in the hardware.

Software audio mixing is useful when you have a soundcard not capable of doing hardware mixing. Under Linux, software mixing can be done by ALSA's <code>dmix</code> / <code>dsnoop</code> plugin, or by userspace applications, like ESD and ARTS. Software uses your CPU to do the work and mixes multiple audio streams into one, before passing the audio data onto your soundcard for playback.

On Windows, software mixing is enabled by default transparently. Because of this, most people would have no idea about the capability of their sound cards in the Windows world. This is debatable whether this is good or bad, and is out of scope of this article.

With ALSA, an easy to test whether your soundcard supports hardware mixing or not would be running this following twice, say in two different terminals:

<pre>
$ aplay -D hw:0,0 test.wav
</pre>

This tells <code>aplay</code>, the ALSA audio player, to play the file <code>test.wav</code> using the first sound hardware directly, without using any plugin or any software mixing. For a soundcard without hardware mixing support, the second <code>aplay</code> would fail, and might look like this:

<pre>
$ aplay -D hw:0,0 test.wav
aplay: main:547: audio open error: Device or resource busy
</pre>

You could also find out from ALSA's driver info, by doing:

<pre>
$ cat /proc/asound/pcm
00-00: Intel ICH : Intel 82801DB-ICH4 : playback 1 : capture 1
00-01: Intel ICH - MIC ADC : Intel 82801DB-ICH4 - MIC ADC : capture 1
00-02: Intel ICH - MIC2 ADC : Intel 82801DB-ICH4 - MIC2 ADC : capture 1
00-03: Intel ICH - ADC2 : Intel 82801DB-ICH4 - ADC2 : capture 1
00-04: Intel ICH - IEC958 : Intel 82801DB-ICH4 - IEC958 : playback 1
01-00: Intel ICH - Modem : Intel 82801DB-ICH4 Modem - Modem : playback 1 : capture 1
</pre>

Notice the first line, "<code>playback 1</code>", indicating the device only supports one PCM audio playback at any time.

With a soundcard that supports hardware audio mixing, the same check looks like this:

<pre>
$ cat /proc/asound/pcm
00-00: emu10k1 : EMU10K1 : playback 32 : capture 1
00-01: emu10k1 mic : EMU10K1 MIC : capture 1
00-02: emu10k1 efx : EMU10K1 EFX : playback 8 : capture 1
</pre>

As you can see, the first line suggests this device supports 32 simultaneous PCM audio playback.

== Prerequisites ==

This article assumes you have a basic understanding and knowledge of Linux. For instance:

* <code>~/</code> refers to your HOME directory. If your user name is <code>blah</code>, then <code>~/</code> normally would be <code>/home/blah/</code>. And so <code>~/.asoundrc</code> would mean <code>/home/blah/.asoundrc</code>

* Files with names starting with a dot (".") are normally considered as hidden files. If you're using some sort of file manager application, remember to turn on or enable showing these hidden files.

* If a "dot rc" file (e.g. <code>.asoundrc</code>, <code>.openalrc</code>) does not exist, simply creates it.

This article assumes you have ALSA setup and working with your soundcard(s).

== The concept ==

It is simple. You want to get all the applications to use the ALSA <code>dmix</code> plugin for PCM audio playback, and sometimes also the <code>dsnoop</code> plugin for audio recording.

According to ALSA, <code>dmix</code> 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. <code>.asoundrc</code>) 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 <code>"plug:dmix"</code>. For example, with the ALSA command line player <code>aplay</code>, you run:

<pre>
$ aplay -D "plug:dmix" test.wav
</pre>

It's a good idea to run this to test if your <code>dmix</code> works.

For applications which does not have ALSA support (i.e. using OSS), you have a few choices:

; <code>aoss</code> : A wrapper script to run any application to use ALSA OSS. This works using simply via <code>LD_PRELOAD</code> to preload <code>libaoss.so</code>. It *seems* to use <code>dmix</code> if available automatically.

; <code>esd</code> : A software audio mixing daemon, typically shipped with GNOME. You can use its wrapper <code>esddsp</code> with other applications. You could run:
<pre>
$ esd -d plug:dmix
</pre>

; <code>artsd</code> : Another software audio mixing daemon, typically shipped with KDE. You can use its wrapper <code>artsdsp</code> with other applications. You could run:
<pre>
$ artsd -D plug:dmix
</pre>

However, not all apps work with all these wrappers. For example, festival does not seem to work properly with <code>aoss</code> and <code>artsd</code>. If possible it's a good idea to try all three approaches to get an OSS application to do ALSA.

<code>esd</code> does not seem to handle recording properly. So if you have an OSS application which does audio recording (say TeamSpeak), <code>esd</code> / <code>esddsp</code> 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 <code>/dev/dsp</code> (or <code>/dev/dsp0</code>, <code>/dev/dsp1</code>, etc), then it is probably using OSS. With ALSA, you normally specify an audio device using a string, which might look something like "<code>hw:0,0</code>" or "<code>plug:dmix</code>", or sometimes "<code>ALSA:default</code>", depending on the application itself.

=== <code>ldd</code> ===

<code>ldd</code> prints what shared libraries an application depends on.

Take <code>aplay</code> again as an example, you do:

<pre>
$ 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)
</pre>

Note the <code>libasound.so.2</code>, which is the ALSA library, which *possibly* means <code>aplay</code> *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 <code>mplayer</code> and <code>xine</code>, which can do audio playback using many different audio libraries/approaches (OSS, ALSA, ESD, ARTS, and more).

=== <code>strace</code> ===

<code>strace</code> is a rather powerful tool, which traces and prints system calls of a running application.

Take <code>mpg123</code> as an example, you do:

<pre>
$ 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
</pre>

This shows all calls to the system call <code>open()</code> of this running instance of <code>mpg123</code>. As you can see it is opening <code>/dev/dsp</code>, which hints it is using OSS.

For an ALSA application, you will see a lot of <code>open()</code> calls to devices like <code>/dev/snd/controlC0</code>, <code>/dev/aloadC2</code>, <code>/dev/snd/pcmC0D0p</code>, etc. (Try <code>strace</code> with <code>aplay</code>!)

== FlightGear ==

FlightGear uses OpenAL (via SimGear) for audio playback, and OpenAL supports ALSA, ESD and ARTS. However you have to make sure your OpenAL is built with the audio support you need. Run <code>configure --help</code> if you are building your own OpenAL.

To get OpenAL to use a particular ALSA device, put these in your <code>~/.openalrc</code>

<pre>
(define devices '(alsa))
(define alsa-out-device "plug:dmix")
</pre>

To get OpenAL to use ESD:

<pre>
(define devices '(esd))
</pre>

And to get OpenAL to use ARTS:

<pre>
(define devices '(arts))
</pre>

== Festival ==

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 <code>~/.festivalrc</code>:

<pre>
(Parameter.set 'Audio_Method 'esdaudio)
</pre>

And then run <code>festival</code> as usual. So:

<pre>
$ festival --server
</pre>

Of course, you'll have to make sure your ESD is running, for example:

<pre>
$ esd -d plug:dmix
</pre>

If for some reasons this does not work, you could always try using <code>esddsp</code>, which means you would be running:

<pre>
$ esddsp festival --server
</pre>

Test your festival server by:

<pre>
$ echo '(SayText "Hello")' | festival_client
</pre>

=== Using the <code>Audio_Command</code> parameter ===

You can configure festival to run another application for playing audio. In this case, we could use <code>aplay</code> to help us. In your <code>~/.festivalrc</code> put:

<pre>
(Parameter.set 'Audio_Command "aplay -D plug:dmix -q -c 1 -t raw -f s16 -r $SR $FILE")
(Parameter.set 'Audio_Method 'Audio_Command)
</pre>

<code>$SR</code> is the sampling rate, and <code>$FILE</code> is the audio data file generated by festival for playback.

== TeamSpeak ==

TeamSpeak works with <code>aoss</code> and <code>artsd</code> / <code>artsdsp</code>. It does not work with <code>esd</code> / <code>esddsp</code>, because <code>esd</code> does not seem to handle recording properly.

=== <code>aoss</code> ===

To run TeamSpeak, do:

<pre>
$ aoss TeamSpeak
</pre>

=== <code>arts</code> ===

You have to run <code>artsd</code> with <code>-d</code>, enabling full-duplex. So:

<pre>
$ artsd -d -D plug:duplex
</pre>

You'll need this [[ #~/.asoundrc ]] as well.

Then you have you run TeamSpeak.bin, instead of TeamSpeak, because <code>artsdsp</code> can only handle binary. You will also need to have LD_LIBRARY_PATH set to where TeamSpeak is installed. For example, if you have TeamSpeak installed at /opt/TeamSpeak/, then you should run:

<pre>
$ LD_LIBRARY_PATH=/opt/TeamSpeak artsdsp /opt/TeamSpeak.bin
</pre>

== ~/.asoundrc ==

Usually you shouldn't need a custom ALSA configuration. But just in case, here is a simple <code>~/.asoundrc</code> to get you started:

<pre>
pcm.duplex {
type asym
playback.pcm "dmix"
capture.pcm "dsnoop"
}

pcm.!default {
type plug
slave.pcm "duplex"
}
</pre>

This is the same as specifying "<code>plug:duplex</code>" as the audio device for all applications, for instance:

<pre>
$ aplay -D plug:duplex test.wav

$ arecord -D plug:duplex test.wav

$ esd -d plug:duplex

$ artsd -d -D plug:duplex
</pre>

So with this configuration, you do not have to specify which ALSA device applications should use. As long as the application uses ALSA, it will be using the <code>dmix</code> and <code>dsnoop</code> plugins. (FlightGear/OpenAL for example, you could leave out the <code>alsa-out-device</code> in the <code>~/.openalrc</code>)

== GNOME and KDE ==

If you're using GNOME or KDE, you will probably have <code>esd</code> or <code>artsd</code> running already. In this case, you may also want to try this [[ #~/.asoundrc ]], which set <code>dmix</code> and <code>dsnoop</code> as the default to use for ALSA. You need to restart <code>esd</code> or <code>artsd</code> after making changes to <code>~/.asoundrc</code>. Make sure your <code>esd</code> or <code>artsd</code> is using ALSA, too.

(TODO: Anyone who uses GNOME or KDE could add more descriptions here, thanks)

== When things don't work ==

* Try this [[ #~/.asoundrc ]]

* <code>aoss</code> honours your ALSA configurations, and hence your <code>~/.asoundrc</code>. You want to make sure it is correct. Use <code>aplay</code> and <code>arecord</code> to test your setup.

* Any other thing to try is to temporarily rename or move away your <code>~/.asoundrc</code>, and then test everything again.

* See http://gentoo-wiki.com/HOWTO_ALSA_sound_mixer_aka_dmix (even if you're not using Gentoo). It's a pretty detailed HOWTO with ALSA audio including <code>dmix</code> and <code>dsnoop</code> configurations.

Linux software audio mixing with FlightGear

2006-06-17T11:00:47Z

Pigeon:

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 (<code>dmix</code> and <code>dsnoop</code> plugin).

== Audio mixing what? ==

One of the most common issues with soundcard and Linux is when you can only have one application playing sound at a time on some systems. This happens when the soundcard itself does not do audio mixing (i.e. hardware mixing).

Audio mixing allows multiple audio (PCM) streams to be "mixed" together and to be played at the same time. It is generally better and more efficient for a soundcard, if available, to do audio mixing in the hardware.

Software audio mixing is useful when you have a soundcard not capable of doing hardware mixing. Under Linux, software mixing can be done by ALSA's <code>dmix</code> / <code>dsnoop</code> plugin, or by userspace applications, like ESD and ARTS. Software uses your CPU to do the work and mixes multiple audio streams into one, before passing the audio data onto your soundcard for playback.

On Windows, software mixing is enabled by default transparently. Because of this, most people would have no idea about the capability of their sound cards in the Windows world. This is debatable whether this is good or bad, and is out of scope of this article.

With ALSA, an easy to test whether your soundcard supports hardware mixing or not would be running this following twice, say in two different terminals:

<pre>
$ aplay -D hw:0,0 test.wav
</pre>

This tells <code>aplay</code>, the ALSA audio player, to play the file <code>test.wav</code> using the first sound hardware directly, without using any plugin or any software mixing. For a soundcard without hardware mixing support, the second <code>aplay</code> would fail, and might look like this:

<pre>
$ aplay -D hw:0,0 test.wav
aplay: main:547: audio open error: Device or resource busy
</pre>

You could also find out from ALSA's driver info, by doing:

<pre>
$ cat /proc/asound/pcm
00-00: Intel ICH : Intel 82801DB-ICH4 : playback 1 : capture 1
00-01: Intel ICH - MIC ADC : Intel 82801DB-ICH4 - MIC ADC : capture 1
00-02: Intel ICH - MIC2 ADC : Intel 82801DB-ICH4 - MIC2 ADC : capture 1
00-03: Intel ICH - ADC2 : Intel 82801DB-ICH4 - ADC2 : capture 1
00-04: Intel ICH - IEC958 : Intel 82801DB-ICH4 - IEC958 : playback 1
01-00: Intel ICH - Modem : Intel 82801DB-ICH4 Modem - Modem : playback 1 : capture 1
</pre>

Notice the first line, "<code>playback 1</code>", indicating the device only supports one PCM audio playback at any time.

With a soundcard that supports hardware audio mixing, the same check looks like this:

<pre>
$ cat /proc/asound/pcm
00-00: emu10k1 : EMU10K1 : playback 32 : capture 1
00-01: emu10k1 mic : EMU10K1 MIC : capture 1
00-02: emu10k1 efx : EMU10K1 EFX : playback 8 : capture 1
</pre>

As you can see, the first line suggests this device supports 32 simultaneous PCM audio playback.

== Prerequisites ==

This article assumes you have a basic understanding and knowledge of Linux. For instance:

* <code>~/</code> refers to your HOME directory. If your user name is <code>blah</code>, then <code>~/</code> normally would be <code>/home/blah/</code>. And so <code>~/.asoundrc</code> would mean <code>/home/blah/.asoundrc</code>

* Files with names starting with a dot (".") are normally considered as hidden files. If you're using some sort of file manager application, remember to turn on or enable showing these hidden files.

* If a "dot rc" file (e.g. <code>.asoundrc</code>, <code>.openalrc</code>) does not exist, simply creates it.

This article assumes you have ALSA setup and working with your soundcard(s).

== The concept ==

It is simple. You want to get all the applications to use the ALSA <code>dmix</code> plugin for PCM audio playback, and sometimes also the <code>dsnoop</code> plugin for audio recording.

According to ALSA, <code>dmix</code> 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. <code>.asoundrc</code>) 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 <code>"plug:dmix"</code>. For example, with the ALSA command line player <code>aplay</code>, you run:

<pre>
$ aplay -D "plug:dmix" test.wav
</pre>

It's a good idea to run this to test if your <code>dmix</code> works.

For applications which does not have ALSA support (i.e. using OSS), you have a few choices:

; <code>aoss</code> : A wrapper script to run any application to use ALSA OSS. This works using simply via <code>LD_PRELOAD</code> to preload <code>libaoss.so</code>. It *seems* to use <code>dmix</code> if available automatically.

; <code>esd</code> : A software audio mixing daemon, typically shipped with GNOME. You can use its wrapper <code>esddsp</code> with other applications. You could run:
<pre>
$ esd -d plug:dmix
</pre>

; <code>artsd</code> : Another software audio mixing daemon, typically shipped with KDE. You can use its wrapper <code>artsdsp</code> with other applications. You could run:
<pre>
$ artsd -D plug:dmix
</pre>

However, not all apps work with all these wrappers. For example, festival does not seem to work properly with <code>aoss</code> and <code>artsd</code>. If possible it's a good idea to try all three approaches to get an OSS application to do ALSA.

<code>esd</code> does not seem to handle recording properly. So if you have an OSS application which does audio recording (say TeamSpeak), <code>esd</code> / <code>esddsp</code> 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 <code>/dev/dsp</code> (or <code>/dev/dsp0</code>, <code>/dev/dsp1</code>, etc), then it is probably using OSS. With ALSA, you normally specify an audio device using a string, which might look something like "<code>hw:0,0</code>" or "<code>plug:dmix</code>", or sometimes "<code>ALSA:default</code>", depending on the application itself.

=== <code>ldd</code> ===

<code>ldd</code> prints what shared libraries an application depends on.

Take <code>aplay</code> again as an example, you do:

<pre>
$ 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)
</pre>

Note the <code>libasound.so.2</code>, which is the ALSA library, which *possibly* means <code>aplay</code> *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 <code>mplayer</code> and <code>xine</code>, which can do audio playback using many different audio libraries/approaches (OSS, ALSA, ESD, ARTS, and more).

=== <code>strace</code> ===

<code>strace</code> is a rather powerful tool, which traces and prints system calls of a running application.

Take <code>mpg123</code> as an example, you do:

<pre>
$ 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
</pre>

This shows all calls to the system call <code>open()</code> of this running instance of <code>mpg123</code>. As you can see it is opening <code>/dev/dsp</code>, which hints it is using OSS.

For an ALSA application, you will see a lot of <code>open()</code> calls to devices like <code>/dev/snd/controlC0</code>, <code>/dev/aloadC2</code>, <code>/dev/snd/pcmC0D0p</code>, etc. (Try <code>strace</code> with <code>aplay</code>!)

== FlightGear ==

FlightGear uses OpenAL (via SimGear) for audio playback, and OpenAL supports ALSA, ESD and ARTS. However you have to make sure your OpenAL is built with the audio support you need. Run <code>configure --help</code> if you are building your own OpenAL.

To get OpenAL to use a particular ALSA device, put these in your <code>~/.openalrc</code>

<pre>
(define devices '(alsa))
(define alsa-out-device "plug:dmix")
</pre>

To get OpenAL to use ESD:

<pre>
(define devices '(esd))
</pre>

And to get OpenAL to use ARTS:

<pre>
(define devices '(arts))
</pre>

== Festival ==

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 <code>~/.festivalrc</code>:

<pre>
(Parameter.set 'Audio_Method 'esdaudio)
</pre>

And then run <code>festival</code> as usual. So:

<pre>
$ festival --server
</pre>

Of course, you'll have to make sure your ESD is running, for example:

<pre>
$ esd -d plug:dmix
</pre>

If for some reasons this does not work, you could always try using <code>esddsp</code>, which means you would be running:

<pre>
$ esddsp festival --server
</pre>

Test your festival server by:

<pre>
$ echo '(SayText "Hello")' | festival_client
</pre>

=== Using the <code>Audio_Command</code> parameter ===

You can configure festival to run another application for playing audio. In this case, we could use <code>aplay</code> to help us. In your <code>~/.festivalrc</code> put:

<pre>
(Parameter.set 'Audio_Command "aplay -D plug:dmix -q -c 1 -t raw -f s16 -r $SR $FILE")
(Parameter.set 'Audio_Method 'Audio_Command)
</pre>

<code>$SR</code> is the sampling rate, and <code>$FILE</code> is the audio data file generated by festival for playback.

== TeamSpeak ==

TeamSpeak works with <code>aoss</code> and <code>artsd</code> / <code>artsdsp</code>. It does not work with <code>esd</code> / <code>esddsp</code>, because <code>esd</code> does not seem to handle recording properly.

=== <code>aoss</code> ===

To run TeamSpeak, do:

<pre>
$ aoss TeamSpeak
</pre>

=== <code>arts</code> ===

You have to run <code>artsd</code> with <code>-d</code>, enabling full-duplex. So:

<pre>
$ artsd -d -D plug:duplex
</pre>

You'll need this [[ #~/.asoundrc ]] as well.

Then you have you run TeamSpeak.bin, instead of TeamSpeak, because <code>artsdsp</code> can only handle binary. You will also need to have LD_LIBRARY_PATH set to where TeamSpeak is installed. For example, if you have TeamSpeak installed at /opt/TeamSpeak/, then you should run:

<pre>
$ LD_LIBRARY_PATH=/opt/TeamSpeak artsdsp /opt/TeamSpeak.bin
</pre>

== ~/.asoundrc ==

Usually you shouldn't need a custom ALSA configuration. But just in case, here is a simple <code>~/.asoundrc</code> to get you started:

<pre>
pcm.duplex {
type asym
playback.pcm "dmix"
capture.pcm "dsnoop"
}

pcm.!default {
type plug
slave.pcm "duplex"
}
</pre>

This is the same as specifying "<code>plug:duplex</code>" as the audio device for all applications, for instance:

<pre>
$ aplay -D plug:duplex test.wav

$ arecord -D plug:duplex test.wav

$ esd -d plug:duplex

$ artsd -d -D plug:duplex
</pre>

So with this configuration, you do not have to specify which ALSA device applications should use. As long as the application uses ALSA, it will be using the <code>dmix</code> and <code>dsnoop</code> plugins. (FlightGear/OpenAL for example, you could leave out the <code>alsa-out-device</code> in the <code>~/.openalrc</code>)

== GNOME and KDE ==

If you're using GNOME or KDE, you will probably have <code>esd</code> or <code>artsd</code> running already. In this case, you may also want to try this [[ #~/.asoundrc ]], which set <code>dmix</code> and <code>dsnoop</code> as the default to use for ALSA. You need to restart <code>esd</code> or <code>artsd</code> after making changes to <code>~/.asoundrc</code>. Make sure your <code>esd</code> or <code>artsd</code> is using ALSA, too.

(TODO: Anyone who uses GNOME or KDE could add more descriptions here, thanks)

== When things don't work ==

* Try this [[ #~/.asoundrc ]]

* <code>aoss</code> honours your ALSA configurations, and hence your <code>~/.asoundrc</code>. You want to make sure it is correct. Use <code>aplay</code> and <code>arecord</code> to test your setup.

* Any other thing to try is to temporarily rename or move away your <code>~/.asoundrc</code>, and then test everything again.

* See http://gentoo-wiki.com/HOWTO_ALSA_sound_mixer_aka_dmix (even if you're not using Gentoo). It's a pretty detailed HOWTO with ALSA audio including <code>dmix</code> and <code>dsnoop</code> configurations.

Linux software audio mixing with FlightGear

2006-06-17T10:48:13Z

Pigeon: /* ~/.asoundrc */

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 (<code>dmix</code> and <code>dsnoop</code> plugin).

== Audio mixing what? ==

One of the most common issues with soundcard and Linux is when you can only have one application playing sound at a time on some systems. This happens when the soundcard itself does not do audio mixing (i.e. hardware mixing).

Audio mixing allows multiple audio (PCM) streams to be "mixed" together and to be played at the same time. It is generally better and more efficient for a soundcard, if available, to do audio mixing in the hardware.

Software audio mixing is useful when you have a soundcard not capable of doing hardware mixing. Under Linux, software mixing can be done by ALSA's <code>dmix</code> / <code>dsnoop</code> plugin, or by userspace applications, like ESD and ARTS. Software uses your CPU to do the work and mixes multiple audio streams into one, before passing the audio data onto your soundcard for playback.

On Windows, software mixing is enabled by default transparently. Because of this, most people would have no idea about the capability of their sound cards in the Windows world. This is debatable whether this is good or bad, and is out of scope of this article.

With ALSA, an easy to test whether your soundcard supports hardware mixing or not would be running this following twice, say in two different terminals:

$ aplay -D hw:0,0 test.wav

This tells <code>aplay</code>, the ALSA audio player, to play the file <code>test.wav</code> using the first sound hardware directly, without using any plugin or any software mixing. For a soundcard without hardware mixing support, the second <code>aplay</code> would fail, and might look like this:

$ aplay -D hw:0,0 test.wav
aplay: main:547: audio open error: Device or resource busy

You could also find out from ALSA's driver info, by doing:

$ cat /proc/asound/pcm
00-00: Intel ICH : Intel 82801DB-ICH4 : playback 1 : capture 1
00-01: Intel ICH - MIC ADC : Intel 82801DB-ICH4 - MIC ADC : capture 1
00-02: Intel ICH - MIC2 ADC : Intel 82801DB-ICH4 - MIC2 ADC : capture 1
00-03: Intel ICH - ADC2 : Intel 82801DB-ICH4 - ADC2 : capture 1
00-04: Intel ICH - IEC958 : Intel 82801DB-ICH4 - IEC958 : playback 1
01-00: Intel ICH - Modem : Intel 82801DB-ICH4 Modem - Modem : playback 1 : capture 1

Notice the first line, "<code>playback 1</code>", indicating the device only supports one PCM audio playback at any time.

With a soundcard that supports hardware audio mixing, the same check looks like this:

$ cat /proc/asound/pcm
00-00: emu10k1 : EMU10K1 : playback 32 : capture 1
00-01: emu10k1 mic : EMU10K1 MIC : capture 1
00-02: emu10k1 efx : EMU10K1 EFX : playback 8 : capture 1

As you can see, the first line suggests this device supports 32 simultaneous PCM audio playback.

== Prerequisites ==

This article assumes you have a basic understanding and knowledge of Linux. For instance:

* <code>~/</code> refers to your HOME directory. If your user name is <code>blah</code>, then <code>~/</code> normally would be <code>/home/blah/</code>. And so <code>~/.asoundrc</code> would mean <code>/home/blah/.asoundrc</code>

* Files with names starting with a dot (".") are normally considered as hidden files. If you're using some sort of file manager application, remember to turn on or enable showing these hidden files.

* If a "dot rc" file (e.g. <code>.asoundrc</code>, <code>.openalrc</code>) does not exist, simply creates it.

This article assumes you have ALSA setup and working with your soundcard(s).

== The concept ==

It is simple. You want to get all the applications to use the ALSA <code>dmix</code> plugin for PCM audio playback, and sometimes also the <code>dsnoop</code> plugin for audio recording.

According to ALSA, <code>dmix</code> 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. <code>.asoundrc</code>) 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 <code>"plug:dmix"</code>. For example, with the ALSA command line player <code>aplay</code>, you run:

$ aplay -D "plug:dmix" test.wav

It's a good idea to run this to test if your <code>dmix</code> works.

For applications which does not have ALSA support (i.e. using OSS), you have a few choices:

; <code>aoss</code> : A wrapper script to run any application to use ALSA OSS. This works using simply via <code>LD_PRELOAD</code> to preload <code>libaoss.so</code>. It *seems* to use <code>dmix</code> if available automatically.

; <code>esd</code> : A software audio mixing daemon, typically shipped with GNOME. You can use its wrapper <code>esddsp</code> with other applications. You could run:
$ esd -d plug:dmix

; <code>artsd</code> : Another software audio mixing daemon, typically shipped with KDE. You can use its wrapper <code>artsdsp</code> 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 <code>aoss</code> and <code>artsd</code>. If possible it's a good idea to try all three approaches to get an OSS application to do ALSA.

<code>esd</code> does not seem to handle recording properly. So if you have an OSS application which does audio recording (say TeamSpeak), <code>esd</code> / <code>esddsp</code> 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 <code>/dev/dsp</code> (or <code>/dev/dsp0</code>, <code>/dev/dsp1</code>, etc), then it is probably using OSS. With ALSA, you normally specify an audio device using a string, which might look something like "<code>hw:0,0</code>" or "<code>plug:dmix</code>", or sometimes "<code>ALSA:default</code>", depending on the application itself.

=== <code>ldd</code> ===

<code>ldd</code> prints what shared libraries an application depends on.

Take <code>aplay</code> 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 <code>libasound.so.2</code>, which is the ALSA library, which *possibly* means <code>aplay</code> *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 <code>mplayer</code> and <code>xine</code>, which can do audio playback using many different audio libraries/approaches (OSS, ALSA, ESD, ARTS, and more).

=== <code>strace</code> ===

<code>strace</code> is a rather powerful tool, which traces and prints system calls of a running application.

Take <code>mpg123</code> 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 <code>open()</code> of this running instance of <code>mpg123</code>. As you can see it is opening <code>/dev/dsp</code>, which hints it is using OSS.

For an ALSA application, you will see a lot of <code>open()</code> calls to devices like <code>/dev/snd/controlC0</code>, <code>/dev/aloadC2</code>, <code>/dev/snd/pcmC0D0p</code>, etc. (Try <code>strace</code> with <code>aplay</code>!)

== FlightGear ==

FlightGear uses OpenAL (via SimGear) for audio playback, and OpenAL supports ALSA, ESD and ARTS. However you have to make sure your OpenAL is built with the audio support you need. Run <code>configure --help</code> if you are building your own OpenAL.

To get OpenAL to use a particular ALSA device, put these in your <code>~/.openalrc</code>

(define devices '(alsa))
(define alsa-out-device "plug:dmix")

To get OpenAL to use ESD:

(define devices '(esd))

And to get OpenAL to use ARTS:

(define devices '(arts))

== Festival ==

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 <code>~/.festivalrc</code>:

(Parameter.set 'Audio_Method 'esdaudio)

And then run <code>festival</code> 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 <code>esddsp</code>, which means you would be running:

$ esddsp festival --server

Test your festival server by:

$ echo '(SayText "Hello")' | festival_client

=== Using the <code>Audio_Command</code> parameter ===

You can configure festival to run another application for playing audio. In this case, we could use <code>aplay</code> to help us. In your <code>~/.festivalrc</code> 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)

<code>$SR</code> is the sampling rate, and <code>$FILE</code> is the audio data file generated by festival for playback.

== TeamSpeak ==

TeamSpeak works with <code>aoss</code> and <code>artsd</code> / <code>artsdsp</code>. It does not work with <code>esd</code> / <code>esddsp</code>, because <code>esd</code> does not seem to handle recording properly.

=== <code>aoss</code> ===

To run TeamSpeak, do:

$ aoss TeamSpeak

=== <code>arts</code> ===

You have to run <code>artsd</code> with <code>-d</code>, enabling full-duplex. So:

$ artsd -d -D plug:duplex

You'll need this [[ #~/.asoundrc ]] as well.

Then you have you run TeamSpeak.bin, instead of TeamSpeak, because <code>artsdsp</code> can only handle binary. You will also need to have LD_LIBRARY_PATH set to where TeamSpeak is installed. For example, if you have TeamSpeak installed at /opt/TeamSpeak/, then you should run:

$ LD_LIBRARY_PATH=/opt/TeamSpeak artsdsp /opt/TeamSpeak.bin

== ~/.asoundrc ==

Usually you shouldn't need a custom ALSA configuration. But just in case, here is a simple <code>~/.asoundrc</code> to get you started:

<pre>
pcm.duplex {
type asym
playback.pcm "dmix"
capture.pcm "dsnoop"
}

pcm.!default {
type plug
slave.pcm "duplex"
}
</pre>

This is the same as specifying "<code>plug:duplex</code>" as the audio device for all applications, for instance:

<pre>
$ aplay -D plug:duplex test.wav

$ arecord -D plug:duplex test.wav

$ esd -d plug:duplex

$ artsd -d -D plug:duplex
</pre>

So with this configuration, you do not have to specify which ALSA device applications should use. As long as the application uses ALSA, it will be using the <code>dmix</code> and <code>dsnoop</code> plugins. (FlightGear/OpenAL for example, you could leave out the <code>alsa-out-device</code> in the <code>~/.openalrc</code>)

== GNOME and KDE ==

If you're using GNOME or KDE, you will probably have <code>esd</code> or <code>artsd</code> running already. In this case, you may also want to try this [[ #~/.asoundrc ]], which set <code>dmix</code> and <code>dsnoop</code> as the default to use for ALSA. You need to restart <code>esd</code> or <code>artsd</code> after making changes to <code>~/.asoundrc</code>. Make sure your <code>esd</code> or <code>artsd</code> is using ALSA, too.

(TODO: Anyone who uses GNOME or KDE could add more descriptions here, thanks)

== When things don't work ==

* Try this [[ #~/.asoundrc ]]

* <code>aoss</code> honours your ALSA configurations, and hence your <code>~/.asoundrc</code>. You want to make sure it is correct. Use <code>aplay</code> and <code>arecord</code> to test your setup.

* Any other thing to try is to temporarily rename or move away your <code>~/.asoundrc</code>, and then test everything again.

* See http://gentoo-wiki.com/HOWTO_ALSA_sound_mixer_aka_dmix (even if you're not using Gentoo). It's a pretty detailed HOWTO with ALSA audio including <code>dmix</code> and <code>dsnoop</code> configurations.

Linux software audio mixing with FlightGear

2006-06-17T10:47:21Z

Pigeon: /* <code>arts</code> */

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 (<code>dmix</code> and <code>dsnoop</code> plugin).

== Audio mixing what? ==

One of the most common issues with soundcard and Linux is when you can only have one application playing sound at a time on some systems. This happens when the soundcard itself does not do audio mixing (i.e. hardware mixing).

Audio mixing allows multiple audio (PCM) streams to be "mixed" together and to be played at the same time. It is generally better and more efficient for a soundcard, if available, to do audio mixing in the hardware.

Software audio mixing is useful when you have a soundcard not capable of doing hardware mixing. Under Linux, software mixing can be done by ALSA's <code>dmix</code> / <code>dsnoop</code> plugin, or by userspace applications, like ESD and ARTS. Software uses your CPU to do the work and mixes multiple audio streams into one, before passing the audio data onto your soundcard for playback.

On Windows, software mixing is enabled by default transparently. Because of this, most people would have no idea about the capability of their sound cards in the Windows world. This is debatable whether this is good or bad, and is out of scope of this article.

With ALSA, an easy to test whether your soundcard supports hardware mixing or not would be running this following twice, say in two different terminals:

$ aplay -D hw:0,0 test.wav

This tells <code>aplay</code>, the ALSA audio player, to play the file <code>test.wav</code> using the first sound hardware directly, without using any plugin or any software mixing. For a soundcard without hardware mixing support, the second <code>aplay</code> would fail, and might look like this:

$ aplay -D hw:0,0 test.wav
aplay: main:547: audio open error: Device or resource busy

You could also find out from ALSA's driver info, by doing:

$ cat /proc/asound/pcm
00-00: Intel ICH : Intel 82801DB-ICH4 : playback 1 : capture 1
00-01: Intel ICH - MIC ADC : Intel 82801DB-ICH4 - MIC ADC : capture 1
00-02: Intel ICH - MIC2 ADC : Intel 82801DB-ICH4 - MIC2 ADC : capture 1
00-03: Intel ICH - ADC2 : Intel 82801DB-ICH4 - ADC2 : capture 1
00-04: Intel ICH - IEC958 : Intel 82801DB-ICH4 - IEC958 : playback 1
01-00: Intel ICH - Modem : Intel 82801DB-ICH4 Modem - Modem : playback 1 : capture 1

Notice the first line, "<code>playback 1</code>", indicating the device only supports one PCM audio playback at any time.

With a soundcard that supports hardware audio mixing, the same check looks like this:

$ cat /proc/asound/pcm
00-00: emu10k1 : EMU10K1 : playback 32 : capture 1
00-01: emu10k1 mic : EMU10K1 MIC : capture 1
00-02: emu10k1 efx : EMU10K1 EFX : playback 8 : capture 1

As you can see, the first line suggests this device supports 32 simultaneous PCM audio playback.

== Prerequisites ==

This article assumes you have a basic understanding and knowledge of Linux. For instance:

* <code>~/</code> refers to your HOME directory. If your user name is <code>blah</code>, then <code>~/</code> normally would be <code>/home/blah/</code>. And so <code>~/.asoundrc</code> would mean <code>/home/blah/.asoundrc</code>

* Files with names starting with a dot (".") are normally considered as hidden files. If you're using some sort of file manager application, remember to turn on or enable showing these hidden files.

* If a "dot rc" file (e.g. <code>.asoundrc</code>, <code>.openalrc</code>) does not exist, simply creates it.

This article assumes you have ALSA setup and working with your soundcard(s).

== The concept ==

It is simple. You want to get all the applications to use the ALSA <code>dmix</code> plugin for PCM audio playback, and sometimes also the <code>dsnoop</code> plugin for audio recording.

According to ALSA, <code>dmix</code> 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. <code>.asoundrc</code>) 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 <code>"plug:dmix"</code>. For example, with the ALSA command line player <code>aplay</code>, you run:

$ aplay -D "plug:dmix" test.wav

It's a good idea to run this to test if your <code>dmix</code> works.

For applications which does not have ALSA support (i.e. using OSS), you have a few choices:

; <code>aoss</code> : A wrapper script to run any application to use ALSA OSS. This works using simply via <code>LD_PRELOAD</code> to preload <code>libaoss.so</code>. It *seems* to use <code>dmix</code> if available automatically.

; <code>esd</code> : A software audio mixing daemon, typically shipped with GNOME. You can use its wrapper <code>esddsp</code> with other applications. You could run:
$ esd -d plug:dmix

; <code>artsd</code> : Another software audio mixing daemon, typically shipped with KDE. You can use its wrapper <code>artsdsp</code> 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 <code>aoss</code> and <code>artsd</code>. If possible it's a good idea to try all three approaches to get an OSS application to do ALSA.

<code>esd</code> does not seem to handle recording properly. So if you have an OSS application which does audio recording (say TeamSpeak), <code>esd</code> / <code>esddsp</code> 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 <code>/dev/dsp</code> (or <code>/dev/dsp0</code>, <code>/dev/dsp1</code>, etc), then it is probably using OSS. With ALSA, you normally specify an audio device using a string, which might look something like "<code>hw:0,0</code>" or "<code>plug:dmix</code>", or sometimes "<code>ALSA:default</code>", depending on the application itself.

=== <code>ldd</code> ===

<code>ldd</code> prints what shared libraries an application depends on.

Take <code>aplay</code> 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 <code>libasound.so.2</code>, which is the ALSA library, which *possibly* means <code>aplay</code> *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 <code>mplayer</code> and <code>xine</code>, which can do audio playback using many different audio libraries/approaches (OSS, ALSA, ESD, ARTS, and more).

=== <code>strace</code> ===

<code>strace</code> is a rather powerful tool, which traces and prints system calls of a running application.

Take <code>mpg123</code> 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 <code>open()</code> of this running instance of <code>mpg123</code>. As you can see it is opening <code>/dev/dsp</code>, which hints it is using OSS.

For an ALSA application, you will see a lot of <code>open()</code> calls to devices like <code>/dev/snd/controlC0</code>, <code>/dev/aloadC2</code>, <code>/dev/snd/pcmC0D0p</code>, etc. (Try <code>strace</code> with <code>aplay</code>!)

== FlightGear ==

FlightGear uses OpenAL (via SimGear) for audio playback, and OpenAL supports ALSA, ESD and ARTS. However you have to make sure your OpenAL is built with the audio support you need. Run <code>configure --help</code> if you are building your own OpenAL.

To get OpenAL to use a particular ALSA device, put these in your <code>~/.openalrc</code>

(define devices '(alsa))
(define alsa-out-device "plug:dmix")

To get OpenAL to use ESD:

(define devices '(esd))

And to get OpenAL to use ARTS:

(define devices '(arts))

== Festival ==

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 <code>~/.festivalrc</code>:

(Parameter.set 'Audio_Method 'esdaudio)

And then run <code>festival</code> 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 <code>esddsp</code>, which means you would be running:

$ esddsp festival --server

Test your festival server by:

$ echo '(SayText "Hello")' | festival_client

=== Using the <code>Audio_Command</code> parameter ===

You can configure festival to run another application for playing audio. In this case, we could use <code>aplay</code> to help us. In your <code>~/.festivalrc</code> 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)

<code>$SR</code> is the sampling rate, and <code>$FILE</code> is the audio data file generated by festival for playback.

== TeamSpeak ==

TeamSpeak works with <code>aoss</code> and <code>artsd</code> / <code>artsdsp</code>. It does not work with <code>esd</code> / <code>esddsp</code>, because <code>esd</code> does not seem to handle recording properly.

=== <code>aoss</code> ===

To run TeamSpeak, do:

$ aoss TeamSpeak

=== <code>arts</code> ===

You have to run <code>artsd</code> with <code>-d</code>, enabling full-duplex. So:

$ artsd -d -D plug:duplex

You'll need this [[ #~/.asoundrc ]] as well.

Then you have you run TeamSpeak.bin, instead of TeamSpeak, because <code>artsdsp</code> can only handle binary. You will also need to have LD_LIBRARY_PATH set to where TeamSpeak is installed. For example, if you have TeamSpeak installed at /opt/TeamSpeak/, then you should run:

$ LD_LIBRARY_PATH=/opt/TeamSpeak artsdsp /opt/TeamSpeak.bin

== ~/.asoundrc ==

With the above setup, you shouldn't need a custom ALSA configuration. But just in case, here is a simple <code>~/.asoundrc</code> to get you started:

<pre>
pcm.duplex {
type asym
playback.pcm "dmix"
capture.pcm "dsnoop"
}

pcm.!default {
type plug
slave.pcm "duplex"
}
</pre>

This is the same as specifying "<code>plug:duplex</code>" as the audio device for all applications, for instance:

<pre>
$ aplay -D plug:duplex test.wav

$ arecord -D plug:duplex test.wav

$ esd -d plug:duplex

$ artsd -d -D plug:duplex
</pre>

So with this configuration, you do not have to specify which ALSA device applications should use. As long as the application uses ALSA, it will be using the <code>dmix</code> and <code>dsnoop</code> plugins. (FlightGear/OpenAL for example, you could leave out the <code>alsa-out-device</code> in the <code>~/.openalrc</code>)

== GNOME and KDE ==

If you're using GNOME or KDE, you will probably have <code>esd</code> or <code>artsd</code> running already. In this case, you may also want to try this [[ #~/.asoundrc ]], which set <code>dmix</code> and <code>dsnoop</code> as the default to use for ALSA. You need to restart <code>esd</code> or <code>artsd</code> after making changes to <code>~/.asoundrc</code>. Make sure your <code>esd</code> or <code>artsd</code> is using ALSA, too.

(TODO: Anyone who uses GNOME or KDE could add more descriptions here, thanks)

== When things don't work ==

* Try this [[ #~/.asoundrc ]]

* <code>aoss</code> honours your ALSA configurations, and hence your <code>~/.asoundrc</code>. You want to make sure it is correct. Use <code>aplay</code> and <code>arecord</code> to test your setup.

* Any other thing to try is to temporarily rename or move away your <code>~/.asoundrc</code>, and then test everything again.

* See http://gentoo-wiki.com/HOWTO_ALSA_sound_mixer_aka_dmix (even if you're not using Gentoo). It's a pretty detailed HOWTO with ALSA audio including <code>dmix</code> and <code>dsnoop</code> configurations.

Linux software audio mixing with FlightGear

2006-06-17T10:46:09Z

Pigeon: /* ESD */

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 (<code>dmix</code> and <code>dsnoop</code> plugin).

== Audio mixing what? ==

One of the most common issues with soundcard and Linux is when you can only have one application playing sound at a time on some systems. This happens when the soundcard itself does not do audio mixing (i.e. hardware mixing).

Audio mixing allows multiple audio (PCM) streams to be "mixed" together and to be played at the same time. It is generally better and more efficient for a soundcard, if available, to do audio mixing in the hardware.

Software audio mixing is useful when you have a soundcard not capable of doing hardware mixing. Under Linux, software mixing can be done by ALSA's <code>dmix</code> / <code>dsnoop</code> plugin, or by userspace applications, like ESD and ARTS. Software uses your CPU to do the work and mixes multiple audio streams into one, before passing the audio data onto your soundcard for playback.

On Windows, software mixing is enabled by default transparently. Because of this, most people would have no idea about the capability of their sound cards in the Windows world. This is debatable whether this is good or bad, and is out of scope of this article.

With ALSA, an easy to test whether your soundcard supports hardware mixing or not would be running this following twice, say in two different terminals:

$ aplay -D hw:0,0 test.wav

This tells <code>aplay</code>, the ALSA audio player, to play the file <code>test.wav</code> using the first sound hardware directly, without using any plugin or any software mixing. For a soundcard without hardware mixing support, the second <code>aplay</code> would fail, and might look like this:

$ aplay -D hw:0,0 test.wav
aplay: main:547: audio open error: Device or resource busy

You could also find out from ALSA's driver info, by doing:

$ cat /proc/asound/pcm
00-00: Intel ICH : Intel 82801DB-ICH4 : playback 1 : capture 1
00-01: Intel ICH - MIC ADC : Intel 82801DB-ICH4 - MIC ADC : capture 1
00-02: Intel ICH - MIC2 ADC : Intel 82801DB-ICH4 - MIC2 ADC : capture 1
00-03: Intel ICH - ADC2 : Intel 82801DB-ICH4 - ADC2 : capture 1
00-04: Intel ICH - IEC958 : Intel 82801DB-ICH4 - IEC958 : playback 1
01-00: Intel ICH - Modem : Intel 82801DB-ICH4 Modem - Modem : playback 1 : capture 1

Notice the first line, "<code>playback 1</code>", indicating the device only supports one PCM audio playback at any time.

With a soundcard that supports hardware audio mixing, the same check looks like this:

$ cat /proc/asound/pcm
00-00: emu10k1 : EMU10K1 : playback 32 : capture 1
00-01: emu10k1 mic : EMU10K1 MIC : capture 1
00-02: emu10k1 efx : EMU10K1 EFX : playback 8 : capture 1

As you can see, the first line suggests this device supports 32 simultaneous PCM audio playback.

== Prerequisites ==

This article assumes you have a basic understanding and knowledge of Linux. For instance:

* <code>~/</code> refers to your HOME directory. If your user name is <code>blah</code>, then <code>~/</code> normally would be <code>/home/blah/</code>. And so <code>~/.asoundrc</code> would mean <code>/home/blah/.asoundrc</code>

* Files with names starting with a dot (".") are normally considered as hidden files. If you're using some sort of file manager application, remember to turn on or enable showing these hidden files.

* If a "dot rc" file (e.g. <code>.asoundrc</code>, <code>.openalrc</code>) does not exist, simply creates it.

This article assumes you have ALSA setup and working with your soundcard(s).

== The concept ==

It is simple. You want to get all the applications to use the ALSA <code>dmix</code> plugin for PCM audio playback, and sometimes also the <code>dsnoop</code> plugin for audio recording.

According to ALSA, <code>dmix</code> 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. <code>.asoundrc</code>) 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 <code>"plug:dmix"</code>. For example, with the ALSA command line player <code>aplay</code>, you run:

$ aplay -D "plug:dmix" test.wav

It's a good idea to run this to test if your <code>dmix</code> works.

For applications which does not have ALSA support (i.e. using OSS), you have a few choices:

; <code>aoss</code> : A wrapper script to run any application to use ALSA OSS. This works using simply via <code>LD_PRELOAD</code> to preload <code>libaoss.so</code>. It *seems* to use <code>dmix</code> if available automatically.

; <code>esd</code> : A software audio mixing daemon, typically shipped with GNOME. You can use its wrapper <code>esddsp</code> with other applications. You could run:
$ esd -d plug:dmix

; <code>artsd</code> : Another software audio mixing daemon, typically shipped with KDE. You can use its wrapper <code>artsdsp</code> 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 <code>aoss</code> and <code>artsd</code>. If possible it's a good idea to try all three approaches to get an OSS application to do ALSA.

<code>esd</code> does not seem to handle recording properly. So if you have an OSS application which does audio recording (say TeamSpeak), <code>esd</code> / <code>esddsp</code> 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 <code>/dev/dsp</code> (or <code>/dev/dsp0</code>, <code>/dev/dsp1</code>, etc), then it is probably using OSS. With ALSA, you normally specify an audio device using a string, which might look something like "<code>hw:0,0</code>" or "<code>plug:dmix</code>", or sometimes "<code>ALSA:default</code>", depending on the application itself.

=== <code>ldd</code> ===

<code>ldd</code> prints what shared libraries an application depends on.

Take <code>aplay</code> 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 <code>libasound.so.2</code>, which is the ALSA library, which *possibly* means <code>aplay</code> *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 <code>mplayer</code> and <code>xine</code>, which can do audio playback using many different audio libraries/approaches (OSS, ALSA, ESD, ARTS, and more).

=== <code>strace</code> ===

<code>strace</code> is a rather powerful tool, which traces and prints system calls of a running application.

Take <code>mpg123</code> 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 <code>open()</code> of this running instance of <code>mpg123</code>. As you can see it is opening <code>/dev/dsp</code>, which hints it is using OSS.

For an ALSA application, you will see a lot of <code>open()</code> calls to devices like <code>/dev/snd/controlC0</code>, <code>/dev/aloadC2</code>, <code>/dev/snd/pcmC0D0p</code>, etc. (Try <code>strace</code> with <code>aplay</code>!)

== FlightGear ==

FlightGear uses OpenAL (via SimGear) for audio playback, and OpenAL supports ALSA, ESD and ARTS. However you have to make sure your OpenAL is built with the audio support you need. Run <code>configure --help</code> if you are building your own OpenAL.

To get OpenAL to use a particular ALSA device, put these in your <code>~/.openalrc</code>

(define devices '(alsa))
(define alsa-out-device "plug:dmix")

To get OpenAL to use ESD:

(define devices '(esd))

And to get OpenAL to use ARTS:

(define devices '(arts))

== Festival ==

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 <code>~/.festivalrc</code>:

(Parameter.set 'Audio_Method 'esdaudio)

And then run <code>festival</code> 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 <code>esddsp</code>, which means you would be running:

$ esddsp festival --server

Test your festival server by:

$ echo '(SayText "Hello")' | festival_client

=== Using the <code>Audio_Command</code> parameter ===

You can configure festival to run another application for playing audio. In this case, we could use <code>aplay</code> to help us. In your <code>~/.festivalrc</code> 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)

<code>$SR</code> is the sampling rate, and <code>$FILE</code> is the audio data file generated by festival for playback.

== TeamSpeak ==

TeamSpeak works with <code>aoss</code> and <code>artsd</code> / <code>artsdsp</code>. It does not work with <code>esd</code> / <code>esddsp</code>, because <code>esd</code> does not seem to handle recording properly.

=== <code>aoss</code> ===

To run TeamSpeak, do:

$ aoss TeamSpeak

=== <code>arts</code> ===

You have to run <code>artsd</code> with <code>-d</code>, enabling full-duplex. So:

$ artsd -d -D plug:duplex

You'll need this [[ ~/.asoundrc ]] as well.

Then you have you run TeamSpeak.bin, instead of TeamSpeak, because <code>artsdsp</code> can only handle binary. You will also need to have LD_LIBRARY_PATH set to where TeamSpeak is installed. For example, if you have TeamSpeak installed at /opt/TeamSpeak/, then you should run:

$ LD_LIBRARY_PATH=/opt/TeamSpeak artsdsp /opt/TeamSpeak.bin

== ~/.asoundrc ==

With the above setup, you shouldn't need a custom ALSA configuration. But just in case, here is a simple <code>~/.asoundrc</code> to get you started:

<pre>
pcm.duplex {
type asym
playback.pcm "dmix"
capture.pcm "dsnoop"
}

pcm.!default {
type plug
slave.pcm "duplex"
}
</pre>

This is the same as specifying "<code>plug:duplex</code>" as the audio device for all applications, for instance:

<pre>
$ aplay -D plug:duplex test.wav

$ arecord -D plug:duplex test.wav

$ esd -d plug:duplex

$ artsd -d -D plug:duplex
</pre>

So with this configuration, you do not have to specify which ALSA device applications should use. As long as the application uses ALSA, it will be using the <code>dmix</code> and <code>dsnoop</code> plugins. (FlightGear/OpenAL for example, you could leave out the <code>alsa-out-device</code> in the <code>~/.openalrc</code>)

== GNOME and KDE ==

If you're using GNOME or KDE, you will probably have <code>esd</code> or <code>artsd</code> running already. In this case, you may also want to try this [[ #~/.asoundrc ]], which set <code>dmix</code> and <code>dsnoop</code> as the default to use for ALSA. You need to restart <code>esd</code> or <code>artsd</code> after making changes to <code>~/.asoundrc</code>. Make sure your <code>esd</code> or <code>artsd</code> is using ALSA, too.

(TODO: Anyone who uses GNOME or KDE could add more descriptions here, thanks)

== When things don't work ==

* Try this [[ #~/.asoundrc ]]

* <code>aoss</code> honours your ALSA configurations, and hence your <code>~/.asoundrc</code>. You want to make sure it is correct. Use <code>aplay</code> and <code>arecord</code> to test your setup.

* Any other thing to try is to temporarily rename or move away your <code>~/.asoundrc</code>, and then test everything again.

* See http://gentoo-wiki.com/HOWTO_ALSA_sound_mixer_aka_dmix (even if you're not using Gentoo). It's a pretty detailed HOWTO with ALSA audio including <code>dmix</code> and <code>dsnoop</code> configurations.

Linux software audio mixing with FlightGear

2006-06-17T09:12:19Z

Pigeon:

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 (<code>dmix</code> and <code>dsnoop</code> plugin).

== Audio mixing what? ==

One of the most common issues with soundcard and Linux is when you can only have one application playing sound at a time on some systems. This happens when the soundcard itself does not do audio mixing (i.e. hardware mixing).

Audio mixing allows multiple audio (PCM) streams to be "mixed" together and to be played at the same time. It is generally better and more efficient for a soundcard, if available, to do audio mixing in the hardware.

Software audio mixing is useful when you have a soundcard not capable of doing hardware mixing. Under Linux, software mixing can be done by ALSA's <code>dmix</code> / <code>dsnoop</code> plugin, or by userspace applications, like ESD and ARTS. Software uses your CPU to do the work and mixes multiple audio streams into one, before passing the audio data onto your soundcard for playback.

On Windows, software mixing is enabled by default transparently. Because of this, most people would have no idea about the capability of their sound cards in the Windows world. This is debatable whether this is good or bad, and is out of scope of this article.

With ALSA, an easy to test whether your soundcard supports hardware mixing or not would be running this following twice, say in two different terminals:

$ aplay -D hw:0,0 test.wav

This tells <code>aplay</code>, the ALSA audio player, to play the file <code>test.wav</code> using the first sound hardware directly, without using any plugin or any software mixing. For a soundcard without hardware mixing support, the second <code>aplay</code> would fail, and might look like this:

$ aplay -D hw:0,0 test.wav
aplay: main:547: audio open error: Device or resource busy

You could also find out from ALSA's driver info, by doing:

$ cat /proc/asound/pcm
00-00: Intel ICH : Intel 82801DB-ICH4 : playback 1 : capture 1
00-01: Intel ICH - MIC ADC : Intel 82801DB-ICH4 - MIC ADC : capture 1
00-02: Intel ICH - MIC2 ADC : Intel 82801DB-ICH4 - MIC2 ADC : capture 1
00-03: Intel ICH - ADC2 : Intel 82801DB-ICH4 - ADC2 : capture 1
00-04: Intel ICH - IEC958 : Intel 82801DB-ICH4 - IEC958 : playback 1
01-00: Intel ICH - Modem : Intel 82801DB-ICH4 Modem - Modem : playback 1 : capture 1

Notice the first line, "<code>playback 1</code>", indicating the device only supports one PCM audio playback at any time.

With a soundcard that supports hardware audio mixing, the same check looks like this:

$ cat /proc/asound/pcm
00-00: emu10k1 : EMU10K1 : playback 32 : capture 1
00-01: emu10k1 mic : EMU10K1 MIC : capture 1
00-02: emu10k1 efx : EMU10K1 EFX : playback 8 : capture 1

As you can see, the first line suggests this device supports 32 simultaneous PCM audio playback.

== Prerequisites ==

This article assumes you have a basic understanding and knowledge of Linux. For instance:

* <code>~/</code> refers to your HOME directory. If your user name is <code>blah</code>, then <code>~/</code> normally would be <code>/home/blah/</code>. And so <code>~/.asoundrc</code> would mean <code>/home/blah/.asoundrc</code>

* Files with names starting with a dot (".") are normally considered as hidden files. If you're using some sort of file manager application, remember to turn on or enable showing these hidden files.

* If a "dot rc" file (e.g. <code>.asoundrc</code>, <code>.openalrc</code>) does not exist, simply creates it.

This article assumes you have ALSA setup and working with your soundcard(s).

== The concept ==

It is simple. You want to get all the applications to use the ALSA <code>dmix</code> plugin for PCM audio playback, and sometimes also the <code>dsnoop</code> plugin for audio recording.

According to ALSA, <code>dmix</code> 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. <code>.asoundrc</code>) 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 <code>"plug:dmix"</code>. For example, with the ALSA command line player <code>aplay</code>, you run:

$ aplay -D "plug:dmix" test.wav

It's a good idea to run this to test if your <code>dmix</code> works.

For applications which does not have ALSA support (i.e. using OSS), you have a few choices:

; <code>aoss</code> : A wrapper script to run any application to use ALSA OSS. This works using simply via <code>LD_PRELOAD</code> to preload <code>libaoss.so</code>. It *seems* to use <code>dmix</code> if available automatically.

; <code>esd</code> : A software audio mixing daemon, typically shipped with GNOME. You can use its wrapper <code>esddsp</code> with other applications. You could run:
$ esd -d plug:dmix

; <code>artsd</code> : Another software audio mixing daemon, typically shipped with KDE. You can use its wrapper <code>artsdsp</code> 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 <code>aoss</code> and <code>artsd</code>. If possible it's a good idea to try all three approaches to get an OSS application to do ALSA.

<code>esd</code> does not seem to handle recording properly. So if you have an OSS application which does audio recording (say TeamSpeak), <code>esd</code> / <code>esddsp</code> 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 <code>/dev/dsp</code> (or <code>/dev/dsp0</code>, <code>/dev/dsp1</code>, etc), then it is probably using OSS. With ALSA, you normally specify an audio device using a string, which might look something like "<code>hw:0,0</code>" or "<code>plug:dmix</code>", or sometimes "<code>ALSA:default</code>", depending on the application itself.

=== <code>ldd</code> ===

<code>ldd</code> prints what shared libraries an application depends on.

Take <code>aplay</code> 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 <code>libasound.so.2</code>, which is the ALSA library, which *possibly* means <code>aplay</code> *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 <code>mplayer</code> and <code>xine</code>, which can do audio playback using many different audio libraries/approaches (OSS, ALSA, ESD, ARTS, and more).

=== <code>strace</code> ===

<code>strace</code> is a rather powerful tool, which traces and prints system calls of a running application.

Take <code>mpg123</code> 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 <code>open()</code> of this running instance of <code>mpg123</code>. As you can see it is opening <code>/dev/dsp</code>, which hints it is using OSS.

For an ALSA application, you will see a lot of <code>open()</code> calls to devices like <code>/dev/snd/controlC0</code>, <code>/dev/aloadC2</code>, <code>/dev/snd/pcmC0D0p</code>, etc. (Try <code>strace</code> with <code>aplay</code>!)

== FlightGear ==

FlightGear uses OpenAL (via SimGear) for audio playback, and OpenAL supports ALSA, ESD and ARTS. However you have to make sure your OpenAL is built with the audio support you need. Run <code>configure --help</code> if you are building your own OpenAL.

To get OpenAL to use a particular ALSA device, put these in your <code>~/.openalrc</code>

(define devices '(alsa))
(define alsa-out-device "plug:dmix")

To get OpenAL to use ESD:

(define devices '(esd))

And to get OpenAL to use ARTS:

(define devices '(arts))

== Festival ==

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 <code>~/.festivalrc</code>:

(Parameter.set 'Audio_Method 'esdaudio)

And then run <code>festival</code> 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 <code>esddsp</code>, which means you would be running:

$ esddsp festival --server

=== Using the <code>Audio_Command</code> parameter ===

You can configure festival to run another application for playing audio. In this case, we could use <code>aplay</code> to help us. In your <code>~/.festivalrc</code> 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)

<code>$SR</code> is the sampling rate, and <code>$FILE</code> is the audio data file generated by festival for playback.

== TeamSpeak ==

TeamSpeak works with <code>aoss</code> and <code>artsd</code> / <code>artsdsp</code>. It does not work with <code>esd</code> / <code>esddsp</code>, because <code>esd</code> does not seem to handle recording properly.

=== <code>aoss</code> ===

To run TeamSpeak, do:

$ aoss TeamSpeak

=== <code>arts</code> ===

You have to run <code>artsd</code> with <code>-d</code>, enabling full-duplex. So:

$ artsd -d -D plug:duplex

You'll need this [[ ~/.asoundrc ]] as well.

Then you have you run TeamSpeak.bin, instead of TeamSpeak, because <code>artsdsp</code> can only handle binary. You will also need to have LD_LIBRARY_PATH set to where TeamSpeak is installed. For example, if you have TeamSpeak installed at /opt/TeamSpeak/, then you should run:

$ LD_LIBRARY_PATH=/opt/TeamSpeak artsdsp /opt/TeamSpeak.bin

== ~/.asoundrc ==

With the above setup, you shouldn't need a custom ALSA configuration. But just in case, here is a simple <code>~/.asoundrc</code> to get you started:

<pre>
pcm.duplex {
type asym
playback.pcm "dmix"
capture.pcm "dsnoop"
}

pcm.!default {
type plug
slave.pcm "duplex"
}
</pre>

This is the same as specifying "<code>plug:duplex</code>" as the audio device for all applications, for instance:

<pre>
$ aplay -D plug:duplex test.wav

$ arecord -D plug:duplex test.wav

$ esd -d plug:duplex

$ artsd -d -D plug:duplex
</pre>

So with this configuration, you do not have to specify which ALSA device applications should use. As long as the application uses ALSA, it will be using the <code>dmix</code> and <code>dsnoop</code> plugins. (FlightGear/OpenAL for example, you could leave out the <code>alsa-out-device</code> in the <code>~/.openalrc</code>)

== GNOME and KDE ==

If you're using GNOME or KDE, you will probably have <code>esd</code> or <code>artsd</code> running already. In this case, you may also want to try this [[ #~/.asoundrc ]], which set <code>dmix</code> and <code>dsnoop</code> as the default to use for ALSA. You need to restart <code>esd</code> or <code>artsd</code> after making changes to <code>~/.asoundrc</code>. Make sure your <code>esd</code> or <code>artsd</code> is using ALSA, too.

(TODO: Anyone who uses GNOME or KDE could add more descriptions here, thanks)

== When things don't work ==

* Try this [[ #~/.asoundrc ]]

* <code>aoss</code> honours your ALSA configurations, and hence your <code>~/.asoundrc</code>. You want to make sure it is correct. Use <code>aplay</code> and <code>arecord</code> to test your setup.

* Any other thing to try is to temporarily rename or move away your <code>~/.asoundrc</code>, and then test everything again.

* See http://gentoo-wiki.com/HOWTO_ALSA_sound_mixer_aka_dmix (even if you're not using Gentoo). It's a pretty detailed HOWTO with ALSA audio including <code>dmix</code> and <code>dsnoop</code> configurations.

Linux software audio mixing with FlightGear

2006-06-17T06:00:08Z

Pigeon: /* ~/.asoundrc */

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 (<code>dmix</code> and <code>dsnoop</code> plugin).

== Prerequisites ==

This article assumes you have a basic understanding and knowledge of Linux. For instance:

* <code>~/</code> refers to your HOME directory. If your user name is <code>blah</code>, then <code>~/</code> normally would be <code>/home/blah/</code>. And so <code>~/.asoundrc</code> would mean <code>/home/blah/.asoundrc</code>

* Files with names starting with a dot (".") are normally considered as hidden files. If you're using some sort of file manager application, remember to turn on or enable showing these hidden files.

* If a "dot rc" file (e.g. <code>.asoundrc</code>, <code>.openalrc</code>) does not exist, simply creates it.

This article assumes you have ALSA setup and working with your soundcard(s).

== The concept ==

It is simple. You want to get all the applications to use the ALSA <code>dmix</code> plugin for PCM audio playback, and sometimes also the <code>dsnoop</code> plugin for audio recording.

According to ALSA, <code>dmix</code> 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. <code>.asoundrc</code>) 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 <code>"plug:dmix"</code>. For example, with the ALSA command line player <code>aplay</code>, you run:

$ aplay -D "plug:dmix" test.wav

It's a good idea to run this to test if your <code>dmix</code> works.

For applications which does not have ALSA support (i.e. using OSS), you have a few choices:

; <code>aoss</code> : A wrapper script to run any application to use ALSA OSS. This works using simply via <code>LD_PRELOAD</code> to preload <code>libaoss.so</code>. It *seems* to use <code>dmix</code> if available automatically.

; <code>esd</code> : A software audio mixing daemon, typically shipped with GNOME. You can use its wrapper <code>esddsp</code> with other applications. You could run:
$ esd -d plug:dmix

; <code>artsd</code> : Another software audio mixing daemon, typically shipped with KDE. You can use its wrapper <code>artsdsp</code> 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 <code>aoss</code> and <code>artsd</code>. If possible it's a good idea to try all three approaches to get an OSS application to do ALSA.

<code>esd</code> does not seem to handle recording properly. So if you have an OSS application which does audio recording (say TeamSpeak), <code>esd</code> / <code>esddsp</code> 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 <code>/dev/dsp</code> (or <code>/dev/dsp0</code>, <code>/dev/dsp1</code>, etc), then it is probably using OSS. With ALSA, you normally specify an audio device using a string, which might look something like "<code>hw:0,0</code>" or "<code>plug:dmix</code>", or sometimes "<code>ALSA:default</code>", depending on the application itself.

=== <code>ldd</code> ===

<code>ldd</code> prints what shared libraries an application depends on.

Take <code>aplay</code> 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 <code>libasound.so.2</code>, which is the ALSA library, which *possibly* means <code>aplay</code> *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 <code>mplayer</code> and <code>xine</code>, which can do audio playback using many different audio libraries/approaches (OSS, ALSA, ESD, ARTS, and more).

=== <code>strace</code> ===

<code>strace</code> is a rather powerful tool, which traces and prints system calls of a running application.

Take <code>mpg123</code> 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 <code>open()</code> of this running instance of <code>mpg123</code>. As you can see it is opening <code>/dev/dsp</code>, which hints it is using OSS.

For an ALSA application, you will see a lot of <code>open()</code> calls to devices like <code>/dev/snd/controlC0</code>, <code>/dev/aloadC2</code>, <code>/dev/snd/pcmC0D0p</code>, etc. (Try <code>strace</code> with <code>aplay</code>!)

== FlightGear ==

FlightGear uses OpenAL (via SimGear) for audio playback, and OpenAL supports ALSA, ESD and ARTS. However you have to make sure your OpenAL is built with the audio support you need. Run <code>configure --help</code> if you are building your own OpenAL.

To get OpenAL to use a particular ALSA device, put these in your <code>~/.openalrc</code>

(define devices '(alsa))
(define alsa-out-device "plug:dmix")

To get OpenAL to use ESD:

(define devices '(esd))

And to get OpenAL to use ARTS:

(define devices '(arts))

== Festival ==

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 <code>~/.festivalrc</code>:

(Parameter.set 'Audio_Method 'esdaudio)

And then run <code>festival</code> 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 <code>esddsp</code>, which means you would be running:

$ esddsp festival --server

=== Using the <code>Audio_Command</code> parameter ===

You can configure festival to run another application for playing audio. In this case, we could use <code>aplay</code> to help us. In your <code>~/.festivalrc</code> 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)

<code>$SR</code> is the sampling rate, and <code>$FILE</code> is the audio data file generated by festival for playback.

== TeamSpeak ==

TeamSpeak works with <code>aoss</code> and <code>artsd</code> / <code>artsdsp</code>. It does not work with <code>esd</code> / <code>esddsp</code>, because <code>esd</code> does not seem to handle recording properly.

=== <code>aoss</code> ===

To run TeamSpeak, do:

$ aoss TeamSpeak

=== <code>arts</code> ===

You have to run <code>artsd</code> with <code>-d</code>, enabling full-duplex. So:

$ artsd -d -D plug:duplex

You'll need this [[ ~/.asoundrc ]] as well.

Then you have you run TeamSpeak.bin, instead of TeamSpeak, because <code>artsdsp</code> can only handle binary. You will also need to have LD_LIBRARY_PATH set to where TeamSpeak is installed. For example, if you have TeamSpeak installed at /opt/TeamSpeak/, then you should run:

$ LD_LIBRARY_PATH=/opt/TeamSpeak artsdsp /opt/TeamSpeak.bin

== ~/.asoundrc ==

With the above setup, you shouldn't need a custom ALSA configuration. But just in case, here is a simple <code>~/.asoundrc</code> to get you started:

<pre>
pcm.duplex {
type asym
playback.pcm "dmix"
capture.pcm "dsnoop"
}

pcm.!default {
type plug
slave.pcm "duplex"
}
</pre>

This is the same as specifying "<code>plug:duplex</code>" as the audio device for all applications, for instance:

<pre>
$ aplay -D plug:duplex test.wav

$ arecord -D plug:duplex test.wav

$ esd -d plug:duplex

$ artsd -d -D plug:duplex
</pre>

So with this configuration, you do not have to specify which ALSA device applications should use. As long as the application uses ALSA, it will be using the <code>dmix</code> and <code>dsnoop</code> plugins. (FlightGear/OpenAL for example, you could leave out the <code>alsa-out-device</code> in the <code>~/.openalrc</code>)

== GNOME and KDE ==

If you're using GNOME or KDE, you will probably have <code>esd</code> or <code>artsd</code> running already. In this case, you may also want to try this [[ #~/.asoundrc ]], which set <code>dmix</code> and <code>dsnoop</code> as the default to use for ALSA. You need to restart <code>esd</code> or <code>artsd</code> after making changes to <code>~/.asoundrc</code>. Make sure your <code>esd</code> or <code>artsd</code> is using ALSA, too.

(TODO: Anyone who uses GNOME or KDE could add more descriptions here, thanks)

== When things don't work ==

* Try this [[ #~/.asoundrc ]]

* <code>aoss</code> honours your ALSA configurations, and hence your <code>~/.asoundrc</code>. You want to make sure it is correct. Use <code>aplay</code> and <code>arecord</code> to test your setup.

* Any other thing to try is to temporarily rename or move away your <code>~/.asoundrc</code>, and then test everything again.

* See http://gentoo-wiki.com/HOWTO_ALSA_sound_mixer_aka_dmix (even if you're not using Gentoo). It's a pretty detailed HOWTO with ALSA audio including <code>dmix</code> and <code>dsnoop</code> configurations.

Linux software audio mixing with FlightGear

2006-06-17T05:54:45Z

Pigeon:

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 (<code>dmix</code> and <code>dsnoop</code> plugin).

== Prerequisites ==

This article assumes you have a basic understanding and knowledge of Linux. For instance:

* <code>~/</code> refers to your HOME directory. If your user name is <code>blah</code>, then <code>~/</code> normally would be <code>/home/blah/</code>. And so <code>~/.asoundrc</code> would mean <code>/home/blah/.asoundrc</code>

* Files with names starting with a dot (".") are normally considered as hidden files. If you're using some sort of file manager application, remember to turn on or enable showing these hidden files.

* If a "dot rc" file (e.g. <code>.asoundrc</code>, <code>.openalrc</code>) does not exist, simply creates it.

This article assumes you have ALSA setup and working with your soundcard(s).

== The concept ==

It is simple. You want to get all the applications to use the ALSA <code>dmix</code> plugin for PCM audio playback, and sometimes also the <code>dsnoop</code> plugin for audio recording.

According to ALSA, <code>dmix</code> 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. <code>.asoundrc</code>) 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 <code>"plug:dmix"</code>. For example, with the ALSA command line player <code>aplay</code>, you run:

$ aplay -D "plug:dmix" test.wav

It's a good idea to run this to test if your <code>dmix</code> works.

For applications which does not have ALSA support (i.e. using OSS), you have a few choices:

; <code>aoss</code> : A wrapper script to run any application to use ALSA OSS. This works using simply via <code>LD_PRELOAD</code> to preload <code>libaoss.so</code>. It *seems* to use <code>dmix</code> if available automatically.

; <code>esd</code> : A software audio mixing daemon, typically shipped with GNOME. You can use its wrapper <code>esddsp</code> with other applications. You could run:
$ esd -d plug:dmix

; <code>artsd</code> : Another software audio mixing daemon, typically shipped with KDE. You can use its wrapper <code>artsdsp</code> 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 <code>aoss</code> and <code>artsd</code>. If possible it's a good idea to try all three approaches to get an OSS application to do ALSA.

<code>esd</code> does not seem to handle recording properly. So if you have an OSS application which does audio recording (say TeamSpeak), <code>esd</code> / <code>esddsp</code> 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 <code>/dev/dsp</code> (or <code>/dev/dsp0</code>, <code>/dev/dsp1</code>, etc), then it is probably using OSS. With ALSA, you normally specify an audio device using a string, which might look something like "<code>hw:0,0</code>" or "<code>plug:dmix</code>", or sometimes "<code>ALSA:default</code>", depending on the application itself.

=== <code>ldd</code> ===

<code>ldd</code> prints what shared libraries an application depends on.

Take <code>aplay</code> 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 <code>libasound.so.2</code>, which is the ALSA library, which *possibly* means <code>aplay</code> *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 <code>mplayer</code> and <code>xine</code>, which can do audio playback using many different audio libraries/approaches (OSS, ALSA, ESD, ARTS, and more).

=== <code>strace</code> ===

<code>strace</code> is a rather powerful tool, which traces and prints system calls of a running application.

Take <code>mpg123</code> 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 <code>open()</code> of this running instance of <code>mpg123</code>. As you can see it is opening <code>/dev/dsp</code>, which hints it is using OSS.

For an ALSA application, you will see a lot of <code>open()</code> calls to devices like <code>/dev/snd/controlC0</code>, <code>/dev/aloadC2</code>, <code>/dev/snd/pcmC0D0p</code>, etc. (Try <code>strace</code> with <code>aplay</code>!)

== FlightGear ==

FlightGear uses OpenAL (via SimGear) for audio playback, and OpenAL supports ALSA, ESD and ARTS. However you have to make sure your OpenAL is built with the audio support you need. Run <code>configure --help</code> if you are building your own OpenAL.

To get OpenAL to use a particular ALSA device, put these in your <code>~/.openalrc</code>

(define devices '(alsa))
(define alsa-out-device "plug:dmix")

To get OpenAL to use ESD:

(define devices '(esd))

And to get OpenAL to use ARTS:

(define devices '(arts))

== Festival ==

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 <code>~/.festivalrc</code>:

(Parameter.set 'Audio_Method 'esdaudio)

And then run <code>festival</code> 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 <code>esddsp</code>, which means you would be running:

$ esddsp festival --server

=== Using the <code>Audio_Command</code> parameter ===

You can configure festival to run another application for playing audio. In this case, we could use <code>aplay</code> to help us. In your <code>~/.festivalrc</code> 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)

<code>$SR</code> is the sampling rate, and <code>$FILE</code> is the audio data file generated by festival for playback.

== TeamSpeak ==

TeamSpeak works with <code>aoss</code> and <code>artsd</code> / <code>artsdsp</code>. It does not work with <code>esd</code> / <code>esddsp</code>, because <code>esd</code> does not seem to handle recording properly.

=== <code>aoss</code> ===

To run TeamSpeak, do:

$ aoss TeamSpeak

=== <code>arts</code> ===

You have to run <code>artsd</code> with <code>-d</code>, enabling full-duplex. So:

$ artsd -d -D plug:duplex

You'll need this [[ ~/.asoundrc ]] as well.

Then you have you run TeamSpeak.bin, instead of TeamSpeak, because <code>artsdsp</code> can only handle binary. You will also need to have LD_LIBRARY_PATH set to where TeamSpeak is installed. For example, if you have TeamSpeak installed at /opt/TeamSpeak/, then you should run:

$ LD_LIBRARY_PATH=/opt/TeamSpeak artsdsp /opt/TeamSpeak.bin

== ~/.asoundrc ==

With the above setup, you shouldn't need a custom ALSA configuration. But just in case, here is a simple <code>~/.asoundrc</code> to get you started:

<pre>
pcm.duplex {
type asym
playback.pcm "dmix"
capture.pcm "dsnoop"
}

pcm.!default {
type plug
slave.pcm "duplex"
}
</pre>

This is the same as specifying "<code>plug:duplex</code>" as the audio device for all applications, for instance:

<pre>
$ aplay -D plug:duplex test.wav

$ arecord -D plug:duplex test.wav

$ esd -d plug:duplex

$ artsd -d -D plug:duplex
</pre>

== GNOME and KDE ==

If you're using GNOME or KDE, you will probably have <code>esd</code> or <code>artsd</code> running already. In this case, you may also want to try this [[ #~/.asoundrc ]], which set <code>dmix</code> and <code>dsnoop</code> as the default to use for ALSA. You need to restart <code>esd</code> or <code>artsd</code> after making changes to <code>~/.asoundrc</code>. Make sure your <code>esd</code> or <code>artsd</code> is using ALSA, too.

(TODO: Anyone who uses GNOME or KDE could add more descriptions here, thanks)

== When things don't work ==

* Try this [[ #~/.asoundrc ]]

* <code>aoss</code> honours your ALSA configurations, and hence your <code>~/.asoundrc</code>. You want to make sure it is correct. Use <code>aplay</code> and <code>arecord</code> to test your setup.

* Any other thing to try is to temporarily rename or move away your <code>~/.asoundrc</code>, and then test everything again.

* See http://gentoo-wiki.com/HOWTO_ALSA_sound_mixer_aka_dmix (even if you're not using Gentoo). It's a pretty detailed HOWTO with ALSA audio including <code>dmix</code> and <code>dsnoop</code> configurations.

Linux software audio mixing with FlightGear

2006-06-17T05:50:18Z

Pigeon: /* FlightGear */

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 (<code>dmix</code> and <code>dsnoop</code> plugin).

== Prerequisites ==

This article assumes you have a basic understanding and knowledge of Linux. For instance:

* <code>~/</code> refers to your HOME directory. If your user name is <code>blah</code>, then <code>~/</code> normally would be <code>/home/blah/</code>. And so <code>~/.asoundrc</code> would mean <code>/home/blah/.asoundrc</code>

* Files with names starting with a dot (".") are normally considered as hidden files. If you're using some sort of file manager application, remember to turn on or enable showing these hidden files.

* If a "dot rc" file (e.g. <code>.asoundrc</code>, <code>.openalrc</code>) does not exist, simply creates it.

This article assumes you have ALSA setup and working with your soundcard(s).

== The concept ==

It is simple. You want to get all the applications to use the ALSA <code>dmix</code> plugin for PCM audio playback, and sometimes also the <code>dsnoop</code> plugin for audio recording.

According to ALSA, <code>dmix</code> 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. <code>.asoundrc</code>) 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 <code>"plug:dmix"</code>. For example, with the ALSA command line player <code>aplay</code>, you run:

$ aplay -D "plug:dmix" test.wav

It's a good idea to run this to test if your <code>dmix</code> works.

For applications which does not have ALSA support (i.e. using OSS), you have a few choices:

; <code>aoss</code> : A wrapper script to run any application to use ALSA OSS. This works using simply via <code>LD_PRELOAD</code> to preload <code>libaoss.so</code>. It *seems* to use <code>dmix</code> if available automatically.

; <code>esd</code> : A software audio mixing daemon, typically shipped with GNOME. You can use its wrapper <code>esddsp</code> with other applications. You could run:
$ esd -d plug:dmix

; <code>artsd</code> : Another software audio mixing daemon, typically shipped with KDE. You can use its wrapper <code>artsdsp</code> 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 <code>aoss</code> and <code>artsd</code>. If possible it's a good idea to try all three approaches to get an OSS application to do ALSA.

<code>esd</code> does not seem to handle recording properly. So if you have an OSS application which does audio recording (say TeamSpeak), <code>esd</code> / <code>esddsp</code> 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 <code>/dev/dsp</code> (or <code>/dev/dsp0</code>, <code>/dev/dsp1</code>, etc), then it is probably using OSS. With ALSA, you normally specify an audio device using a string, which might look something like "<code>hw:0,0</code>" or "<code>plug:dmix</code>", or sometimes "<code>ALSA:default</code>", depending on the application itself.

=== <code>ldd</code> ===

<code>ldd</code> prints what shared libraries an application depends on.

Take <code>aplay</code> 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 <code>libasound.so.2</code>, which is the ALSA library, which *possibly* means <code>aplay</code> *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 <code>mplayer</code> and <code>xine</code>, which can do audio playback using many different audio libraries/approaches (OSS, ALSA, ESD, ARTS, and more).

=== <code>strace</code> ===

<code>strace</code> is a rather powerful tool, which traces and prints system calls of a running application.

Take <code>mpg123</code> 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 <code>open()</code> of this running instance of <code>mpg123</code>. As you can see it is opening <code>/dev/dsp</code>, which hints it is using OSS.

For an ALSA application, you will see a lot of <code>open()</code> calls to devices like <code>/dev/snd/controlC0</code>, <code>/dev/aloadC2</code>, <code>/dev/snd/pcmC0D0p</code>, etc. (Try <code>strace</code> with <code>aplay</code>!)

== FlightGear ==

FlightGear uses OpenAL (via SimGear) for audio playback, and OpenAL supports ALSA, ESD and ARTS. However you have to make sure your OpenAL is built with the audio support you need. Run <code>configure --help</code> if you are building your own OpenAL.

To get OpenAL to use a particular ALSA device, put these in your <code>~/.openalrc</code>

(define devices '(alsa))
(define alsa-out-device "plug:dmix")

To get OpenAL to use ESD:

(define devices '(esd))

And to get OpenAL to use ARTS:

(define devices '(arts))

== Festival ==

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 <code>~/.festivalrc</code>:

(Parameter.set 'Audio_Method 'esdaudio)

And then run <code>festival</code> 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 <code>esddsp</code>, which means you would be running:

$ esddsp festival --server

=== Using the <code>Audio_Command</code> parameter ===

You can configure festival to run another application for playing audio. In this case, we could use <code>aplay</code> to help us. In your <code>~/.festivalrc</code> 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)

<code>$SR</code> is the sampling rate, and <code>$FILE</code> is the audio data file generated by festival for playback.

== TeamSpeak ==

TeamSpeak works with <code>aoss</code> and <code>artsd</code> / <code>artsdsp</code>. It does not work with <code>esd</code> / <code>esddsp</code>, because <code>esd</code> does not seem to handle recording properly.

=== <code>aoss</code> ===

To run TeamSpeak, do:

$ aoss TeamSpeak

=== <code>arts</code> ===

You have to run <code>artsd</code> with <code>-d</code>, enabling full-duplex. So:

$ artsd -d -D plug:duplex

You'll need this [[ ~/.asoundrc ]] as well.

Then you have you run TeamSpeak.bin, instead of TeamSpeak, because <code>artsdsp</code> can only handle binary. You will also need to have LD_LIBRARY_PATH set to where TeamSpeak is installed. For example, if you have TeamSpeak installed at /opt/TeamSpeak/, then you should run:

$ LD_LIBRARY_PATH=/opt/TeamSpeak artsdsp /opt/TeamSpeak.bin

== ~/.asoundrc ==

With the above setup, you shouldn't need a custom ALSA configuration. But just in case, here is a simple <code>~/.asoundrc</code> to get you started:

<pre>
pcm.duplex {
type asym
playback.pcm "dmix"
capture.pcm "dsnoop"
}

pcm.!default {
type plug
slave.pcm "duplex"
}
</pre>

This is the same as specifying "plug:duplex" as the audio device for all applications, for instance:

<pre>
$ aplay -D plug:duplex test.wav

$ arecord -D plug:duplex test.wav

$ esd -d plug:duplex

$ artsd -d -D plug:duplex
</pre>

== GNOME and KDE ==

If you're using GNOME or KDE, you will probably have <code>esd</code> or <code>artsd</code> running already. In this case, you may also want to try this [[ #~/.asoundrc ]], which set <code>dmix</code> and <code>dsnoop</code> as the default to use for ALSA. Make sure your <code>esd</code> or <code>artsd</code> is using ALSA, too.

(TODO: Anyone who uses GNOME or KDE could add more descriptions here, thanks)

== When things don't work ==

* Try this [[ #~/.asoundrc ]]

* <code>aoss</code> honours your ALSA configurations, and hence your <code>~/.asoundrc</code>. You want to make sure it is correct. Use <code>aplay</code> and <code>arecord</code> to test your setup.

* Any other thing to try is to temporarily rename or move away your <code>~/.asoundrc</code>, and then test everything again.

* See http://gentoo-wiki.com/HOWTO_ALSA_sound_mixer_aka_dmix (even if you're not using Gentoo). It's a pretty detailed HOWTO with ALSA audio including <code>dmix</code> and <code>dsnoop</code> configurations.

Linux software audio mixing with FlightGear

2006-06-17T05:46:51Z

Pigeon:

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 (<code>dmix</code> and <code>dsnoop</code> plugin).

== Prerequisites ==

This article assumes you have a basic understanding and knowledge of Linux. For instance:

* <code>~/</code> refers to your HOME directory. If your user name is <code>blah</code>, then <code>~/</code> normally would be <code>/home/blah/</code>. And so <code>~/.asoundrc</code> would mean <code>/home/blah/.asoundrc</code>

* Files with names starting with a dot (".") are normally considered as hidden files. If you're using some sort of file manager application, remember to turn on or enable showing these hidden files.

* If a "dot rc" file (e.g. <code>.asoundrc</code>, <code>.openalrc</code>) does not exist, simply creates it.

This article assumes you have ALSA setup and working with your soundcard(s).

== The concept ==

It is simple. You want to get all the applications to use the ALSA <code>dmix</code> plugin for PCM audio playback, and sometimes also the <code>dsnoop</code> plugin for audio recording.

According to ALSA, <code>dmix</code> 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. <code>.asoundrc</code>) 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 <code>"plug:dmix"</code>. For example, with the ALSA command line player <code>aplay</code>, you run:

$ aplay -D "plug:dmix" test.wav

It's a good idea to run this to test if your <code>dmix</code> works.

For applications which does not have ALSA support (i.e. using OSS), you have a few choices:

; <code>aoss</code> : A wrapper script to run any application to use ALSA OSS. This works using simply via <code>LD_PRELOAD</code> to preload <code>libaoss.so</code>. It *seems* to use <code>dmix</code> if available automatically.

; <code>esd</code> : A software audio mixing daemon, typically shipped with GNOME. You can use its wrapper <code>esddsp</code> with other applications. You could run:
$ esd -d plug:dmix

; <code>artsd</code> : Another software audio mixing daemon, typically shipped with KDE. You can use its wrapper <code>artsdsp</code> 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 <code>aoss</code> and <code>artsd</code>. If possible it's a good idea to try all three approaches to get an OSS application to do ALSA.

<code>esd</code> does not seem to handle recording properly. So if you have an OSS application which does audio recording (say TeamSpeak), <code>esd</code> / <code>esddsp</code> 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 <code>/dev/dsp</code> (or <code>/dev/dsp0</code>, <code>/dev/dsp1</code>, etc), then it is probably using OSS. With ALSA, you normally specify an audio device using a string, which might look something like "<code>hw:0,0</code>" or "<code>plug:dmix</code>", or sometimes "<code>ALSA:default</code>", depending on the application itself.

=== <code>ldd</code> ===

<code>ldd</code> prints what shared libraries an application depends on.

Take <code>aplay</code> 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 <code>libasound.so.2</code>, which is the ALSA library, which *possibly* means <code>aplay</code> *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 <code>mplayer</code> and <code>xine</code>, which can do audio playback using many different audio libraries/approaches (OSS, ALSA, ESD, ARTS, and more).

=== <code>strace</code> ===

<code>strace</code> is a rather powerful tool, which traces and prints system calls of a running application.

Take <code>mpg123</code> 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 <code>open()</code> of this running instance of <code>mpg123</code>. As you can see it is opening <code>/dev/dsp</code>, which hints it is using OSS.

For an ALSA application, you will see a lot of <code>open()</code> calls to devices like <code>/dev/snd/controlC0</code>, <code>/dev/aloadC2</code>, <code>/dev/snd/pcmC0D0p</code>, etc. (Try <code>strace</code> with <code>aplay</code>!)

== FlightGear ==

FlightGear uses OpenAL (via SimGear) for audio playback, and OpenAL supports ALSA, ESD and ARTS. Though, you have to make sure your OpenAL is built with the audio support you need. Run <code>configure --help</code> if you are building your own OpenAL.

To get OpenAL to use a particular ALSA device, put these in your <code>~/.openalrc</code>

(define devices '(alsa))
(define alsa-out-device "plug:dmix")

To get OpenAL to use ESD:

(define devices '(esd))

And to get OpenAL to use ARTS:

(define devices '(arts))

== Festival ==

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 <code>~/.festivalrc</code>:

(Parameter.set 'Audio_Method 'esdaudio)

And then run <code>festival</code> 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 <code>esddsp</code>, which means you would be running:

$ esddsp festival --server

=== Using the <code>Audio_Command</code> parameter ===

You can configure festival to run another application for playing audio. In this case, we could use <code>aplay</code> to help us. In your <code>~/.festivalrc</code> 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)

<code>$SR</code> is the sampling rate, and <code>$FILE</code> is the audio data file generated by festival for playback.

== TeamSpeak ==

TeamSpeak works with <code>aoss</code> and <code>artsd</code> / <code>artsdsp</code>. It does not work with <code>esd</code> / <code>esddsp</code>, because <code>esd</code> does not seem to handle recording properly.

=== <code>aoss</code> ===

To run TeamSpeak, do:

$ aoss TeamSpeak

=== <code>arts</code> ===

You have to run <code>artsd</code> with <code>-d</code>, enabling full-duplex. So:

$ artsd -d -D plug:duplex

You'll need this [[ ~/.asoundrc ]] as well.

Then you have you run TeamSpeak.bin, instead of TeamSpeak, because <code>artsdsp</code> can only handle binary. You will also need to have LD_LIBRARY_PATH set to where TeamSpeak is installed. For example, if you have TeamSpeak installed at /opt/TeamSpeak/, then you should run:

$ LD_LIBRARY_PATH=/opt/TeamSpeak artsdsp /opt/TeamSpeak.bin

== ~/.asoundrc ==

With the above setup, you shouldn't need a custom ALSA configuration. But just in case, here is a simple <code>~/.asoundrc</code> to get you started:

<pre>
pcm.duplex {
type asym
playback.pcm "dmix"
capture.pcm "dsnoop"
}

pcm.!default {
type plug
slave.pcm "duplex"
}
</pre>

This is the same as specifying "plug:duplex" as the audio device for all applications, for instance:

<pre>
$ aplay -D plug:duplex test.wav

$ arecord -D plug:duplex test.wav

$ esd -d plug:duplex

$ artsd -d -D plug:duplex
</pre>

== GNOME and KDE ==

If you're using GNOME or KDE, you will probably have <code>esd</code> or <code>artsd</code> running already. In this case, you may also want to try this [[ #~/.asoundrc ]], which set <code>dmix</code> and <code>dsnoop</code> as the default to use for ALSA. Make sure your <code>esd</code> or <code>artsd</code> is using ALSA, too.

(TODO: Anyone who uses GNOME or KDE could add more descriptions here, thanks)

== When things don't work ==

* Try this [[ #~/.asoundrc ]]

* <code>aoss</code> honours your ALSA configurations, and hence your <code>~/.asoundrc</code>. You want to make sure it is correct. Use <code>aplay</code> and <code>arecord</code> to test your setup.

* Any other thing to try is to temporarily rename or move away your <code>~/.asoundrc</code>, and then test everything again.

* See http://gentoo-wiki.com/HOWTO_ALSA_sound_mixer_aka_dmix (even if you're not using Gentoo). It's a pretty detailed HOWTO with ALSA audio including <code>dmix</code> and <code>dsnoop</code> configurations.

Linux software audio mixing with FlightGear

2006-06-17T05:09:17Z

Pigeon: /* The concept */

Linux software audio mixing with FlightGear

2006-06-17T05:06:41Z

Pigeon:

Linux software audio mixing with FlightGear

2006-06-17T02:33:56Z

Pigeon: /* When things don't work */

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 <code>dmix</code> plugin).

== Prerequisites ==

This article assumes you have a basic understanding and knowledge of Linux. For instance:

* <code>~/</code> refers to your HOME directory. If your user name is <code>blah</code>, then <code>~/</code> normally would be <code>/home/blah/</code>. And so <code>~/.asoundrc</code> would mean <code>/home/blah/.asoundrc</code>

* Files with names starting with a dot (".") are normally considered as hidden files. If you're using some sort of file manager application, remember to turn on or enable showing these hidden files.

* If a "dot rc" file (e.g. <code>.asoundrc</code>, <code>.openalrc</code>) does not exist, simply creates it.

This article assumes you have ALSA setup and working with your soundcard(s).

== The concept ==

It is simple. You want to get all the applications to use ALSA <code>dmix</code> plugin for PCM audio playback. According to ALSA, <code>dmix</code> 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. <code>.asoundrc</code>) 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 <code>"plug:dmix"</code>. For example, with the ALSA command line player <code>aplay</code>, you run:

aplay -D "plug:dmix" test.wav

It's a good idea to run this to test if your <code>dmix</code> works.

For applications which does not have ALSA support (i.e. using OSS), you have a few choices:

; <code>aoss</code> : A wrapper script to run any application to use ALSA OSS. This works using simply via <code>LD_PRELOAD</code> to preload <code>libaoss.so</code>. It *seems* to use <code>dmix</code> if available automatically.

; <code>esd</code> : A software audio mixing daemon, typically shipped with GNOME. You can use its wrapper <code>esddsp</code> with other applications. You could run:
esd -d plug:dmix

; <code>artsd</code> : Another software audio mixing daemon, typically shipped with KDE. You can use its wrapper <code>artsdsp</code> 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 <code>aoss</code> and <code>artsd</code>. If possible it's a good idea to try all three approaches to get an OSS application to do ALSA.

<code>esd</code> does not seem to handle recording properly. So if you have an OSS application which does audio recording (say TeamSpeak), <code>esd</code> / <code>esddsp</code> 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 <code>/dev/dsp</code> (or <code>/dev/dsp0</code>, <code>/dev/dsp1</code>, etc), then it is probably using OSS. With ALSA, you normally specify an audio device using a string, which might look something like "<code>hw:0,0</code>" or "<code>plug:dmix</code>", or sometimes "<code>ALSA:default</code>", depending on the application itself.

=== <code>ldd</code> ===

<code>ldd</code> prints what shared libraries an application depends on.

Take <code>aplay</code> 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 <code>libasound.so.2</code>, which is the ALSA library, which *possibly* means <code>aplay</code> *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 <code>mplayer</code> and <code>xine</code>, which can do audio playback using many different audio libraries/approaches (OSS, ALSA, ESD, ARTS, and more).

=== <code>strace</code> ===

<code>strace</code> is a rather powerful tool, which traces and prints system calls of a running application.

Take <code>mpg123</code> 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 <code>open()</code> of this running instance of <code>mpg123</code>. As you can see it is opening <code>/dev/dsp</code>, which hints it is using OSS.

For an ALSA application, you will see a lot of <code>open()</code> calls to devices like <code>/dev/snd/controlC0</code>, <code>/dev/aloadC2</code>, <code>/dev/snd/pcmC0D0p</code>, etc. (Try <code>strace</code> with <code>aplay</code>!)

== FlightGear ==

FlightGear uses OpenAL (via SimGear) for audio playback, and OpenAL supports ALSA, ESD and ARTS. Though, you have to make sure your OpenAL is built with the audio support you need. Run <code>configure --help</code> if you are building your own OpenAL.

To get OpenAL to use a particular ALSA device, put these in your <code>~/.openalrc</code>

(define devices '(alsa))
(define alsa-out-device "plug:dmix")

To get OpenAL to use ESD:

(define devices '(esd))

And to get OpenAL to use ARTS:

(define devices '(arts))

== 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 <code>~/.festivalrc</code>:

(Parameter.set 'Audio_Method 'esdaudio)

And then run <code>festival</code> 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 <code>esddsp</code>, which means you would be running:

esddsp festival --server

=== Using the <code>Audio_Command</code> parameter ===

You can configure festival to run another application for playing audio. In this case, we could use <code>aplay</code> to help us. In your <code>~/.festivalrc</code> 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)

<code>$SR</code> is the sampling rate, and <code>$FILE</code> is the audio data file generated by festival for playback.

== TeamSpeak to use ALSA ==

TeamSpeak works with <code>aoss</code>, with minor issues. Sometimes it gets stuck on exit, for example.

TeamSpeak works with <code>artsd</code> / <code>artsdsp</code> 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 <code>esd</code> / <code>esddsp</code>, because <code>esd</code> does not seem to handle recording properly.

To run TeamSpeak, do:

aoss TeamSpeak

== When things don't work ==

* <code>aoss</code> honours your ALSA configurations, and hence your <code>~/.asoundrc</code>. You want to make sure it is correct. Use <code>aplay</code> and <code>arecord</code> to test your setup.

* Any other thing to try is to temporarily rename or move away your <code>~/.asoundrc</code>, and then test everything again.

* Try the following <code>.asoundrc</code>:

<pre>
pcm.duplex {
type asym
playback.pcm "dmix"
capture.pcm "dsnoop"
}

pcm.!default {
type plug
slave.pcm "duplex"
}
</pre>

* See http://gentoo-wiki.com/HOWTO_ALSA_sound_mixer_aka_dmix (even if you're not using Gentoo). It's a pretty detailed HOWTO with ALSA audio including <code>dmix</code> and <code>dsnoop</code> configurations.

Linux software audio mixing with FlightGear

2006-06-17T02:31:31Z

Pigeon: /* FlightGear to use ALSA */

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 <code>dmix</code> plugin).

== Prerequisites ==

This article assumes you have a basic understanding and knowledge of Linux. For instance:

* <code>~/</code> refers to your HOME directory. If your user name is <code>blah</code>, then <code>~/</code> normally would be <code>/home/blah/</code>. And so <code>~/.asoundrc</code> would mean <code>/home/blah/.asoundrc</code>

* Files with names starting with a dot (".") are normally considered as hidden files. If you're using some sort of file manager application, remember to turn on or enable showing these hidden files.

* If a "dot rc" file (e.g. <code>.asoundrc</code>, <code>.openalrc</code>) does not exist, simply creates it.

This article assumes you have ALSA setup and working with your soundcard(s).

== The concept ==

It is simple. You want to get all the applications to use ALSA <code>dmix</code> plugin for PCM audio playback. According to ALSA, <code>dmix</code> 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. <code>.asoundrc</code>) 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 <code>"plug:dmix"</code>. For example, with the ALSA command line player <code>aplay</code>, you run:

aplay -D "plug:dmix" test.wav

It's a good idea to run this to test if your <code>dmix</code> works.

For applications which does not have ALSA support (i.e. using OSS), you have a few choices:

; <code>aoss</code> : A wrapper script to run any application to use ALSA OSS. This works using simply via <code>LD_PRELOAD</code> to preload <code>libaoss.so</code>. It *seems* to use <code>dmix</code> if available automatically.

; <code>esd</code> : A software audio mixing daemon, typically shipped with GNOME. You can use its wrapper <code>esddsp</code> with other applications. You could run:
esd -d plug:dmix

; <code>artsd</code> : Another software audio mixing daemon, typically shipped with KDE. You can use its wrapper <code>artsdsp</code> 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 <code>aoss</code> and <code>artsd</code>. If possible it's a good idea to try all three approaches to get an OSS application to do ALSA.

<code>esd</code> does not seem to handle recording properly. So if you have an OSS application which does audio recording (say TeamSpeak), <code>esd</code> / <code>esddsp</code> 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 <code>/dev/dsp</code> (or <code>/dev/dsp0</code>, <code>/dev/dsp1</code>, etc), then it is probably using OSS. With ALSA, you normally specify an audio device using a string, which might look something like "<code>hw:0,0</code>" or "<code>plug:dmix</code>", or sometimes "<code>ALSA:default</code>", depending on the application itself.

=== <code>ldd</code> ===

<code>ldd</code> prints what shared libraries an application depends on.

Take <code>aplay</code> 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 <code>libasound.so.2</code>, which is the ALSA library, which *possibly* means <code>aplay</code> *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 <code>mplayer</code> and <code>xine</code>, which can do audio playback using many different audio libraries/approaches (OSS, ALSA, ESD, ARTS, and more).

=== <code>strace</code> ===

<code>strace</code> is a rather powerful tool, which traces and prints system calls of a running application.

Take <code>mpg123</code> 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 <code>open()</code> of this running instance of <code>mpg123</code>. As you can see it is opening <code>/dev/dsp</code>, which hints it is using OSS.

For an ALSA application, you will see a lot of <code>open()</code> calls to devices like <code>/dev/snd/controlC0</code>, <code>/dev/aloadC2</code>, <code>/dev/snd/pcmC0D0p</code>, etc. (Try <code>strace</code> with <code>aplay</code>!)

== FlightGear ==

FlightGear uses OpenAL (via SimGear) for audio playback, and OpenAL supports ALSA, ESD and ARTS. Though, you have to make sure your OpenAL is built with the audio support you need. Run <code>configure --help</code> if you are building your own OpenAL.

To get OpenAL to use a particular ALSA device, put these in your <code>~/.openalrc</code>

(define devices '(alsa))
(define alsa-out-device "plug:dmix")

To get OpenAL to use ESD:

(define devices '(esd))

And to get OpenAL to use ARTS:

(define devices '(arts))

== 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 <code>~/.festivalrc</code>:

(Parameter.set 'Audio_Method 'esdaudio)

And then run <code>festival</code> 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 <code>esddsp</code>, which means you would be running:

esddsp festival --server

=== Using the <code>Audio_Command</code> parameter ===

You can configure festival to run another application for playing audio. In this case, we could use <code>aplay</code> to help us. In your <code>~/.festivalrc</code> 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)

<code>$SR</code> is the sampling rate, and <code>$FILE</code> is the audio data file generated by festival for playback.

== TeamSpeak to use ALSA ==

TeamSpeak works with <code>aoss</code>, with minor issues. Sometimes it gets stuck on exit, for example.

TeamSpeak works with <code>artsd</code> / <code>artsdsp</code> 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 <code>esd</code> / <code>esddsp</code>, because <code>esd</code> does not seem to handle recording properly.

To run TeamSpeak, do:

aoss TeamSpeak

== When things don't work ==

* <code>aoss</code> honours your ALSA configurations, and hence your <code>~/.asoundrc</code>. You want to make sure it is correct. Use <code>aplay</code> and <code>arecord</code> to test your setup.

* Any other thing to try is to temporarily rename or move away your <code>~/.asoundrc</code>, and then test everything again.

* Try the following <code>.asoundrc</code>:

<pre>
pcm.duplex {
type asym
playback.pcm "dmix"
capture.pcm "dsnoop"
}

pcm.!default {
type plug
slave.pcm "duplex"
}
</pre>

* See http://gentoo-wiki.com/HOWTO_ALSA_sound_mixer_aka_dmix a pretty detailed HOWTO with ALSA audio including <code>dmix</code> and <code>dsnoop</code> configurations.

Linux software audio mixing with FlightGear

2006-06-17T02:28:06Z

Pigeon:

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 <code>dmix</code> plugin).

== Prerequisites ==

This article assumes you have a basic understanding and knowledge of Linux. For instance:

* <code>~/</code> refers to your HOME directory. If your user name is <code>blah</code>, then <code>~/</code> normally would be <code>/home/blah/</code>. And so <code>~/.asoundrc</code> would mean <code>/home/blah/.asoundrc</code>

* Files with names starting with a dot (".") are normally considered as hidden files. If you're using some sort of file manager application, remember to turn on or enable showing these hidden files.

* If a "dot rc" file (e.g. <code>.asoundrc</code>, <code>.openalrc</code>) does not exist, simply creates it.

This article assumes you have ALSA setup and working with your soundcard(s).

== The concept ==

It is simple. You want to get all the applications to use ALSA <code>dmix</code> plugin for PCM audio playback. According to ALSA, <code>dmix</code> 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. <code>.asoundrc</code>) 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 <code>"plug:dmix"</code>. For example, with the ALSA command line player <code>aplay</code>, you run:

aplay -D "plug:dmix" test.wav

It's a good idea to run this to test if your <code>dmix</code> works.

For applications which does not have ALSA support (i.e. using OSS), you have a few choices:

; <code>aoss</code> : A wrapper script to run any application to use ALSA OSS. This works using simply via <code>LD_PRELOAD</code> to preload <code>libaoss.so</code>. It *seems* to use <code>dmix</code> if available automatically.

; <code>esd</code> : A software audio mixing daemon, typically shipped with GNOME. You can use its wrapper <code>esddsp</code> with other applications. You could run:
esd -d plug:dmix

; <code>artsd</code> : Another software audio mixing daemon, typically shipped with KDE. You can use its wrapper <code>artsdsp</code> 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 <code>aoss</code> and <code>artsd</code>. If possible it's a good idea to try all three approaches to get an OSS application to do ALSA.

<code>esd</code> does not seem to handle recording properly. So if you have an OSS application which does audio recording (say TeamSpeak), <code>esd</code> / <code>esddsp</code> 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 <code>/dev/dsp</code> (or <code>/dev/dsp0</code>, <code>/dev/dsp1</code>, etc), then it is probably using OSS. With ALSA, you normally specify an audio device using a string, which might look something like "<code>hw:0,0</code>" or "<code>plug:dmix</code>", or sometimes "<code>ALSA:default</code>", depending on the application itself.

=== <code>ldd</code> ===

<code>ldd</code> prints what shared libraries an application depends on.

Take <code>aplay</code> 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 <code>libasound.so.2</code>, which is the ALSA library, which *possibly* means <code>aplay</code> *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 <code>mplayer</code> and <code>xine</code>, which can do audio playback using many different audio libraries/approaches (OSS, ALSA, ESD, ARTS, and more).

=== <code>strace</code> ===

<code>strace</code> is a rather powerful tool, which traces and prints system calls of a running application.

Take <code>mpg123</code> 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 <code>open()</code> of this running instance of <code>mpg123</code>. As you can see it is opening <code>/dev/dsp</code>, which hints it is using OSS.

For an ALSA application, you will see a lot of <code>open()</code> calls to devices like <code>/dev/snd/controlC0</code>, <code>/dev/aloadC2</code>, <code>/dev/snd/pcmC0D0p</code>, etc. (Try <code>strace</code> with <code>aplay</code>!)

== 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 <code>~/.openalrc</code>

(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 <code>~/.festivalrc</code>:

(Parameter.set 'Audio_Method 'esdaudio)

And then run <code>festival</code> 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 <code>esddsp</code>, which means you would be running:

esddsp festival --server

=== Using the <code>Audio_Command</code> parameter ===

You can configure festival to run another application for playing audio. In this case, we could use <code>aplay</code> to help us. In your <code>~/.festivalrc</code> 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)

<code>$SR</code> is the sampling rate, and <code>$FILE</code> is the audio data file generated by festival for playback.

== TeamSpeak to use ALSA ==

TeamSpeak works with <code>aoss</code>, with minor issues. Sometimes it gets stuck on exit, for example.

TeamSpeak works with <code>artsd</code> / <code>artsdsp</code> 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 <code>esd</code> / <code>esddsp</code>, because <code>esd</code> does not seem to handle recording properly.

To run TeamSpeak, do:

aoss TeamSpeak

== When things don't work ==

* <code>aoss</code> honours your ALSA configurations, and hence your <code>~/.asoundrc</code>. You want to make sure it is correct. Use <code>aplay</code> and <code>arecord</code> to test your setup.

* Any other thing to try is to temporarily rename or move away your <code>~/.asoundrc</code>, and then test everything again.

* Try the following <code>.asoundrc</code>:

<pre>
pcm.duplex {
type asym
playback.pcm "dmix"
capture.pcm "dsnoop"
}

pcm.!default {
type plug
slave.pcm "duplex"
}
</pre>

* See http://gentoo-wiki.com/HOWTO_ALSA_sound_mixer_aka_dmix a pretty detailed HOWTO with ALSA audio including <code>dmix</code> and <code>dsnoop</code> configurations.

Linux software audio mixing with FlightGear

2006-06-17T02:26:14Z

Pigeon: /* When things don't work */

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 <code>dmix</code> plugin).

== Prerequisites ==

This article assumes you have a basic understanding and knowledge of Linux. For instance:

* <code>~/</code> refers to your HOME directory. If your user name is <code>blah</code>, then <code>~/</code> normally would be <code>/home/blah/</code>. And so <code>~/.asoundrc</code> would mean <code>/home/blah/.asoundrc</code>

* Files with names starting with a dot (".") are normally considered as hidden files. If you're using some sort of file manager application, remember to turn on or enable showing these hidden files.

* If a "dot rc" file (e.g. <code>.asoundrc</code>, <code>.openalrc</code>) does not exist, simply creates it.

This article assumes you have ALSA setup and working with your soundcard(s).

== The concept ==

It is simple. You want to get all the applications to use ALSA <code>dmix</code> plugin for PCM audio playback. According to ALSA, <code>dmix</code> 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. <code>.asoundrc</code>) 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 <code>"plug:dmix"</code>. For example, with the ALSA command line player <code>aplay</code>, you run:

aplay -D "plug:dmix" test.wav

It's a good idea to run this to test if your <code>dmix</code> works.

For applications which does not have ALSA support (i.e. using OSS), you have a few choices:

; <code>aoss</code> : A wrapper script to run any application to use ALSA OSS. This works using simply via <code>LD_PRELOAD</code> to preload <code>libaoss.so</code>. It *seems* to use <code>dmix</code> if available automatically.

; <code>esd</code> : A software audio mixing daemon, typically shipped with GNOME. You can use its wrapper <code>esddsp</code> with other applications. You could run:
esd -d plug:dmix

; <code>artsd</code> : Another software audio mixing daemon, typically shipped with KDE. You can use its wrapper <code>artsdsp</code> 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 <code>aoss</code> and <code>artsd</code>. If possible it's a good idea to try all three approaches to get an OSS application to do ALSA.

<code>esd</code> does not seem to handle recording properly. So if you have an OSS application which does audio recording (say TeamSpeak), <code>esd</code> / <code>esddsp</code> 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 <code>/dev/dsp</code> (or <code>/dev/dsp0</code>, <code>/dev/dsp1</code>, etc), then it is probably using OSS. With ALSA, you normally specify an audio device using a string, which might look something like "<code>hw:0,0</code>" or "<code>plug:dmix</code>", or sometimes "<code>ALSA:default</code>", depending on the application itself.

=== <code>ldd</code> ===

<code>ldd</code> prints what shared libraries an application depends on.

Take <code>aplay</code> 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 <code>libasound.so.2</code>, which is the ALSA library, which *possibly* means <code>aplay</code> *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 <code>mplayer</code> and <code>xine</code>, which can do audio playback using many different audio libraries/approaches (OSS, ALSA, ESD, ARTS, and more).

=== <code>strace</code> ===

<code>strace</code> is a rather powerful tool, which traces and prints system calls of a running application.

Take <code>mpg123</code> 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 <code>open()</code> of this running instance of <code>mpg123</code>. As you can see it is opening <code>/dev/dsp</code>, which hints it is using OSS.

For an ALSA application, you will see a lot of <code>open()</code> calls to devices like <code>/dev/snd/controlC0</code>, <code>/dev/aloadC2</code>, <code>/dev/snd/pcmC0D0p</code>, etc. (Try <code>strace</code> with <code>aplay</code>!)

== 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 <code>~/.openalrc</code>

(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 <code>~/.festivalrc</code>:

(Parameter.set 'Audio_Method 'esdaudio)

And then run <code>festival</code> 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 <code>esddsp</code>, which means you would be running:

esddsp festival --server

=== Using the <code>Audio_Command</code> parameter ===

You can configure festival to run another application for playing audio. In this case, we could use <code>aplay</code> to help us. In your <code>~/.festivalrc</code> 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)

<code>$SR</code> is the sampling rate, and <code>$FILE</code> is the audio data file generated by festival for playback.

== TeamSpeak to use ALSA ==

TeamSpeak works with <code>aoss</code>, with minor issues. Sometimes it gets stuck on exit, for example.

TeamSpeak works with <code>artsd</code> / <code>artsdsp</code> 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 <code>esd</code> / <code>esddsp</code>, because <code>esd</code> does not seem to handle recording properly.

To run TeamSpeak, do:

aoss TeamSpeak

== When things don't work ==

* <code>aoss</code> honours your ALSA configurations, and hence your <code>~/.asoundrc</code>. You want to make sure it is correct. Use <code>aplay</code> and <code>arecord</code> to test your setup.

* Any other thing to try is to temporarily rename or move away your <code>~/.asoundrc</code>, and then test everything again.

* Try the following <code>.asoundrc</code>:

<pre>
pcm.duplex {
type asym
playback.pcm "dmix"
capture.pcm "dsnoop"
}

pcm.!default {
type plug
slave.pcm "duplex"
}
</pre>

Linux software audio mixing with FlightGear

2006-06-17T02:17:54Z

Pigeon: /* When things don't work */

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 <code>dmix</code> plugin).

== Prerequisites ==

This article assumes you have a basic understanding and knowledge of Linux. For instance:

* <code>~/</code> refers to your HOME directory. If your user name is <code>blah</code>, then <code>~/</code> normally would be <code>/home/blah/</code>. And so <code>~/.asoundrc</code> would mean <code>/home/blah/.asoundrc</code>

* Files with names starting with a dot (".") are normally considered as hidden files. If you're using some sort of file manager application, remember to turn on or enable showing these hidden files.

* If a "dot rc" file (e.g. <code>.asoundrc</code>, <code>.openalrc</code>) does not exist, simply creates it.

This article assumes you have ALSA setup and working with your soundcard(s).

== The concept ==

It is simple. You want to get all the applications to use ALSA <code>dmix</code> plugin for PCM audio playback. According to ALSA, <code>dmix</code> 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. <code>.asoundrc</code>) 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 <code>"plug:dmix"</code>. For example, with the ALSA command line player <code>aplay</code>, you run:

aplay -D "plug:dmix" test.wav

It's a good idea to run this to test if your <code>dmix</code> works.

For applications which does not have ALSA support (i.e. using OSS), you have a few choices:

; <code>aoss</code> : A wrapper script to run any application to use ALSA OSS. This works using simply via <code>LD_PRELOAD</code> to preload <code>libaoss.so</code>. It *seems* to use <code>dmix</code> if available automatically.

; <code>esd</code> : A software audio mixing daemon, typically shipped with GNOME. You can use its wrapper <code>esddsp</code> with other applications. You could run:
esd -d plug:dmix

; <code>artsd</code> : Another software audio mixing daemon, typically shipped with KDE. You can use its wrapper <code>artsdsp</code> 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 <code>aoss</code> and <code>artsd</code>. If possible it's a good idea to try all three approaches to get an OSS application to do ALSA.

<code>esd</code> does not seem to handle recording properly. So if you have an OSS application which does audio recording (say TeamSpeak), <code>esd</code> / <code>esddsp</code> 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 <code>/dev/dsp</code> (or <code>/dev/dsp0</code>, <code>/dev/dsp1</code>, etc), then it is probably using OSS. With ALSA, you normally specify an audio device using a string, which might look something like "<code>hw:0,0</code>" or "<code>plug:dmix</code>", or sometimes "<code>ALSA:default</code>", depending on the application itself.

=== <code>ldd</code> ===

<code>ldd</code> prints what shared libraries an application depends on.

Take <code>aplay</code> 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 <code>libasound.so.2</code>, which is the ALSA library, which *possibly* means <code>aplay</code> *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 <code>mplayer</code> and <code>xine</code>, which can do audio playback using many different audio libraries/approaches (OSS, ALSA, ESD, ARTS, and more).

=== <code>strace</code> ===

<code>strace</code> is a rather powerful tool, which traces and prints system calls of a running application.

Take <code>mpg123</code> 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 <code>open()</code> of this running instance of <code>mpg123</code>. As you can see it is opening <code>/dev/dsp</code>, which hints it is using OSS.

For an ALSA application, you will see a lot of <code>open()</code> calls to devices like <code>/dev/snd/controlC0</code>, <code>/dev/aloadC2</code>, <code>/dev/snd/pcmC0D0p</code>, etc. (Try <code>strace</code> with <code>aplay</code>!)

== 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 <code>~/.openalrc</code>

(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 <code>~/.festivalrc</code>:

(Parameter.set 'Audio_Method 'esdaudio)

And then run <code>festival</code> 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 <code>esddsp</code>, which means you would be running:

esddsp festival --server

=== Using the <code>Audio_Command</code> parameter ===

You can configure festival to run another application for playing audio. In this case, we could use <code>aplay</code> to help us. In your <code>~/.festivalrc</code> 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)

<code>$SR</code> is the sampling rate, and <code>$FILE</code> is the audio data file generated by festival for playback.

== TeamSpeak to use ALSA ==

TeamSpeak works with <code>aoss</code>, with minor issues. Sometimes it gets stuck on exit, for example.

TeamSpeak works with <code>artsd</code> / <code>artsdsp</code> 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 <code>esd</code> / <code>esddsp</code>, because <code>esd</code> does not seem to handle recording properly.

To run TeamSpeak, do:

aoss TeamSpeak

== When things don't work ==

* <code>aoss</code> honours your ALSA configurations, and hence your <code>~/.asoundrc</code>. You want to make sure it is correct. Use <code>aplay</code> and <code>arecord</code> to test your setup.

* Any other thing to try is to temporarily rename or move away your <code>~/.asoundrc</code>, and then test everything again.

* Try the following <code>.asoundrc</code>:

<pre>
pcm.duplex {
type asym
playback.pcm "dmix"
capture.pcm "dsnoop"
}

pcm.!default {
type plug
slave.pcm "duplex"
}
</pre>

Linux software audio mixing with FlightGear

2006-06-17T01:52:48Z

Pigeon: /* When things don't work */

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 <code>dmix</code> plugin).

== Prerequisites ==

This article assumes you have a basic understanding and knowledge of Linux. For instance:

* <code>~/</code> refers to your HOME directory. If your user name is <code>blah</code>, then <code>~/</code> normally would be <code>/home/blah/</code>. And so <code>~/.asoundrc</code> would mean <code>/home/blah/.asoundrc</code>

* Files with names starting with a dot (".") are normally considered as hidden files. If you're using some sort of file manager application, remember to turn on or enable showing these hidden files.

* If a "dot rc" file (e.g. <code>.asoundrc</code>, <code>.openalrc</code>) does not exist, simply creates it.

This article assumes you have ALSA setup and working with your soundcard(s).

== The concept ==

It is simple. You want to get all the applications to use ALSA <code>dmix</code> plugin for PCM audio playback. According to ALSA, <code>dmix</code> 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. <code>.asoundrc</code>) 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 <code>"plug:dmix"</code>. For example, with the ALSA command line player <code>aplay</code>, you run:

aplay -D "plug:dmix" test.wav

It's a good idea to run this to test if your <code>dmix</code> works.

For applications which does not have ALSA support (i.e. using OSS), you have a few choices:

; <code>aoss</code> : A wrapper script to run any application to use ALSA OSS. This works using simply via <code>LD_PRELOAD</code> to preload <code>libaoss.so</code>. It *seems* to use <code>dmix</code> if available automatically.

; <code>esd</code> : A software audio mixing daemon, typically shipped with GNOME. You can use its wrapper <code>esddsp</code> with other applications. You could run:
esd -d plug:dmix

; <code>artsd</code> : Another software audio mixing daemon, typically shipped with KDE. You can use its wrapper <code>artsdsp</code> 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 <code>aoss</code> and <code>artsd</code>. If possible it's a good idea to try all three approaches to get an OSS application to do ALSA.

<code>esd</code> does not seem to handle recording properly. So if you have an OSS application which does audio recording (say TeamSpeak), <code>esd</code> / <code>esddsp</code> 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 <code>/dev/dsp</code> (or <code>/dev/dsp0</code>, <code>/dev/dsp1</code>, etc), then it is probably using OSS. With ALSA, you normally specify an audio device using a string, which might look something like "<code>hw:0,0</code>" or "<code>plug:dmix</code>", or sometimes "<code>ALSA:default</code>", depending on the application itself.

=== <code>ldd</code> ===

<code>ldd</code> prints what shared libraries an application depends on.

Take <code>aplay</code> 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 <code>libasound.so.2</code>, which is the ALSA library, which *possibly* means <code>aplay</code> *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 <code>mplayer</code> and <code>xine</code>, which can do audio playback using many different audio libraries/approaches (OSS, ALSA, ESD, ARTS, and more).

=== <code>strace</code> ===

<code>strace</code> is a rather powerful tool, which traces and prints system calls of a running application.

Take <code>mpg123</code> 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 <code>open()</code> of this running instance of <code>mpg123</code>. As you can see it is opening <code>/dev/dsp</code>, which hints it is using OSS.

For an ALSA application, you will see a lot of <code>open()</code> calls to devices like <code>/dev/snd/controlC0</code>, <code>/dev/aloadC2</code>, <code>/dev/snd/pcmC0D0p</code>, etc. (Try <code>strace</code> with <code>aplay</code>!)

== 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 <code>~/.openalrc</code>

(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 <code>~/.festivalrc</code>:

(Parameter.set 'Audio_Method 'esdaudio)

And then run <code>festival</code> 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 <code>esddsp</code>, which means you would be running:

esddsp festival --server

=== Using the <code>Audio_Command</code> parameter ===

You can configure festival to run another application for playing audio. In this case, we could use <code>aplay</code> to help us. In your <code>~/.festivalrc</code> 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)

<code>$SR</code> is the sampling rate, and <code>$FILE</code> is the audio data file generated by festival for playback.

== TeamSpeak to use ALSA ==

TeamSpeak works with <code>aoss</code>, with minor issues. Sometimes it gets stuck on exit, for example.

TeamSpeak works with <code>artsd</code> / <code>artsdsp</code> 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 <code>esd</code> / <code>esddsp</code>, because <code>esd</code> does not seem to handle recording properly.

To run TeamSpeak, do:

aoss TeamSpeak

== When things don't work ==

<code>aoss</code> honours your ALSA configurations, and hence your <code>~/.asoundrc</code>. You want to make sure it is correct. Use <code>aplay</code> and <code>arecord</code> to test your setup.

Any other thing to try is to temporarily rename or move away your <code>~/.asoundrc</code>, and then test everything again.

Linux software audio mixing with FlightGear

2006-06-17T01:50:12Z

Pigeon:

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 <code>dmix</code> plugin).

== Prerequisites ==

This article assumes you have a basic understanding and knowledge of Linux. For instance:

* <code>~/</code> refers to your HOME directory. If your user name is <code>blah</code>, then <code>~/</code> normally would be <code>/home/blah/</code>. And so <code>~/.asoundrc</code> would mean <code>/home/blah/.asoundrc</code>

* Files with names starting with a dot (".") are normally considered as hidden files. If you're using some sort of file manager application, remember to turn on or enable showing these hidden files.

* If a "dot rc" file (e.g. <code>.asoundrc</code>, <code>.openalrc</code>) does not exist, simply creates it.

This article assumes you have ALSA setup and working with your soundcard(s).

== The concept ==

It is simple. You want to get all the applications to use ALSA <code>dmix</code> plugin for PCM audio playback. According to ALSA, <code>dmix</code> 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. <code>.asoundrc</code>) 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 <code>"plug:dmix"</code>. For example, with the ALSA command line player <code>aplay</code>, you run:

aplay -D "plug:dmix" test.wav

It's a good idea to run this to test if your <code>dmix</code> works.

For applications which does not have ALSA support (i.e. using OSS), you have a few choices:

; <code>aoss</code> : A wrapper script to run any application to use ALSA OSS. This works using simply via <code>LD_PRELOAD</code> to preload <code>libaoss.so</code>. It *seems* to use <code>dmix</code> if available automatically.

; <code>esd</code> : A software audio mixing daemon, typically shipped with GNOME. You can use its wrapper <code>esddsp</code> with other applications. You could run:
esd -d plug:dmix

; <code>artsd</code> : Another software audio mixing daemon, typically shipped with KDE. You can use its wrapper <code>artsdsp</code> 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 <code>aoss</code> and <code>artsd</code>. If possible it's a good idea to try all three approaches to get an OSS application to do ALSA.

<code>esd</code> does not seem to handle recording properly. So if you have an OSS application which does audio recording (say TeamSpeak), <code>esd</code> / <code>esddsp</code> 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 <code>/dev/dsp</code> (or <code>/dev/dsp0</code>, <code>/dev/dsp1</code>, etc), then it is probably using OSS. With ALSA, you normally specify an audio device using a string, which might look something like "<code>hw:0,0</code>" or "<code>plug:dmix</code>", or sometimes "<code>ALSA:default</code>", depending on the application itself.

=== <code>ldd</code> ===

<code>ldd</code> prints what shared libraries an application depends on.

Take <code>aplay</code> 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 <code>libasound.so.2</code>, which is the ALSA library, which *possibly* means <code>aplay</code> *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 <code>mplayer</code> and <code>xine</code>, which can do audio playback using many different audio libraries/approaches (OSS, ALSA, ESD, ARTS, and more).

=== <code>strace</code> ===

<code>strace</code> is a rather powerful tool, which traces and prints system calls of a running application.

Take <code>mpg123</code> 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 <code>open()</code> of this running instance of <code>mpg123</code>. As you can see it is opening <code>/dev/dsp</code>, which hints it is using OSS.

For an ALSA application, you will see a lot of <code>open()</code> calls to devices like <code>/dev/snd/controlC0</code>, <code>/dev/aloadC2</code>, <code>/dev/snd/pcmC0D0p</code>, etc. (Try <code>strace</code> with <code>aplay</code>!)

== 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 <code>~/.openalrc</code>

(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 <code>~/.festivalrc</code>:

(Parameter.set 'Audio_Method 'esdaudio)

And then run <code>festival</code> 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 <code>esddsp</code>, which means you would be running:

esddsp festival --server

=== Using the <code>Audio_Command</code> parameter ===

You can configure festival to run another application for playing audio. In this case, we could use <code>aplay</code> to help us. In your <code>~/.festivalrc</code> 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)

<code>$SR</code> is the sampling rate, and <code>$FILE</code> is the audio data file generated by festival for playback.

== TeamSpeak to use ALSA ==

TeamSpeak works with <code>aoss</code>, with minor issues. Sometimes it gets stuck on exit, for example.

TeamSpeak works with <code>artsd</code> / <code>artsdsp</code> 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 <code>esd</code> / <code>esddsp</code>, because <code>esd</code> does not seem to handle recording properly.

To run TeamSpeak, do:

aoss TeamSpeak

== When things don't work ==

<code>aoss</code> honours your ALSA configurations, and hence your <code>~/.asoundrc</code>. You want to make sure it is correct. Use <code>aplay</code> and <code>arecord</code> to test your setup.

Main Page

2006-06-17T00:55:12Z

Pigeon: Added link to Linux_software_audio_mixing_with_FlightGear

__NOTOC__
__NOEDITSECTION__
'''FlightGear''' Flight Simulator project is an open-source, multi-platform, cooperative flight simulator development project. Source code for the entire project is available ([http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/?cvsroot=FlightGear-0.9#dirlist CVS repository]) and licensed under the [http://www.gnu.org/copyleft/gpl.html GNU General Public License].

The goal of the '''FlightGear''' project is to create a sophisticated flight simulator framework for use in research or academic environments, for the development and pursuit of other interesting flight simulation ideas, and as an end-user application. We are developing a sophisticated, open simulation framework that can be expanded and improved upon by anyone interested in [[Volunteer|contributing]].

There are many exciting possibilities for an open, free flight sim. We hope that this project will be interesting and useful to many people in many areas.

'''FlightGear''' comes with a set of illustrated documentation, notably
"The Manual", which is available as
[http://www.flightgear.org/Docs/getstart/getstart.pdf PDF] and
[http://www.flightgear.org/Docs/getstart/getstart.html HTML]. If you
prefer to follow the 'bleeding edge' set of FlightGear instructions,
then the following articles are likely to make you happy. You will
notice that parts of this Wiki duplicate information that's alread
present in "The Manual".

{|cellspacing="10"
| width="50%"|
== User Documentation ==

=== Getting Started ===
* [[ New to FlightGear ]]
* [[ FAQ ]]
* [[ Hardware Recommendations ]]
* [[ Recommended Software ]]
* [[ Troubleshooting Problems ]]
* [[ Volunteer ]]
* [[ Real Life Experience ]]

=== Using Flightgear ===
* [[ Aircraft ]]
* [[ Suggested Flights ]]
* [[ Starting in the Air ]]
* [[ Multiplayer Howto ]]
* [[ Carrier Howto ]]
* [[ Air-Air Refueling Howto ]]
* [[ AI Systems ]]
* [[ Installing Scenery ]]
* [[ Improving Framerates ]]
* [[ Instant Replay ]]
* [[ Command Line Parameters ]]
* [[ Preset Properties ]]
* [[ Realism ]]
* [[ Soaring ]]
* [[ Linux software audio mixing with FlightGear ]]

=== Flying Resources ===
* [[ Definitions Acronyms ]]
* [[ Getting IFR Charts ]]
* [[ Understanding Altitude ]]
* [[ Understanding Navigation ]]
* [[ Understanding Propeller Torque and P-Factor ]]
* [[ Understanding Aerodynamics ]]
* [[ Communications ]]
* [[ Weather ]]
* [[ Avionics and Instruments ]]

| width="50%" valign="top" |
== Developer Documentation ==

=== Coding Guidelines ===
* [[ Building Flightgear ]]
* [[ Building Terragear ]]
* [[ Submitting Patches ]]
* [[ Janitors ]]
* [[ Development Resources ]]
* [[ Extension Support ]]

=== Code Internals ===
* [[ Property Tree ]]
* [[ Subsystems ]]
* [[ Commands ]]
* [[ FDM API ]]
* [[ Nasal scripting language ]]

=== Modeling ===
* [[ Modeling - Getting Started ]]
* [[ Model Import and Export ]]
* [[ Modeling Resources ]]
* [[ Aircraft Information Resources ]]

=== Todo ===
* [[ Bugs ]]
* [[ FGFS Todo ]]
* [[ Aircraft Todo ]]
* [[ Goals ]]
* [[ Feature Requests / Proposals / Ideas ]]

=== Miscellaneous ===
* [[ Glass Cockpit Projects ]]
* [[ Tutorial Resources ]]
* [[ Copyright Inquiry ]]
* [http://www.cafepress.com/fgfs_gear FlightGear - Gear]
|}

Linux software audio mixing with FlightGear

2006-06-17T00:50:39Z

Pigeon: /* TeamSpeak */

Linux software audio mixing with FlightGear

2006-06-17T00:50:10Z

Pigeon: /* The concept */

Linux software audio mixing with FlightGear

2006-06-17T00:49:37Z

Pigeon: /* TeamSpeak */

Linux software audio mixing with FlightGear

2006-06-17T00:48:18Z

Pigeon: /* TeamSpeak */

Linux software audio mixing with FlightGear

2006-06-17T00:46:05Z

Pigeon:

Linux FG Festival TS

2006-06-17T00:43:08Z

Pigeon: Linux FG Festival TS moved to Linux software audio mixing with FlightGear

#REDIRECT [[Linux software audio mixing with FlightGear]]

Linux software audio mixing with FlightGear

2006-06-17T00:43:08Z

Pigeon: Linux FG Festival TS moved to 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 <code>dmix</code> plugin).

== The concept ==

It is simple. You want to get all the applications to use ALSA <code>dmix</code> plugin for PCM audio playback. According to ALSA, <code>dmix</code> 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. <code>.asoundrc</code>) 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 <code>"plug:dmix"</code>. For example, with the ALSA command line player <code>aplay</code>, 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:

; <code>aoss</code> : A wrapper script to run any application to use ALSA OSS. This works using simply via <code>LD_PRELOAD</code> to preload <code>libaoss.so</code>. It *seems* to use <code>dmix</code> if available automatically.

; <code>esd</code> : A software audio mixing daemon, typically shipped with GNOME. You can use its wrapper <code>esddsp</code> with other applications. You could run:
esd -d plug:dmix

; <code>artsd</code> : Another software audio mixing daemon, typically shipped with KDE. You can use its wrapper <code>artsdsp</code> 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 <code>aoss</code> and <code>artsd</code>. If possible it's a good idea to try all three approaches to get an OSS application to do ALSA.

<code>esd</code> does not seem to handle recording properly. So if you have an OSS application which does audio recording (say TeamSpeak), <code>esd</code> / <code>esddsp</code> 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 <code>/dev/dsp</code> (or <code>/dev/dsp0</code>, <code>/dev/dsp1</code>, etc), then it is probably using OSS. With ALSA, you normally specify an audio device using a string, which might look something like "<code>hw:0,0</code>" or "<code>plug:dmix</code>", or sometimes "<code>ALSA:default</code>", depending on the application itself.

=== <code>ldd</code> ===

<code>ldd</code> prints what shared libraries an application depends on.

Take <code>aplay</code> 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 <code>libasound.so.2</code>, which is the ALSA library, which *possibly* means <code>aplay</code> *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 <code>mplayer</code> and <code>xine</code>, which can do audio playback using many different audio libraries/approaches (OSS, ALSA, ESD, ARTS, and more).

=== <code>strace</code> ===

<code>strace</code> is a rather powerful tool, which traces and prints system calls of a running application.

Take <code>mpg123</code> 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 <code>open()</code> of this running instance of <code>mpg123</code>. As you can see it is opening <code>/dev/dsp</code>, which hints it is using OSS.

For an ALSA application, you will see a lot of <code>open()</code> calls to devices like <code>/dev/snd/controlC0</code>, <code>/dev/aloadC2</code>, <code>/dev/snd/pcmC0D0p</code>, etc. (Try <code>strace</code> with <code>aplay</code>!)

== 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 <code>~/.openalrc</code>

(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 <code>~/.festivalrc</code>:

(Parameter.set 'Audio_Method 'esdaudio)

And then run <code>festival</code> 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 <code>esddsp</code>, which means you would be running:

esddsp festival --server

=== Using the <code>Audio_Command</code> parameter ===

You can configure festival to run another application for playing audio. In this case, we could use <code>aplay</code> to help us. In your <code>~/.festivalrc</code> 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)

<code>$SR</code> is the sampling rate, and <code>$FILE</code> is the audio data file generated by festival for playback.

== TeamSpeak ==

TeamSpeak works nicely with <code>aoss</code>. It also works with <code>artsdsp</code> (so you have to run artsd as well).

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

To run TeamSpeak, do:

aoss TeamSpeak

or, using artsd, do:

artsd -d -D plug:dmix

where the <code>-d</code> is to enable full-duplex operations.

Then you run TeamSpeak:

artsdsp TeamSpeak

Linux software audio mixing with FlightGear

2006-06-17T00:41:39Z

Pigeon: /* The concept */

Linux software audio mixing with FlightGear

2006-06-17T00:38:46Z

Pigeon: /* FlightGear + Festival + TeamSpeak with software audio mixing on Linux */

<h1>FlightGear + Festival + TeamSpeak with software audio mixing on Linux</h1>

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 <code>dmix</code> plugin).

== The concept ==

It is simple. You want to get all the applications to use ALSA <code>dmix</code> plugin for PCM audio playback. According to ALSA, <code>dmix</code> 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. <code>.asoundrc</code>) 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 <code>"plug:dmix"</code>. For example, with the ALSA command line player <code>aplay</code>, 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:

; <code>aoss</code> : A wrapper script to run any application to use ALSA OSS. This works using simply via <code>LD_PRELOAD</code> to preload <code>libaoss.so</code>. It *seems* to use <code>dmix</code> if available automatically.

; <code>esd</code> : A software audio mixing daemon, typically shipped with GNOME. You can use its wrapper <code>esddsp</code> with other applications. You could run:
esd -d plug:dmix

; <code>artsd</code> : Another software audio mixing daemon, typically shipped with KDE. You can use its wrapper <code>artsdsp</code> 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 <code>aoss</code> and <code>artsd</code>. If possible it's a good idea to try all three approaches to get an OSS application to do ALSA.

<code>esd</code> does not seem to handle recording properly. So if you have an OSS application which does audio recording (say TeamSpeak), <code>esd</code> / <code>esddsp</code> 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 <code>/dev/dsp</code> (or <code>/dev/dsp0</code>, <code>/dev/dsp1</code>, etc), then it is probably using OSS. With ALSA, you normally specify an audio device using a string, which might look something like "<code>hw:0,0</code>" or "<code>plug:dmix</code>", or sometimes "<code>ALSA:default</code>", depending on the application itself.

=== <code>ldd</code> ===

<code>ldd</code> prints what shared libraries an application depends on.

Take <code>aplay</code> 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 <code>libasound.so.2</code>, which is the ALSA library, which *possibly* means <code>aplay</code> *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 <code>mplayer</code> and <code>xine</code>, which can do audio playback using many different audio libraries/approaches (OSS, ALSA, ESD, ARTS, and more).

=== <code>strace</code> ===

<code>strace</code> is a rather powerful tool, which traces and prints system calls of a running application.

Take <code>mpg123</code> 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 <code>open()</code> of this running instance of <code>mpg123</code>. As you can see it is opening <code>/dev/dsp</code>, which hints it is using OSS.

For an ALSA application, you will see a lot of <code>open()</code> calls to devices like <code>/dev/snd/controlC0</code>, <code>/dev/aloadC2</code>, <code>/dev/snd/pcmC0D0p</code>, etc. (Try <code>strace</code> with <code>aplay</code>!)

== 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 <code>~/.openalrc</code>

(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 <code>~/.festivalrc</code>:

(Parameter.set 'Audio_Method 'esdaudio)

And then run <code>festival</code> 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 <code>esddsp</code>, which means you would be running:

esddsp festival --server

=== Using the <code>Audio_Command</code> parameter ===

You can configure festival to run another application for playing audio. In this case, we could use <code>aplay</code> to help us. In your <code>~/.festivalrc</code> 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)

<code>$SR</code> is the sampling rate, and <code>$FILE</code> is the audio data file generated by festival for playback.

== TeamSpeak ==

TeamSpeak works nicely with <code>aoss</code>. It also works with <code>artsdsp</code> (so you have to run artsd as well).

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

To run TeamSpeak, do:

aoss TeamSpeak

or, using artsd, do:

artsd -d -D plug:dmix

where the <code>-d</code> is to enable full-duplex operations.

Then you run TeamSpeak:

artsdsp TeamSpeak

Linux software audio mixing with FlightGear

2006-06-16T13:55:38Z

Pigeon:

= FlightGear + Festival + TeamSpeak with software audio mixing on Linux =

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. <code>.asoundrc</code>) to use "dmix" by default. This article's approach is NOT to use any global or per-user configuration file setup, 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 <code>aplay</code>, 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.
; esd : A software audio mixing daemon, typically shipped with GNOME.
; artsd : Another software audio mixing daemon, typically shipped with KDE.

== 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 <code>~/.openalrc</code>

(define devices '(alsa))
(define alsa-out-device "plug:dmix")