Audio digital en GNU/Linux.
Requisitos mínimos del sistema
(Actualizado a Lenny 2-9-2008)
La latencia es el tiempo que tarda una señal en ser procesada, es decir, el tiempo que pasa entre que el momento en que pulsamos una tecla y aquel en que escuchamos el sonido correspondiente. Cuanto menor sea esta latencia, mejor será nuestro sistema de sonido. Los kernel 2.6 tienen una latencia decente; pero para disfrutar de audio digital con calidad profesional, es necesario aplicar parches y retocar cosas. Lo que sigue a continuación es una recopilación de diferentes fuentes de información disponibles en Internet. Cualquier nueva información (y hasta las correcciones ;)) es bienvenida.
Lo primero es descargar las fuentes del kernel desde kernel.org. En este caso, estamos usando el kernel 2.6.26.3. Descargamos también el parche realtime de Ingo Molnar. Hay que hacer clic con el botón derecho en el enlace correspondiente y escoger "guardar como".
Muy bien, vamos a descomprimir las fuentes del kernel en el directorio /usr/src. Podemos hacerlo como usuario a condición de pertenecer al grupo "src"
$ cd /usr/src $ tar jxvf /path/hasta/linux-2.6.26.3.tar.bz2 $ ln -s linux-2.6.26.3 linux $ cd linux
Aplicamos el parche realtime
$ patch -p1 < /path/hasta/patch-2.6.23.3-rt3
Si el parche se aplica correctamente, estamos listos para configurar el kernel. Personalmente me gusta usar "make menuconfig"
$ make menuconfig
Las opciones relevantes en el tema del sonido digital han ido evolucionando junto con el kernel: aquí proporcionamos un resumen.
CONFIGURACION DEL KERNEL
Block layer --->
IO schedulers --->
<*> Anticipatoty I/O scheduler
<*> Deadline I/O scheduler
<*> CFQ I/O scheduler
Default I/O scheduler (Deadline) --->
Processor type and features --->
[ ] Tickless system (ahorro energia, da problemas en amd64)
[*] High Resolution Timer Support
Processor family (Generic x86-64) --->
Premption model ---> Complete preemption (realtime)
[*] MTRR (Memory Type Range Register) support
[*] x86 PAT support
Timer frequency (1000 HZ) --->
[ ] Tickless system (ahorro energia, da problemas en amd64)
[*] High Resolution Timer Support
Processor family (Generic x86-64) --->
[*] x86 PAT support
Power management options --->
Anteriormente se recomendaba desactivar todo lo referente a gestión de energía (sobre todo si nuestra máquina era un equipo de escritorio). Esto es debido a que los ajustes de gestión de energía pueden afectar a la latencia. Sin embargo el tsc no se considera un clocksource lo bastante bueno desde el kernel 2.6.18. (ver este post). Por tanto actualmente se recomienda activar el soporte para ACPI. Esto proporciona un clocksource llamado acpi_pm que sí es fiable.
Sin embargo se recomienda no activar ningún módulo ACPI (como "button" por ejemplo) ya que algunos (pero no todos) empeoran la latencia. Por supuesto, desactivar estos módulos eliminará algunas características de gestión de energía, etc, en nuestro portátil, de modo que si estamos en ese caso, más vale hacer unas pruebas. En general, incluso con todos los módulos ACPI activados, nuestra latencia será como mucho similar a la de una máquina windows. Si con eso te conformas, actívalos. Si eres exigente con la latencia, desactívalos (sobre todo si tu máquina es de escritorio).
Podemos ver los clocksources disponibles podemos ver el contenido del archivo /sys/devices/system/clocksource/clocksource0/available_clocksource
cat /sys/devices/system/clocksource/clocksource0/available_clocksource
hpet acpi_pm jiffies tsc
Y podemos también ver cuál estamos usando efectivamente:
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
hpet
El HPET (High Precision Event Timer) es la nueva generación de clocksource que sustituye a los antiguos PIT y RTC. Se le llama también Multimedia Timer. Surgió de la colaboración de Intel y Microsoft y se trata de un reloj más preciso. Debemos activar el correspondiente soporte en el kernel si queremos usarlo (ver más abajo). Lo normal es que las placas modernas traigan HPET, aunque es posible que esté desactivado en la BIOS. También depende de que tengamos ACPI activado; es decir; si no hemos activado el soporte ACPI, no encontraremos ninguna opción en Device Drivers---> Character Devices ---> HPET . Asimismo, en arquitecturas de 32 bit tendremos una opcion "HPET Timer" en "Processor type and features" que convendrá activar (suponiendo que la placa tiene HPET). Una vez configuradas todas estas opciones, el sistema escoge automáticamente el mejor clocksource entre los disponibles.
Por tanto, las opciones "seguras" para baja latencia nos quedan así:
Power Management options--->
[*] Power Management Support
[*] ACPI (Advanced Configuration and Power Interface) Support --->
CPU Frequency Scaling --->
[*] CPU idle PM support
Dentro del submenú "ACPI Support" deberíamos dejar todo desactivado. Sin embargo, insistimos en que es posible usar al menos algunos de esos módulos, si no todos.
Dentro del Submenú "CPU Frequency Scaling" (suponiendo que activemos la opción) deberemos escoger almenos uno de los "governor" y usarlo como "governor" por defecto. Si nos preocupa la latencia, probablemente es el "performance governor" el que nos interesa. Los demás se pueden dejar como módulos.
Subsistema IDE
El subsistema IDE puede convertirse en un cuello de botella si no está bien configurado. Ver los "Audio hints" de Con Kolivas. Es importante NO configurar "IDE Taskfile access" (no se necesita normalmente) ni "generic/default IDE chipset support" (ya que debemos tener un módulo concreto, no genérico, para el chipset IDE de nuestra placa madre).
Device drivers --->
<*> ATA/ATAPI/MFM/RLL support--->
<*> Include IDE/ATA2 disk support
[*] Use multiple sector mode for Programmed I/O by default
[ ] IDE Taskfile access
< > generic/default IDE chipset support
[*] PCI IDE chipset support
[*] Generic PCI bus-master DMA support (no está en x86-64)
[*] Use PCI DMA by default when available (no en x86-64)
<M> El chipset PCI IDE que use tu placa madre
<M> Otros chipsets PCI IDE (si quieres que funcione en otras placas)
Subsistema RTC
Algunas aplicaciones de audio usan RTC (seguimos en Device drivers)
Character devices --->
<M> Enhanced Real Time Clock Support
<M> Generic /dev/rtc emulation (no está en x86-64-lenny)
< > Priority Inheritance Debugging (Blocker) Device Support
[*] HPET - High Precision Event Timer
[*] Extended RTC operation (no está en x86-64-lenny)
Si subimos un subnivel (hasta Device Drivers) encontramos alguna opción más que afecta al RTC: concretamente:
< > Real Time Clock ---> En Etch, era necesario activar esta opción. En Lenny, si lo hacemos, ALSA es incapaz de usar el RTC como timer (o al menos la opción queda oculta y sin configurar). No sabemos si ALSA es capaz de usar algún otro timer sin esa opción, pero sí sabemos que antes funcionaba así, de modo que dejamos esto desactivado (al parecer es para soportar timers añadidos a la placa madre ¿?) y pasamos a las opciones que afecta a ALSA.
ALSA
<*> Sound card support
Advanced Linux Sound Architecture ---> <M> Advanced Linux Sound Architecture--->
<M> Sequencer support
<M> Sequencer dummy client
<M> OSS Mixer API
<M> OSS PCM (digital audio) API
[*] OSS PCM (digital audio) API - Include plugin system
[*] OSS Sequencer API
<M> RTC Timer support
[*] Use RTC as default sequencer timer
tmpfs
Para que JACK (el servidor de audio) tenga un buen rendimiento es necesario tmpfs
File systems --->
Pseudo filesystems --->
[*] Virtual memory file system support (former shm fs)
Ya tenemos configurados todos los ajustes necesarios para conseguir un kernel con baja latencia. Salimos del make-menuconfig y compilamos como usuario con el siguiente comando:
$ fakeroot make-kpkg --append-to-version -loquesea --initrd kernel-image
Tras la compilación, tendremos un paquete .deb en el directorio /usr/src, listo para ser instalado (como root)
NOTA: Si se configura dentro del kernel todo lo necesario para arrancar (y no como módulo), no es necesario usar la opcion --initrd al compilarlo.
$ su
# dpkg -i paquete.deb
Y reiniciamos para que el nuevo kernel entre en accion.
AJUSTES DEL SISTEMA DE ARCHIVOS
No conviene usar reiser4 porque al parecer, aunque tiene un gran ancho de banda, también tiene bastante latencia. Es mejor reiser3, pero tiene la desventaja de que ha quedado obsoleto tras la llegada de reiser4. La recomendación es usar ext3 con algunos retoques adicionales. Tener una partición dedicada a nuestro trabajo con música es buena idea, ya que alguno de estos ajustes, muy buenos para lograr baja latencia, pueden interferir en otras cosas. Sin embargo, tampoco hay gran problema que apliquemos estos cambios a nuestra partición /home (que esta sí, deberíamos tenerla siempre, en mi opinión)
Los dos primeros ajustes se pueden hacer en el archivo /etc/fstab Se trata de especificar las opciones noatime y writeback. Suponiendo que las aplicamos en nuestra partición /home, la línea orginal en /etc/fstab podría ser parecida a esta
/dev/hdaX /home ext3 defaults 0 0
Y la modificada podría ser parecida a:
/dev/hdaX /home/ext3 defaults,noatime,writeback 0 0
Y la tercera optimización que podemos aplicar es usar tune2fs para tener un B-tree, de este modo las búsquedas, etc, serán más rápidas:
$ tune2fs -O dir_index /dev/hdaX
