Modelo arquitectónico de ALSA
(Advanced Linux Sound Architecture)
Arquitectura general
por David García Garzón (Vokimon), david punto garcia en upf punto edu
Nota:
Este manual está en construcción y es muy posible que haya
erratas y secciones incompletas.
Si quieres ayudar, puedes ver algunos temas a
resolver activando la hoja de estilo Default with TODO's.
Normalmente en el menu Ver o Visualizar de tu navegador.
Arquitectura general
Subsistemas
La funcionalidad de ALSA se divide varios subsistemas.
Cada subsistema controla un tipo diferente de flujo.
Los principales son:
- ctl: Flujo de control.
(Mezcladores de entrada y salida, equalización, balance, sorround, activación de canales...)
TODO: Pilotos, monitores, vumeters y compañia tambien estarian aquí como flujo de entrada?
- pcm: Flujo de audio digital.
- seq: Flujo de eventos musicales (MIDI).
- timer: Flujo de eventos de tiempo.
Permite un control fino de la temporización en los dispositivos de sonido.
Otros no tan importantes
- rawmidi: Flujo de mensajes MIDI sin decodificar.
Permite un nivel más bajo de abstracción que seq.
- hctl: Flujo de control pero usando cache para reducir accesos al hardware.
TODO: hctl parece un interfaz de programación pero no sale en ningun sitio como subsistema
de dispositivos.
TODO: Alguno mas? hwdep?
Dispositivos (devices)
Los dispositivos (devices) son los elementos que usan las aplicaciones
como fuentes y sumideros de sus flujos de datos.
- Cada subsistema (ctl, pcm, seq...)
ofrece a las aplicaciones una serie de dispositivos.
- Las aplicaciones leen de ellos (captura) o escriben en ellos (reproducción).
- Las aplicaciones pueden especificar el dispositivo a usar mediante un identificador.
- Algunos nombres de dispositivo se pueden parametrizar, nombre:param1,param2,
para indicar dispositivos diferentes.
- ALSA predefine algunos nombres de dispositivos de conveniencia.
- El usuario puede definir sus propios nombres de dispositivos con nuevas
capacidades mediante la combinación de plugins.
Conectables (plugins)
Todos los dispositivos, incluidos los predefinidos, estan formados por una cadena de plugins:
- Cada plugin de la cadena realiza una operación sobre el flujo de datos del dispositivo.
- El último plugin de la cadena suele estar relacionado con un controlador de hardware y
ofrece una funcionalidad muy sencilla para leer y escribir en él.
- El resto de plugins permiten que los dispositivos hagan cosas más elaboradas:
Conversiones, filtros, mezclas, bifurcaciones, unión de dispositivos...
- Se pueden ampliar las posibilidades de ALSA incorporando nuevos plugins.
Por ejemplo, LADSPA y JACK se han integrado en ALSA como plugins.
- Los plugins son prácticos pero cada uno añade un costo en latencia y eficiencia.
- La modularidad nos permite minimizar la latencia
utilizando solo aquellos plugins que necesitemos.
Por ejemplo, imagina que queremos enviar un flujo de audio digital (pcm)
a nuestra tarjeta de sonido:
- Si no necesitamos ningun tipo de conversion de formato,
podemos usar directamente el plugin hardware y obtendremos una latencia mínima.
- Si no nos queremos preocupar por los formatos y no nos importa la latencia que ello pueda generar,
podemos añadirle un plugin que automaticamente detecte y convierta los formatos de audio.
- Si solo necesitamos convertir a una frecuencia de muestreo diferente,
podemos mejorar la latencia usando un plugin que haga extrictamente esa conversión.
La forma de definir un dispositivo no es especificando la cadena de plugins completa.
Simplemente, se define un dispositivo como el resultado de aplicar un plugin al flujo
de otro dispositivo ya existente (el slave).
Es decir, para cada eslabón de la cadena se corresponde con un dispositivo.
Aunque tener tantos dispositivos no sea nuestra intención,
esta forma de definir los dispositivos facilita a ALSA la reutilización de subcadenas de plugins.
Dependiendo del plugin, la forma en que se relaciona el slave con
posibles masters (otro plugin o una aplicación) puede ser:
- Final: No tiene slave. Es un plugin terminal.
Corresponde normalmente con un driver en el kernel
- Linear: Un slave se corresponde con un master.
- Route: Un slave se corresponde con un master pero
varia la configuración de canales
- Share: Separa los canales del slave en diversos dispositivos.
- Multi: Combina varios slaves en un solo dispositivo
- DMix: Acepta varios masters dinamicamente y los mezcla hacia un
solo slave. Requiere canales iguales?
- DShare: TODO: Dinamic share?
- DSnoop: TODO: Dinamic snoop?
TODO: Se puede aplicar la clasificación a otros flujos no pcm?
TODO: Se puede aplicar el concepto de canal a todos los flujos?
TODO: Introducir el concepto de canal antes en el manual si es aplicable.