Jack requiere que usted, el usuario experto, configure el servidor para determinar la latencia de procesamiento más baja posible para su máquina. (La latencia de procesamiento es el tiempo que le toma al servidor mover datos hacia / desde las aplicaciones del cliente y luego enviar / recibir el próximo "fragmento" de muestras de audio fuera del sistema). Jack entregará esos fragmentos de datos de audio a tiempo, o fallará y le dará una falta de funcionamiento del búfer (a veces llamado "abandono" o pops y clics) Si Jack sufre insuficientes constantemente, es su trabajo reiniciar el servidor con diferentes configuraciones o cambiar algo en las aplicaciones del cliente para que sean más eficientes para que pueda cumplir con sus plazos de audio. Dado que la configuración de su servidor se aplica de manera uniforme a todos los clientes, Jack es bastante útil para enrutar audio entre múltiples aplicaciones de audio y obtener resultados predecibles . (Es decir, es como conectar "jacks" en varios componentes de audio).
Pulse está diseñado para minimizar la cantidad de veces que el audio se cae debido a que el servidor no cumple con una fecha límite para enviar / recibir audio fuera del sistema. Al parecer, trata de hacer esto eligiendo un búfer grande para aplicaciones de cliente que no solicitan baja latencia de procesamiento , luego "inyectando" muestras en ese búfer para aplicaciones de clientes que tienen una fecha límite más pronto. Si intenta inyectar muestras tan pronto que no cumple con una fecha límite y causa un retraso, Pulse aumentará automáticamente la menor cantidad de tiempo que le permitirá al cliente enviar una actualización de audio al servidor. Los documentos de Pulse indican explícitamente que la latencia ultrabaja es decir, menos de 10 ms de latencia de procesamiento- No es un objetivo de diseño. Dado que Linux en sí (y probablemente su hardware) no fue diseñado para la programación de audio en tiempo real, sería capaz de creerlos.
En términos de configuración del usuario, Pulse es "ligero". (Se podría decir que Pulse tiene una latencia de configuración baja , algo que desafortunadamente muchas aplicaciones de audio de Linux aparentemente ignoran). En términos de su complejidad subyacente en comparación con Jack, Pulse es "gordo".
Para obtener una respuesta definitiva sobre cuál es más rápido, solo tendrá que obtener un dispositivo de bucle invertido y medir la latencia de ida y vuelta en su propio sistema para saber la verdad. La latencia de ida y vuelta es el tiempo que le toma a su sistema procesar audio y recibir lo que procesó nuevamente en el sistema. Hay tutoriales en línea que explican cómo hacer esto en Linux. Eso le dará una idea de lo que realmente está buscando, que es la latencia percibida : el tiempo que lleva desde el momento en que activa un evento (por ejemplo, rasguear las cuerdas de una guitarra) hasta el momento en que escucha el sonido por primera vez. eso resulta (por ejemplo, escuchar el acorde de la guitarra).
Finalmente, tenga en cuenta que Pulse y Jack se ubican por encima de ALSA en la mayoría de las distribuciones de GNU / Linux. Sé que solo preguntas por Jack vs. Pulse. Pero si está utilizando una sola aplicación de audio que se puede conectar directamente a ALSA, no hay forma concebible de que al agregar Pulse o Jack obtenga una latencia percibida más baja que ALSA solo. En ese sentido, tanto Pulse como Jack son "gordos".
tldr; ALSA solo es el más rápido, Jack es útil para encadenar múltiples aplicaciones de audio, y Pulse es probablemente el más fácil de usar cuando no te importa la latencia ultra baja. Ignore cualquier documentación o discusión que use el término latencia sin explicar qué tipo de latencia se entiende. (Desafortunadamente, tanto los documentos oficiales de Jack como las entradas de blog de Lennart sobre Pulse entran en esta categoría).
Nota : Puede haber casos extremos en los que desee utilizar una sola aplicación de audio y tenga una interfaz ALSA horrible y una interfaz Jack decente. En ese caso, usar Jack puede reducir la latencia. Pero si hablamos de aplicaciones diseñadas para minimizar la latencia, esos casos deberían ser raros. ¡Pero conecte un dispositivo loopback y pruebe mi hipótesis!