¿Por que los drivers ALSA de Linux dan menos latencia que los ASIO de Win?

  • 1
césar
#1 por césar el 27/05/2019
Quisiera saber el motivo por el cual ALSA en linux con mi interface de audio funciona a mucha menor latencia en comparacion a los drivers propios de focusrite para windows, que son ASIO y supuestamente son escritos por los mismos fabricantes quienes conocen a fondo el funcionamiento de sus dispositivos(osea que sus drivers deberian de ser los mejores en teoria).
He estado migrando a linux(especificamente la dristribucion kali) debido a que estoy comenzando mis estudios en programacion y este sistema operativo me es muy atractivo , quisiera conocer este mundo de linux en lo que voy a prendiendo de programcion. Por eso me anime a probar como es producir y grabar y me parece interesante saber que trabajare a menor latencia que en windows.
Si es que sabe alguien si como le hago para correr simuladores de amp dentro de mi daw(reaper) como amplitube, bias, etc. Les agradeceria un monton.
PD:No sean malos con migo si estoy en alguna profunda ignorancian en estos aspectos del audio, tampoco soy un profesional en esto, apenas grabo cosillas con mi guitarra xd.
Subir
OFERTAS Ver todas
  • -7%
    Modal Argon8 (B-Stock)
    559 €
    Ver oferta
  • -50%
    NI Komplete 15 Collector's Edition
    885 €
    Ver oferta
  • -20%
    Technics SL-1200M7 Lamborghini
    1.199 €
    Ver oferta
Libertizer
#2 por Libertizer el 27/05/2019
césar escribió:
No sean malos con migo si estoy en alguna profunda ignorancian en estos aspectos del audio


tu tampoco seas malo si ves que no te aclaramos tus dudas... :desdentado:
Subir
Alexmx03
#3 por Alexmx03 el 27/05/2019
Probablemente sea porque los drivers de Focusrite en sus gamas Scarlett y clarett por usb son del montón por no decir algo peor. Eso si, son de un color rojo precioso y las venden a patadas...
Subir
vagar
#4 por vagar el 27/05/2019
Precisamente porque conocen bien su hardware, es posible que los drivers del fabricante no arriesguen a dejar bajar la latencia a valores insostenibles (y, posiblemente, que no aportan una diferencia apreciable al oído humano).

Ten en cuenta que la latencia se puede bajar teóricamente todo lo que se quiera, hasta un búffer de una muestra por ciclo, pero lo importante es conseguir baja latencia SIN CORTES. Y cuanto más se baja la latencia, más riesgo hay de que se produzcan esos cortes que arruinan cualquier grabación, porque los búffers se llenan tan rápido que no da tiempo a que la CPU compense la sobrecarga que representa la gestión de entrada o salida en todo el proceso.

Que los drivers ALSA te permitan bajar la latencia hasta un límite menor no implica necesariamente que tu equipo pueda trabajar con seguridad a esa latencia. Depende de muchos otros factores como la velocidad de la CPU, la del disco, la configuración del hardware USB dentro de la arquitectura general del ordenador, la carga de software que estés utilizando, etc. Es todo mucho más complicado que simplemente mover un fader.

En cualquier caso, por debajo de 5 ms ya estamos en valores de propagación del sonido a menos de 2 metros, el oído humano no es capaz de separar ese retardo del sonido original.
Subir
Lenny
Carmelopec
#6 por Carmelopec el 01/06/2019
#3
No son los de RME, pero han mejorado sustancialmente.
Subir
Carmelopec
#7 por Carmelopec el 01/06/2019
No tengo conocimiento preciso; pero al parecer Unix, de donde salen Linux y Mac Osx, es una interfaz y un núcleo más ligero y más directo para comunicarse con lis recursos.
Subir
césar
#8 por césar el 07/06/2019
#2 agradezco sus amables respuestas. Han resolvido gran parte de mis dudas.
Subir
césar
#9 por césar el 07/06/2019
#7 Pues tambien verifique que en Mac OS se trabaja a menor latencia al igual que en linux.
Subir
césar
#10 por césar el 07/06/2019
#4 he probado hacer una grabacion basica con guitarras usando los mismos plugins y configuraciones, 1 en linux y otra en Windows. En linux a menor latencia trabaje igual de estable que a mayor latencia con windows,de hecho intente bajar la latencia a igual medida que en linux y note que en windows con ASIO ya comenzaba a cortarse el audio.
Subir
césar
#11 por césar el 02/08/2019
#7 segun he trasteado por internet ALSA es una arquitectura completa de audio que esta incrustada directamente en el kernel de linux, por lo cual ALSA tiene acceso directo al hardware y eso hace que tenga mucha menor latencia que un driver convencional ASIO que tiene que desviar las capas de software de Windows para tener acceso al Hawrdware, ademas de que tambien los ASIO de Focusrite estan llenos de bugs, en el caso de Core Audio de Mac Os que tambien es una arquitectura de audio incrustada en el kernel por eso es tan eficiente para trabajar a bajas latencias sin clipping en el audio. Es por eso que la mayoria de estudios profesionales compran MAC antes que PC ya que se olvidan de drivers Bugosos y de los pantallazos azules de W10.
Subir
GCC
#12 por GCC el 02/08/2019
Hola César,

Si no me equivoco ASIO es un servidor de audio que funciona sobre los drivers nativos de Windows (No tengo Windows en estos momentos). Por eso es posible que tenga algo más de latencia que trabajar sobre ALSA directamente, que es como hacerlo sobre los drivers del dispositivo sin usar ninguna capa intermedia a nivel de usuario.

Linux tiene dos servidores de audio, uno para uso normal, escuchar música, ver vídeos y jugar a algunos juegos que es Pulseaudio que es el que se instala por defecto, y otro dedicado a la edición de audio o para tareas en tiempo real que se llama Jack, que sería una especie de equivalente a ASIO en Windows. Lo que hacen tanto Pulseaudio como Jack es conectar y gestionar las entradas y las salidas de audio de las aplicaciones (MIDI también en el caso de Jack) con los drivers del Kernel y su acceso concurrente a los dispositivos (varias aplicaciones leyendo y escribiendo del mismo dispositivo, por ejemplo) por eso es posible que estos servidores añadan sobrecarga y tiempo al ser una capa adicional de Software.

En el caso de Jack, permite a nivel de usuario configurar como las aplicaciones se conectan a los recursos de audio del equipo de una forma más fina, por ejemplo, dispositivos MIDI, interfaces de audio (entradas/salidas) pudiendo elegir quién se conecta con quién, mejorando la latencia de Pulseadio (para uso genérico) y permitiendo el acceso exclusivo a un driver o dispositivo concreto, así como configurar los bitrates y las frecuencias de reproducción y de muestreo de las conexiones, mejorando su respuesta para casos de tiempo real. Curiosamente Jack también puede funcionar con y sobre Pulseadio, y a la inversa, pero no quiero complicar el asunto. así que aquí lo dejo.

Como dato curioso, Jack lleva mucho años de desarrollo (es anterior a ASIO) y en mi opinión es una maravilla. Linux tiene menos Daws y software comercial, pero pienso que tiene el mejor subsistema de audio de los sistemas operativos actuales, si, mejor que Apple. Otra de las cosas que permite Jack es distribuir los recursos de audio entre dos equipos (MIDI incluido) sobre ethernet con lo que es posible conectar dos Ardour en dos equipos distintos y compartir las interfaces de audio y enviar mensajería MIDI por la red de uno a otro.

Este enlace es muy explicativo y muestra por encima y compara cómo funcionan los subsistemas de audio de Windows y de Linux

https://www.learndigitalaudio.com/how-linux-audio-works-vs-windows-audio-2017

Saludos.
Subir
vagar
#13 por vagar el 02/08/2019
#12

Hay algunas inexactitudes en ese artículo, yo no lo tomaría como fuente.

ASIO es un modelo de driver de audio, alternativo a otros de Windows como DirectSound. No es un servidor de audio. Lo que sí funciona sobre los drivers nativos es ASIO4All, que es una capa de adaptación sobre WDM para interfaces que no tienen drivers ASIO nativos.

GCC escribió:
Jack, que sería una especie de equivalente a ASIO en Windows


No, para nada, eso es un error bastante gordo en el artículo citado. Jack es una capa de interconexión, entre unas aplicaciones y otras y entre aplicaciones y dispositivos de audio. ASIO es un modelo de driver, de acceso a la interfaz de audio.

#11

No, ASIO (nativo, no ASIO4All) también tiene acceso muy directo al hardware, saltándose los drivers de Windows. Por eso cuando lanzas una aplicación que accede al driver ASIO el resto de aplicaciones no puede usar la interfaz.

Linux tiene cosas muy buenas, pero no hace falta mitificarlo. Puede haber excepciones patológicas, pero es muy raro que nadie haga mejores drivers para un hardware que el fabricante de dicho hardware, que tiene la gran ventaja del acceso a toda la información sobre cómo está construido.
Subir
césar
#14 por césar el 04/08/2019
#13 Que buen aporte lo tuyo, ya me parecia raro que el diga que ASIO es un servidor de audio. Un punto en el que te equivocas es que en realiad cuando una aplicacion accede a ASIO las demas aplicaciones si tienen acceso a la interface sin problemas, yo siempre habria spotify o youtube mientras usaba vst's dentro de mi DAW como Bias FX tranquilamente. Solo si habilitas en el panel de control de windows la opcion de "Permitir que una aplicacion tome el control exlusivo de este dispositivo" puedes bloquear el uso de la interface a las demas aplicaciones.
En realidad es mucho mejor ALSA y Core Audio de las MAC que un driver escrito por el fabricante, ya que ALSA esta incrustado o mejor dicho es parte del kernel de linux, asi como Core Audio es parte del kernel de MAC OS y al ser un componente del kernel mismo estos tienen un acceso directo e inmediato al hardware, y no hace falta saber como funcionan para que estos componetes de kernel puedan trabajar con casi cualquier interface debido a que la mayoria (por no decir todas) son Class Compliant.
Lo que hace en realidad un driver para windows es intentar solventar esa carencia de un sistema de audio profesional en Windows, ya que el kernel de Windows no fue diseñado ni pensado para trabajar con audio en baja latencia. Muchas veces ese intento de solventar esa carencia sale mal y como resultado estan los drivers inestables de algunos fabricantes, hagan la prieba, eligan la interface con los peores drivers del mercado y pruebenlo en MAC y en Windows y veran que en MAC funciona de las mil maravillas, mientras en windows es un caos, todo por la culpa de que el equipo de desarrollo de los drivers son incompetentes. El unico fabricante que si tiene un buen equipo de desarrollo para sus drivers es RME.
Subir
Alexmx03
#15 por Alexmx03 el 04/08/2019
No sé si llevas o no razón, pero yo he podido comprobar por mi mismo cómo una interfaz de audio tenía una latencia infumable en mac y mejoraba algo en Windows pero no mucho,también todo lo contrarío. Y he tenido una presonus estudio por FireWire que necesitaba drivers si o si para poder funcionar en mac, y una motu que sin su software en mac tampoco funcionaba ni medio bien... eso de que todas son classcompilant no es cierto, quizá una mayoría, pero te aseguro que no todas. En lo que si estoy de acuerdo es que normalmente, en mac se consiguen mejores latencias al igual que se aprovechan muchísimo mejor los recursos de la máquina¿motivo? Ni idea, no soy informático, pero para mí ha quedado bien demostrado.
Subir
Hilos similares
Nuevo post

Regístrate o para poder postear en este hilo