Pues no soy un experto (ni en esto ni en nada), pero lo intentaré. Hace tiempo que tengo pensado escribir un mini howto sobre esto, pero el ver a ALSA ya dentro del kernel me echó para atrás. En cuanto ALSA sea la salida estándar, se acabaron los problemas (esperemos).

    Como decía, el problema del cuelgue del plugin de flash no es un problema exclusivo del plugin. Es cierto, como me puntualizan, que hay aplicaciones que detectan que el dispositivo de sonido está siendo utilizado y desactivan el sonido si es así. Pero eso no es solución. Es sólo un parche (y a mi modo de ver bastante cutre).

    El verdadero problema es que el OSS (Open Sound System) es un sistema de sonido muy muy muy básico. Sólo es capaz de recibir un flujo de datos a través de /dev/dsp y enviarlo a la tarjeta de sonido. Punto. Si nuestra tarjeta es normalita (SB16-32-AWE, las SB PCI básicas, las VIA integradas en placa, etc), sólo podrá reproducir un sonido simultáneamente. Y como efecto secundario, si un programa ya está utilizándola e intentamos mandar sonido desde otro, éste último no sonará. Hay otras tarjetas más "avanzadas" (la SB Live!, por ejemplo) que son capaces de mezclar sonidos por hard. Esto es, que nosotros enviamos más de un flujo de datos a /dev/dsp, y la propia tarjeta se encarga de mezclarlos y hacer que suenen simultáneamente.

¿Cómo lidia cada programa con este problema?

    Pues depende, como todo. Los hay "inteligentes" (como el mplayer) que detectan la imposibilidad de reproducir sonido y lo desactivan. Pero otros (como el plugin de flash 5, el xmms, etc) simplemente esperarán a tener el sonido disponible para ellos. NO se cuelgan (quiero dejar claro eso). Simplemente están a la espera. De hecho, si dejas de reproducir el sonido causante de la pausa, seguirán ejecutándose como si nada.

¿Y qué pintan los servidores de sonido entonces en todo esto?

    Planteado un problema (imposibilidad de algunas tarjetas de reproducir más de un sonido simultáneamente), había que buscar una solución. Esa solución son los "servidores de sonido".
Un servidor de sonido no es más que un demonio que está a la escucha, y es capaz de recibir mil y un flujos de sonido, mezclarlos y enviar la mezcla *como una sola salida* a /dev/dsp. Sencillo y eficiente. La tarjeta seguirá reproduciendo un solo sonido, pero ese sonido es la mezcla de todos.
Fácil, ¿no?. Pues no, no es tan fácil. ;)
Resulta que para que una aplicación pueda usar un servidor de sonido, ha de estar preparada para ello. Es decir, no basta con que montemos un servidor para que mágicamente se mezclen todas las salidas de nuestros programas. Hemos de decirle a los programas en cuestión que utilizen el servidor *en lugar de* OSS (/dev/dsp). Y depende del programa en concreto que esto sea posible.

    Dicho esto, comentar que existen (que yo conozca, es posible que haya muchos más) tres servidores de sonido. Uno es "arts" (Analog Realtime Synthesizer), que es el servidor de sonido predeterminado de KDE. El segundo es "esd" (Enlightened Sound Daemon), que es el que se usa por defecto en Gnome y en Enlightenment, y el último es ALSA (Advanced Linux Sound Architecture), desarrollado por SUSE y estándar en los kernel 2.5 (y por tanto 2.6)

¿Por qué es "mala" la variedad en este caso?.

    Por una sencilla razón: la falta de estandarización: Las aplicaciones de KDE hacen que su salida sonora sea a través de arts, los de gnome a través de esd, y el resto depende. Mplayer es capaz de usar tanto esd como arts. Xmms también, aunque sólo viene integrado el soporte para esd. Si quieres soporte arts deberás bajarte un plugin (el paquete xmms-arts para debian). Otros muchos programas no traen soporte para ninguno de ellos.

Para acabar de rematarla, tenemos el problema que trae de cabeza a todos los usuarios novatos (y no tan novatos):
¿Por qué la caca del mplayer (por poner un ejemplo, que es un gran programa) este me dice que no puede reproducir sonido si no tengo abierto NADA salvo KDE?.
    Pues muy fácil. Es el servidor de sonido el que te está ocupando el sonido. O sea, la pescadilla que se muerde la cola. Mientras el servidor esté activo, estará ocupando /dev/dsp, como es lógico. Si tu aplicación no está preparada para usar arts, no será capaz de hacer sonar nada mientras arts esté activo... y arts tarda 60 segundos en desactivarse por defecto (al menos es así en debian). Muchos usuarios recurren a ponerle un "0" al timeout de arts en el panel de control de KDE, pero eso no deja de ser una solución rápida y mala. Lo que se debería intentar hacer es hacer que *todas* las aplicaciones usen el servidor de sonido. ¿Es esto posible?. Hasta donde yo sé, sí es posible con arts. Con esd no tengo ni idea, pero supongo que también.

¿Cómo hacer que una aplicación no preparada para arts salga a través de él?

    Muy fácil. Para arrancar la aplicación, usa el comando "artsdsp". Es decir, si quieres arrancar mozilla para que la salida del plugin de flash (en realidad cualquier sonido producido por mozilla) sea a través de arts, escribe "artsdsp mozilla" en lugar de "mozilla". Toda la salida del mozilla irá a arts en lugar de a /dev/dsp. Esto funciona en todos los programas que probé excepto uno: Quake 3. No sé por qué, pero si arrancas este juego con artsdsp, no oirás NADA. :(

    Espero que haya servido para aclarar algunas dudas. Supongo que lo colgaré de mi minipágina de miniayudas para quien lo quiera leer:

http://davide.enredo.net.

Saludos.