Traducción al Español que hice de sndio. Este trabajo está licenciada por el Autor de este sitio bajo los mismos términos y condiciones de la web antes citada y por la Licencia FDL 1.3.
sndio es una pequeña parte del marco de audio y MIDI del proyecto OpenBSD y portado a FreeBSD, Linux y NetBSD. Proporciona un servidor ligero de audio y MIDI y una API de espacio de usuario totalmente documentada para acceder al servidor o al hardware directamente de una manera uniforme. sndio está diseñado para funcionar con aplicaciones de escritorio, pero presta especial atención a los mecanismos de sincronización y la confiabilidad requeridas por las aplicaciones musicales. La confiabilidad a través de la simplicidad es parte de los objetivos del proyecto.
Este código fuente se construye en cualquier sistema OpenBSD, Linux y FreeBSD sin modificaciones. Los parches para hacer que sndio funcione en NetBSD están disponibles en el árbol de puertos.
Hay binarios disponibles para los siguientes sistemas operativos.
Muchos programas de código abierto, incluyendo los principales reproductores multimedia, navegadores web, librerías de audio y utilidades que soportan sndio de forma nativa. Otros programas tienen parches en el árbol de puertos de OpenBSD esperando integración en fases previas.
sndio es una mejora del audio de OpenBSD y sub-sistemas MIDI. Cuenta con un servidor de audio y MIDI, y provee una nueva API basada una la biblioteca. Este marco está diseñado con ciertas restricciones de aplicaciones de audio en mente: estricto control de latencia y sincronización precisa entre transmisiones de audio. Admite las conversiones de remuestreo y formato al vuelo, compartiendo dispositivos entre múltiples aplicaciones, sea un dispositivo en múltiples subdispositivos y consecuente sincronización con aplicaciones que no son de audio. La simplicidad de la arquitectura, el diseño y la implementación son lo más importante, y lo que intentan obtener es una herramienta ligera, rápida y confiable.
Las aplicaciones de escritorio y de audio musical requieren que el sistema operativo exponga el hardware de audio y MIDI. Pero hay un desfase entre los requisitos de las aplicaciones y lo que ofrece el hardware. El subsistema de audio de alto nivel, una capa intermedia entre las aplicaciones y los controladores de dispositivos, se encarga de llenar ese vacío. Puede utilizarse para:
NetBSD tiene un kernel de audio que sólo se encarga de las conversiones de formato y el remuestreo 4; permite ejecutar casi todas las aplicaciones en la mayoría del hardware soportado, pero no permite ejecutar múltiples aplicaciones de audio simultáneamente. FreeBSD tiene un espacio de trabajo en el núcleo similar que también puede dividir dispositivos hardware en múltiples dispositivos lógicos y aplicar efectos digitales sobre la marcha 5; permite compartir dispositivos entre múltiples programas, pero no proporciona ningún mecanismo a nivel de sistema para sincronizarlos. OSS es un kernel framework comercial de código abierto proporcionado por Front technologies con características similares al de FreeBSD. Todas estas implementaciones exponen API basadas en llamadas al sistema (en contraposición a las bibliotecas). Linux utiliza ALSA: un marco de trabajo rico y complejo que se ejecuta como una biblioteca de espacio de usuario 6. Se basa en extensiones (plug-ins) que procesan flujos de audio sobre la marcha. Existen extensiones para prácticamente todo: mezclas, efectos, conversiones, remuestreo, etc.
Nota
4 El rango dinámico está definido por: 20 log (a/aO) donde a es la amplitud máxima, y a0 es la amplitud mínima de la señal. Con muestras de 16 bits, la amplitud máxima es 216, y la amplitud mínima es 1. El rango dinámico es así: 20 log 216 ≃96dB.
Nota
5 Esta declaración es falsa para las interfaces de audio profesionales que pueden admitir hasta 120 dB.
Nota
6 Cualquier señal continua con un espectro limitado se puede muestrear y convertir nuevamente al original sin pérdida de información (Teorema de Shanon). Con este punto de vista, el remuestreo consiste simplemente en calcular la señal continua y volver a muestrearla a la nueva solicitud.
Para superar las limitaciones del subsistema de audio, se pueden usar ciertas bibliotecas y servidores de audio del espacio de usuarios. Por ejemplo, los proyectos GNOME y KDE solían usar Esound y Art, superar las limitaciones del subsistema de audio de Linux antes de que ALSA estuviera disponible; ahora son reemplazados por Pulse, que tiene aún más funciones que los complementos ALSA 7 y 8.
Nota
7 Por ejemplo, al procesar una señal grabada en hardware con un rango dinámico de 96 dB, el ruido generado por el procesamiento debe ser tal que la relación señal sobre ruido se mantenga por encima de 96 dB.
Nota
8 Pero probablemente los programas que usan E/S de bloqueo rara vez necesitan eventos asincrónicos.
Los anteriores marcos de trabajo en el kernel o en el espacio de usuario suponen que las aplicaciones de audio son independientes, es decir, que la sincronización o el intercambio de datos entre aplicaciones no son gestionados por el subsistema de audio. Este tipo de marcos son útiles para la producción musical (u otras tareas de audio más complejas) siempre que todo el procesamiento relacionado con el audio se realice dentro de un único programa monolítico. El marco de trabajo (framework) jack supera esta limitación: permite que los programas cooperen: pueden pasarse datos de forma sincrónica entre ellos; además, jack proporciona un mecanismo de sincronización para aplicaciones que no son de audio. Por otro lado, jack sólo admite un formato de muestreo y funciona a una frecuencia de muestreo fija, lo cual es aceptable para aplicaciones musicales. En teoría, jack podría utilizarse también para escritorio, pero las distribuciones de escritorio de Linux han privilegiado otros marcos de trabajo.
El marco de trabajo sndio propuesto intenta cumplir con la mayoría de los requisitos de las aplicaciones de escritorio, pero presta especial atención a los mecanismos de sincronización requeridos por las aplicaciones musicales. La implementación actual admite conversiones, remuestreo, mezcla, mapeo de canales, división de dispositivos y sincronización de transmisiones de audio. Además, el volumen de aplicación y la sincronización están controlados por protocolos MIDI estándar, lo que permite la interoperabilidad no solo con aplicaciones MIDI sino también con hardware MIDI conectado a la máquina. Estos aspectos son novedosos en el mundo Unix. La simplicidad y la robustez de la arquitectura, el diseño y la implementación son parte de los requisitos; Por lo tanto, no se proporcionan ciertas características complicadas o no esenciales (por ejemplo, efectos, monitoreo, transparencia de red).
Primero, presentamos el problema que sndio intenta resolver y los objetivos del proyecto. Luego discutimos todas las opciones técnicas en el debate para demostrar que son una consecuencia natural de los objetivos del proyecto. Luego presentamos la arquitectura sndio resultante. Finalmente mostramos pocos casos de uso para ilustrar cómo se usa en la practica.
Nota
1 Escriba programas que hagan una cosa y lo hagan bien. Escriba programas para trabajar juntos. Doug McIlroy.
El rendimiento está relacionado con el tiempo de CPU consumido para realizar una tarea determinada, mientras que la capacidad de respuesta mide qué tan rápido se procesa un evento. No existe una relación directa entre el rendimiento y la capacidad de respuesta: dependiendo de para qué esté diseñado un programa, puede tener un mal rendimiento y una buena capacidad de respuesta o lo contrario
Un servidor de audio es un proceso limitado de E/S: después de todo, se supone que es solo una capa delgada entre la aplicación y el controlador del dispositivo. Por lo tanto, su consumo total de CPU es muy pequeño y se supone que es insignificante en comparación con los recursos de CPU disponibles en la máquina. Entonces "desperdiciar" ciclos de la CPU no son un problema, ya que el tiempo total de CPU consumido permanece insignificante.
La capacidad de respuesta, por otro lado, es de primera importancia: por ejemplo, el servidor de audio debe producir datos para reproducir tan pronto como el dispositivo lo solicite, para reducir al mínimo la posibilidad de que se agote el búfer, lo que provocaría un sonido entrecortado. Del mismo modo, un evento MIDI «nota de reproducción» procedente de un teclado MIDI debe procesarse inmediatamente y transmitirse al sintetizador que producirá el sonido real.
En los sistemas similares a UNIX, se accede al hardware de audio a través de un controlador de dispositivo de caracteres. El código de conversión, mezcla y remuestreo es una capa intermedia entre el controlador del dispositivo y la aplicación. Solo el controlador del dispositivo debe ejecutarse en el espacio del núcleo; Las conversiones y la mezcla se pueden realizar en el espacio del usuario como un proceso de usuario regular o en modo núcleo (kernel).
En una implementación de espacio de usuario, la aplicación produce datos de audio, los transmite al servidor de audio, que a su vez los procesa y los transmite al kernel. En una implementación de solo núcleo, la aplicación produce datos de audio y los transmite directamente al núcleo, que hace las conversiones y transmite el resultado al hardware.