Versión 2.19

  • No hay nuevas funciones, solo correcciones de errores.
  • Esta versión es compatible oficialmente con Windows 10 y Windows 11.
  • También se confirmó que funciona con Windows 7 y Windows 8, aunque con algunos defectos visuales menores en la GUI.
  • Informar errores a feedback@asio4all.com!

Cambios desde la versión 2.18

  • Solucionar un problema de agregación al mezclar la salida de WaveCyclic y los dispositivos de entrada muestreados de WaveRT, que provocaba distorsión de la señal de entrada.
  • Soluciona el problema del bucle de reinicio esporádico del host en Studio One (y posiblemente también en otros hosts).
  • Eliminar el ID de PnP de la ventana de información sobre herramientas del dispositivo, lo que simplifica un poco la interfaz gráfica de usuario.
  • Se corrigió la detección del estado de conexión/desconexión de los dispositivos Bluetooth. Esto provocaba que algunos dispositivos conectados desaparecieran y que algunos desconectados fueran visibles.
  • Se corrige una pequeña fuga de recursos en las solicitudes de reinicio del host.
  • Se han realizado algunos ajustes menores en el manejo del búfer de WaveRT.


Publicado

in

,

by

Tags:

Comentarios

44 respuestas a “Versión 2.19”

  1. Estoy experimentando interrupciones de audio, crujidos y reproducción inestable al usar ASIO4ALL con una interfaz de guitarra USB basada en el códec USB TI PCM2902 (que aparece en Windows como dispositivo de sonido USB PnP).
    Mi sistema es estable y LatencyMon no reporta problemas importantes de latencia DPC, pero los problemas persisten específicamente con este dispositivo.
    Configuración actual:
    Ventanas 10 x64
    ASIO4TODOS 2.19
    44.1 kHz

    Probé con varios tamaños de búfer (256 / 512 / 1024).
    El problema se produce en Guitar Rig y en los simuladores de amplificadores.
    La entrada del dispositivo funciona y se detecta la señal de audio, pero la reproducción a menudo presenta chasquidos o interrupciones.
    ¿Podrían investigar posibles mejoras de compatibilidad o estabilidad para los dispositivos de audio USB basados ​​en PCM2902?
    Gracias por tu trabajo en ASIO4ALL.

    1. Legacy WaveCylic es lo siguiente en la lista de cosas por hacer.
      Por el momento, esta versión no tiene los reinicios frecuentes:
      https://asio4all.org/downloads/test/ASIO4ALL_2_21_test.exe

      Aún se necesita trabajar un poco más en mejorar la latencia de ida y vuelta, pero las interrupciones deberían haber desaparecido.

      1. Hola,
        Gracias por la versión de prueba y por investigar el problema de Legacy WaveCyclic.
        Probé la nueva versión de prueba ASIO4ALL 2.21 con mi interfaz de guitarra TI PCM2902 USB CODEC (dispositivo de sonido USB PnP).

        Los problemas de interrupciones de audio parecen haberse solucionado por completo, lo cual supone una gran mejora.

        Sin embargo, tras unos 3-5 minutos de reproducción, el audio empieza a distorsionarse progresivamente. Curiosamente, si hago clic en cualquier elemento del panel ASIO4ALL o vuelvo a abrir el panel de control, el sonido se normaliza inmediatamente durante unos minutos.

        Este comportamiento se repite de forma constante.

        Mi configuración:

        Ventanas 10 x64
        44.1 kHz
        Probé con varios tamaños de búfer (256/512/1024).
        Equipo de guitarra / Fortin Nameless
        Entrada: Códec USB TI PCM2902
        Salida: Altavoces Realtek

        LatencyMon no reporta problemas importantes de latencia DPC.

        Da la sensación de que la sincronización del flujo de audio o del búfer se desajusta con el tiempo hasta que ASIO4ALL se "actualiza" al interactuar con el panel.

        Espero que esta información ayude con la depuración.

        Gracias de nuevo por su trabajo y apoyo.

      2. La última versión en la que mi tarjeta de sonido Audient iD14 puede comunicarse con ASIO4ALL a través del kernel es la versión 2.17 beta2 y anteriores. Las actualizaciones posteriores no pueden comunicarse con el kernel de mi tarjeta de sonido. Por ejemplo, el tiempo de ida y vuelta de audio con bypass de seguridad en la versión 2.16 era de 3 milisegundos, pero con las actualizaciones más recientes es de 13 milisegundos. Esto indica un problema de comunicación con la tarjeta de sonido. También probé la versión 2.21 y el problema persistió.

        1. ¿Cómo mediste la latencia de ida y vuelta?

          1. Utilicé los cálculos internos de Fender Studio para medirlo.
            Incluso a oído, se puede notar que la latencia de ida y vuelta es correcta.

        2. Tu DAW no mide nada. Simplemente consulta al controlador ASIO y muestra la información que recibe. De esta forma, puedo crearte un controlador ASIO con latencia cero sin problema, aunque técnicamente sea imposible.

          Más información sobre la latencia de ida y vuelta: https://asio4all.org/latency-compensation/

          1. Tengo un sistema optimizado y tengo un problema con el controlador de mi tarjeta de sonido porque tiene una limitación de seguridad y no puedo lograr una latencia menor. La razón por la que uso asio4all es para sortear esta limitación 🙁

  2. La versión 2.18/2.19 supone una mejora respecto a la 2.17, que me estropeó la configuración. Gracias por las mejoras.

  3. He encontrado un nuevo error en ASIO4ALL. Al usar “Studio One” en modo de dispositivo WaveRT, falla la solicitud del tamaño del búfer.
    ¿Podrían revisar este asunto, por favor? Muchas gracias.
    Saludos cordiales 🙂

    1. Intenta usar ASIO4ALL UI (Interfaz de usuario) era un error desde la versión 2.17.

    2. Permitir que el host anule el tamaño del búfer ASIO es un vestigio de diseño de hace mucho tiempo. Este enfoque siempre presentará un problema de causa y efecto.

      El tamaño del búfer ASIO siempre se puede configurar dentro del panel de control de ASIO4ALL.
      Eliminaremos la opción para que el host pueda anular la configuración. Simplemente no hay ningún beneficio práctico, además de que resulta confuso y propenso a errores.

      1. Este problema no existía antes; acaba de surgir. Simplemente lo menciono para preguntar si tiene solución, no para discutir sobre qué fue primero: el huevo o la gallina. Siempre se ha dado por sentado que la gallina fue antes que el huevo, y esta conclusión ya estaba establecida. Ahora mismo no deberíamos debatir sobre quién tiene razón; el problema ha surgido y me gustaría pedirles su ayuda para resolverlo.
        Aunque creo que tienes razón, plantear este tipo de dilema del huevo o la gallina me hace sentir que estás presumiendo, ¿sabes? Solo te lo comenté porque te considero alguien de confianza. De lo contrario, no habría dicho nada.

        1. Con el debido respeto, ¡lo tienes al revés!

          El primer pollo (necesariamente) provino de un huevo, puesto por algún ser que aún no era del todo un pollo (que no necesariamente calificaba completamente como "pollo", todavía).

          Por lo tanto, el huevo fue lo primero.

          En lo que respecta al tamaño del búfer ASIO, el mecanismo es el siguiente:
          1.) El controlador informa al host sobre el tamaño de búfer que prefiere.
          2.) El host llama a “CreateBuffers()”, con un argumento de tamaño de búfer que es igual al valor preferido del controlador, o algo completamente diferente.

          Por lo tanto, no hay nada que impida que Studio One ignore el tamaño de búfer preferido por el controlador y establezca el suyo propio. ¡Nada!

          Pero no es así. Más bien, espera que el controlador también cambie sus preferencias la próxima vez que el host llame a GetBufferSize(). Si el controlador no cambia de opinión y se empeña en devolver su tamaño preferido (que es solo una sugerencia), Studio One se enfadará e ignorará la modificación del tamaño del búfer en su propio cuadro de diálogo de configuración de audio, sin motivo alguno.

          Aquí tienes tu dilema del huevo y la gallina.

          Claro, podríamos simplemente añadir un mecanismo que permita al controlador recuperar el control sobre sus propias preferencias cada vez que el usuario modifique el tamaño del búfer ASIO en el panel de control ASIO. Esto añadiría una complejidad innecesaria a una solución que solo funciona el 90 % de las veces.

          La versión de prueba tiene lo siguiente: https://asio4all.org/downloads/ASIO4ALL_2_20_test.exe

          – o podríamos simplemente indicarle al host que debe ajustarse al tamaño del búfer definido por el controlador (estableciendo max=min=preferred) y así evitar por completo cualquier tipo de ambigüedad.

      2. Los controladores ASIO estándar permiten que la aplicación host cambie la frecuencia de muestreo. No estoy juzgando si esto es correcto o incorrecto; simplemente es una práctica común. Solo lo planteo como punto de discusión, no para debatir sobre si es correcto o incorrecto. Aunque creo que tienes razón, simplemente estoy planteando el tema.

      3. Incluso podrías añadir un interruptor para que los usuarios elijan si permiten o no que el host cambie la frecuencia de muestreo, en lugar de entrar en esta discusión del tipo "¿qué fue primero, el huevo o la gallina?" conmigo.

  4. Por alguna razón, 2.19 [Final] no funciona para muchas personas, no produce ningún sonido. Sin embargo, 2.19_Test (que estaba vinculado en tu publicación 2.18: https://asio4all.org/downloads/ASIO4ALL_2_19_Test.exe ) funciona muy bien. Estoy usando audio Realtek; WASAPI y Steinberg Built-in funcionan perfectamente.

    1. Avatar de Michael Tippach
      Michael Tippach

      Prueba a configurar el tamaño del búfer ASIO a >= 15 ms, a modo de experimento. ¿Hay alguna diferencia?

      1. Sí, me funciona con esta configuración:

        Tamaño del búfer ASIO: 768 spls (16/21 ms)
        Modo de bajo consumo: Apagado
        Entrada: deshabilitada
        Salida: solo auriculares
        Compensación de latencia (entrada/salida): 16 muestras
        Frecuencia de muestreo: 48 kHz
        DAW: Reaper 7.69 (abril de 2026)
        Sistema operativo: Windows 11 Home 25H2 (abril de 2026)
        Controladores de audio: Realtek 6.0.9915.1 (17 de noviembre de 2025)

        1. ¿Has podido seleccionar algún tamaño de buffet ASIO inferior a 10 ms en versiones anteriores?

          1. Solo con 2.19_Test y 2.16

        2. Nuevo experimento: https://asio4all.org/downloads/ASIO4ALL_2_20_TRACE.exe
          Esta es una versión de depuración y generará un archivo llamado "ASIO4ALL Debug Log.txt" en su escritorio.

          Las líneas más interesantes que hay ahí:

          [INFO] Comprobando el rango de tamaño del búfer…
          [INFO] Rango de tamaño de bloque (Spls) MÍN =
          [INFO] Rango de tamaño de bloque (Spls) MÁX =

          ¿Puedes encontrarlos?

          1. Sí. Aquí están sus resultados:

            [INFO] Comprobando el rango de tamaño del búfer…
            [INFO] Rango de tamaño de bloque (Spls) MÍN = 256
            [INFO] Rango de tamaño de bloque (Spls) MÁX = 96000

            Gracias de antemano por su tiempo para mejorar ASIO4ALL.

        3. Avatar de Michael Tippach
          Michael Tippach

          Entonces, esta versión de depuración debería funcionar para usted, incluso con tamaños de búfer < 512 muestras. ¿Correcto?

          1. Intenté realizar pruebas con la compilación de depuración ( https://asio4all.org/downloads/ASIO4ALL_2_20_TRACE.exe ) pero no funciona. La configuración ASIO normal (ASIO + Debug + Offline Settings) funciona correctamente, sin embargo, la compilación TRACE bloquea Reaper 7.69 casi inmediatamente después de cargarse, tan rápido que el archivo .txt "ASIO4ALL Debug Log" se crea en el escritorio justo después del bloqueo.
            —Configuración de prueba: Reaper 7.69 con VSL piano (VST3i) + iamreverb 1.4.3 (VST3) + Pro-Q4 (VST3) + Luego más presión con: 2.ª pista con Kontakt 8.9 (todos los VST3/i actualizados a abril de 2026)
            Frecuencia de muestreo solicitada: 48 kHz, sin entrada, 1 salida

            Comparación de versiones (misma configuración base en todas)
            2.16 Configuración predeterminada. 512 muestras → latencia de 10/11 ms (12 ms con compensación de 16 muestras). Sin artefactos. Con una carga VST mayor, se necesitan 640 muestras → 14/14 ms.
            2.17 Configuración predeterminada, modo de bajo consumo desactivado. 512 muestras → 10/11 ms. Sin artefactos. Con mayor carga, se necesitan 576 muestras → 13/23 ms.
            2.18 Configuración predeterminada, modo de bajo consumo desactivado. 512 muestras → 10/11 ms. Sin artefactos. Con mayor carga, se necesitan 576 muestras → 12/21 ms.
            2.19 Configuración predeterminada, modo de bajo consumo desactivado. Solo funciona a 768 muestras → 16/21 ms. Sin artefactos. El búfer ya es tan grande que añadir más VST no me obliga a aumentarlo más; Reaper ni siquiera se inmuta.
            2.19_Prueba al ganador
            Configuración predeterminada, modo de bajo consumo desactivado. Funciona sin problemas a 512 muestras → 10/11 ms. Sin artefactos. Y lo mejor de todo: bajo una carga VST intensa, se mantiene en 512 muestras → 10/11 ms. No es necesario aumentar el búfer. Esta es la única versión que mantiene una baja latencia Y un bajo consumo de recursos bajo presión.

          2. Segunda respuesta:
            Tras realizar más pruebas con la versión 2.16 (junio de 2024), aunque ya no sea relevante en 2026, obtuve estos resultados con los controladores Realtek 6.0.9915.1 de Lenovo (noviembre de 2025) y Windows 11 Home 25H2 (abril de 2026): mi configuración no puede manejar nada por debajo de 512 muestras, y la mayoría de los valores superiores generan artefactos bajo carga pesada. Solo 512 y 768 muestras funcionan correctamente. Todo lo demás falla.

            Como dije antes, su versión 2.19_Test (la mejor):
            Configuración predeterminada, modo de bajo consumo desactivado. Funciona sin problemas a 512 muestras → 10/11 ms. Sin artefactos. Y lo mejor de todo: bajo una carga VST intensa, se mantiene en 512 muestras → 10/11 ms. No es necesario aumentar el búfer. Esta es la única versión que mantiene una baja latencia Y un bajo consumo de recursos bajo presión.

        4. Si logramos averiguar por qué la compilación de depuración provoca que Reaper falle, es muy probable que en el futuro se pueda reducir el búfer ASIO hasta 64 muestras.

          ¿Se trata de un sistema AMD y el controlador de audio es “Realtek (xyz) con HAP”?

          1. Sí, CPU: AMD Ryzen 5 5500U (UEFI: 19 de marzo de 2025, SMU Firmware Rev. 55.93.0)
            Controladores del chipset AMD: 8.02.18.557 (marzo de 2026)
            Sistema operativo: Windows 11 Home 25H2 (abril de 2026)
            Hardware de audio: Realtek: HDAUDIO\FUNC_01&VEN_10EC&DEV_0257&SUBSYS_17AA38BC&REV_1000
            Controlador de audio: Realtek 6.0.9915.1 (17 de noviembre de 2025) / hdxapclv.inf

          2. Actualización: logré que la versión 2.20 funcionara con Reaper 7.69. El truco: desinstalar ASIO4ALL, iniciar Reaper, cambiar el backend de audio a WASAPI, cerrar Reaper y luego reinstalar y configurar ASIO4ALL 2.20. Después de eso, funciona correctamente.
            Ahora veamos la diferencia con respecto a la versión 2.19 (final): en la versión 2.20, el tamaño mínimo de mi búfer de trabajo es de 576 muestras, lo que resulta en una latencia de 12/21 ms. Es más alta de lo que me gustaría, pero la buena noticia es que no hay artefactos.
            Bonificación adicional: ASIO4ALL ahora funciona bien con Foobar2000 2.26 y AIMP 6 (ASIO + VST2/3). Al usar auriculares intrauditivos medidos con un B&K 5128 y un objetivo de ecualización de campo difuso (5128), AIMP suena notablemente mejor que Foobar. Sí, hay latencia, pero ASIO4ALL combinado con un ecualizador paramétrico como FabFilter Pro-Q 4 (4.12) supone un cambio radical si quieres disfrutar de una lista de reproducción sin tener que usar un DAW completo.

        5. El ruido del choque sigue sonando raro.

          Aquí tienes una versión de prueba sin rastros. ¡Activa la opción "Depuración" durante la instalación! De esta forma, esperamos que se genere un volcado de memoria en caso de que volvamos a encontrarnos con este problema.

          https://www.asio4all.org/downloads/ASIO4ALL_2_20_test.exe – Versión de prueba sin registro.

          Sigue siendo interesante por qué no se obtiene un mejor rendimiento al reducir el tamaño del búfer ASIO. Con un búfer ASIO menor o igual a 512, ¿se obtiene audio, aunque con interrupciones ocasionales, o no se obtiene audio en absoluto?

          https://www.asio4all.org/downloads/ASIO4ALL_2_20_TRACE.exe – Versión de rastreo actualizada.

          Establezca el tamaño del búfer ASIO, por ejemplo, en 320 muestras e inspeccione el rastro en busca de líneas que se lean como:
          [INFO] Se establece el búfer SPL para <192 <=512 >512 (muestras) MÍN = 256 | MÍN*2 = 256 | MÁX = 480
          [INFO] Inicialización de SPL | Tamaño del búfer de paquetes pequeños = 1000 | pin = 2BC

          Las interrupciones ocasionales indican que su sistema está sufriendo graves problemas de compatibilidad en tiempo real, que en la mayoría de los casos se pueden solucionar mediante cambios de configuración. Por ejemplo, ¿ha desactivado la detección de presencia?

          1. Envié un correo electrónico a feedback@asio4all.com con mi análisis de la situación y soluciones alternativas, y adjuntos: CRA4D43.tmp (volcado de fallo) y registro de depuración de ASIO4ALL.

            Con 2.20_Trace, al configurar el tamaño del búfer ASIO a 512 muestras, bajo el valor que solicitó en el registro de depuración "[INFO] Establecer búfer SPL para <192 512 (muestras) MÍN = 256 | MÍN*2 = 256 | MÁX = 480"

            [INFO] Inicialización de SPL | Tamaño del búfer de paquetes pequeños = 800 | pin = 65C
            [INFO] Inicialización de SPL | Tamaño del búfer de paquetes pequeños = 800 | pin = 668
            [INFO] Inicialización de SPL | Tamaño del búfer de paquetes pequeños = 800 | pin = 694
            [INFO] Inicialización de SPL | Tamaño del búfer de paquetes pequeños = 800 | pin = 2F4
            ...
            Etc.

            NOTA: No se observaron interrupciones en ninguna versión desde la 2.16 hasta la 2.20. Las únicas compilaciones que fuerzan una latencia elevada sin artefactos son la 2.19 Final (768 muestras) y la 2.20_Test/Trace (576 muestras); con 512 muestras, no se produce salida de audio. Además, la versión 2.20 muestra un comportamiento anómalo de la memoria que indica una fuga.

            Gracias de antemano.

        6. Lo comprobé personalmente: si desinstalas ASIO4ALL, Reaper simplemente seleccionará el siguiente controlador ASIO de la lista. Si este presenta errores, Reaper se bloqueará, incluso sin tener ASIO4ALL instalado. Parece ser un problema de Reaper.

          He actualizado las versiones de prueba (con y sin registro). Utilice los enlaces anteriores.

          El problema de memoria debería haberse solucionado. Y también debería haberse evitado el fallo.

          El experimento interesante: ¿Qué sucede ahora si se reduce el tamaño del búfer ASIO a 192 muestras? Y: ¿qué sucede si se reduce a menos de 192 muestras?

          1. Buenas noticias. No hubo fallos y ahora puedo actualizar sin problemas entre compilaciones (por ejemplo, de 2.20_Test a 2.20_Trace). Cabe destacar que tengo Steinberg Built-in 1.0.9 configurado como controlador de respaldo. La versión anterior fallaba con esta configuración, pero la actual no.

            Los resultados son impresionantes: 512 muestras = 10/11 ms de latencia, sin artefactos. Nuevo mínimo para obtener audio limpio: 192 muestras = 4/11 ms, sin artefactos. Por debajo de 192 muestras, el controlador intenta emitir sonido, pero solo logra un crujido ocasional antes de quedarse completamente en silencio.

            Información de compilación de seguimiento:

            [INFO] Comprobando el rango de tamaño del búfer…
            [INFO] Rango de tamaño de bloque (Spls) MÍN = 256
            [INFO] Rango de tamaño de bloque (Spls) MÁX = 96000
            ---
            [INFO] Se establece el búfer SPL para <192 512 (muestras) MÍN = 256 | MÍN*2 = 256 | MÁX = 480
            [INFO] Inicialización de SPL | Tamaño del búfer de paquetes pequeños = f00 | pin = 570

            Gracias por su atención.

        7. ¡Es hora de un poco de "Ingeniería de Software Empírica"!
          He actualizado la compilación de prueba (sin registro) una vez más.

          Suponiendo que el controlador Realtek en los sistemas AMD sea algo "especial", en el sentido de que no admite un tamaño de paquete de 256 muestras, a pesar de haber anunciado que sí lo haría.

          Sin embargo, sí admite un tamaño de paquete de 480 muestras, lo que equivale exactamente a 10 ms.
          Sin embargo, 10 ms no es para presumir; así que veamos si podemos reducirlo en incrementos de 1 ms. Sabemos que 4 ms no funciona, porque así era en versiones anteriores.

          La compilación de prueba le permitirá probar todos los incrementos desde 5 … 10 ms configurando el tamaño del búfer ASIO de esta manera:

          <192 – 5 ms
          <256 – 6 ms
          <320 – 7 ms
          <384 – 8 ms
          <480 – 9 ms
          480 y más: 10 ms

          ¿Puedes encontrar alguna configuración por debajo de 480 que aún funcione?

          1. | Tamaño del búfer (muestras) | Latencia (ms) / Reaper 7.69
            | 512 | 10 / 11 |
            | 480 | 10 / 11 |
            | 448 | 9.3 / 11 |
            | 416 | 8.6 / 11 |
            | 384 | 8 / 11 |
            | 352 | 7.3 / 11 |
            | 320 | 6.6 / 11 |
            | 288 | 6 / 11 |
            | 256 | 5.3 / 11 |
            | 240 | 5 / 11 |
            | 224 | 4.6 / 11 |
            | 208 | 4.3 / 11 |
            | 192 | 4 / 11 |

            Por debajo de 192 muestras, no se produce ninguna salida de audio. Los medidores de volumen del DAW siguen registrando actividad de señal, pero no llega nada a la salida.

        8. Eh... ¿podrías confirmar que estás usando la versión que muestra "Development Preview 2604212037" en la interfaz gráfica y Reaper x64? De lo contrario, las lecturas de latencia de salida parecen un poco extrañas.

          Si coloca el cursor sobre el resultado, ¿qué dice la información emergente: "Polling" o "SPL"?

          1. Sí, estoy ejecutando Development Preview 2604212037 en Reaper 7.69 x64.

            1. (SPL) Modo de baja potencia.
            2. Sincronización de búfer alternativa (anteriormente el interruptor "Permitir modo de extracción").
            3. Remuestrear siempre a 44.1 kHz / 48 kHz.

            Las tres opciones estaban DESACTIVADAS.

            Al pasar el ratón por encima de mi única salida, no aparece nada relacionado con: SPL o Sondeo.

            A continuación, probé la sincronización de búfer alternativa; los resultados se midieron en Reaper 7.69 (latencia en ms):

            | Tamaño del búfer (muestras) | Después (ABS [Activado] + LC [0/0]) | Antes (sin ABS y con LC) |

            | 512 | 10/10 | 10/11 |
            | 480 | 10/10 | 10/11 |
            | 384 | 8/8 | 8/11 |
            | 288 | 6/6.0 | 6/11 |
            | 240 | 5.0/5.0 | 5/11 |
            | 192 | 4.0/4.0 | 4/11 |
            Nota: No pude lograr exactamente 9/9.0 ni 7/7.0.

            Estos son los valores que muestra la interfaz de Reaper. En cuanto a la calidad de audio en mi hardware actual: el sonido empieza a percibirse a partir de 288 muestras (6.0/6.0 ms), pero con mucha distorsión. Solo a partir de 512 muestras (10/10 ms) la salida se reproduce sin problemas.

            Resumen de los resultados en mi hardware, sin artefactos bajo carga elevada:
            Utilizando solo 512 muestras:
            Latencia: 10/10 ms con sincronización de búfer alternativa activada.
            Latencia: 10/11 ms con sincronización de búfer alternativa ACTIVADA más compensación de latencia (ENTRADA/SALIDA) a 16 muestras.

            Cabe destacar que, con la sincronización de búfer alternativa desactivada y la compensación de latencia (entrada/salida) configurada en 16 muestras, mi hardware produce un audio limpio (sin artefactos) bajo una carga alta en todo el rango, desde 192 muestras (4/11 ms) hasta 512 muestras (10/11 ms).

        9. Olvídese por un momento de la "Sincronización de búfer alternativa". Probablemente, esto pondrá el dispositivo en modo de sondeo, lo cual no resulta muy útil en este caso.

          He puesto otra versión de prueba aquí: https://asio4all.org/downloads/ASIO4ALL_2_20_test.exe (sin registro de seguimiento)
          https://asio4all.org/downloads/ASIO4ALL_2_20_test_TRACE.exe (con registro de seguimiento)

          La marca de tiempo en la barra de título de la ventana de la interfaz gráfica de usuario debería mostrar: 202604221115

          Se corrigió la notificación de la latencia de salida, que *no* debería permanecer constante cuando el tamaño del búfer ASIO cambia en un rango amplio.

          Relación entre el tamaño del búfer ASIO y el tamaño del paquete interno, como antes. Si obtiene sonido con un búfer ASIO de, por ejemplo, 256, realice un seguimiento y busque líneas que se parezcan a:

          [INFO] Inicialización de SPL | Tamaño del búfer de paquetes pequeños = 600 | pin = 578
          [INFO] KSPROPERTY_RTAUDIO_BUFFER_WITH_NOTIFICATION | Tamaño sin SPL = 15c0 | pin = 578
          [INFO] GetRtProperty() 5 | pin = 578 | bytes devueltos = 16
          [INFO] Base = E9C0D00 | Tamaño = 600 | Barrera de memoria = 1

          En la primera línea, "Size" indica el tamaño solicitado; en la última, el tamaño del búfer devuelto. En su sistema, "F00" equivaldría a un tamaño de paquete de 10 ms. Cuanto menor sea el tamaño, mejor.

          1. Versión probada: 2604221115 (2026/04/22 11:15)

            Configuración:
            – Modo de bajo consumo: Desactivado
            – Compensación de latencia (entrada/salida): 0 muestras
            – Frecuencia de muestreo solicitada por REAPER 7.69 x64: 48 kHz
            – Entrada: Ninguna
            – Salida: 1 (Salida de audio Realtek HD con HAP)

            Resultados del tamaño del búfer:

            Tamaño mínimo del búfer sin artefactos de audio: 192 muestras = Latencia: 4.0 ms de entrada / 14 ms de salida
            Tamaño mínimo del búfer con artefactos de audio: 64 muestras = Latencia: ~1.3 ms de entrada / 6.7 ms de salida

            Lecturas del registro de depuración:

            Con 192 muestras (libres de artefactos):

            [INFO] Inicialización de SPL | Tamaño del búfer de paquetes pequeños = f00 | pin = A40
            [INFO] KSPROPERTY_RTAUDIO_BUFFER_WITH_NOTIFICATION | Tamaño sin SPL = 1000 | pin = A40
            [INFO] GetRtProperty() 5 | pin = A40 | bytes devueltos = 16
            [INFO] Base = 910000 | Tamaño = 1000 | Barrera de memoria = 0

            A las 64 muestras (con artefactos):

            [INFO] Inicialización de SPL | Tamaño del búfer de paquetes pequeños = 900 | pin = 448
            [INFO] KSPROPERTY_RTAUDIO_BUFFER_WITH_NOTIFICATION | Tamaño sin SPL = 600 | pin = 448
            [INFO] GetRtProperty() 5 | pin = 448 | bytes devueltos = 16
            [INFO] Base = D480000 | Tamaño = 1000 | Barrera de memoria = 0

          2. Segunda respuesta:
            Sospecho que puede haber un valor informado incorrectamente en la compilación 2604221115 (2026/04/22 11:15).
            Con 512 muestras, Reaper informa 10/10 ms (entrada/salida). Sin embargo, los tamaños de búfer inmediatamente superiores e inferiores devuelven valores asimétricos:

            480 muestras → 10/20 ms
            512 muestras → 10/10 ms
            576 muestras → 12/22 ms

            Entiendo que existen limitaciones de hardware, pero mi pregunta es: ¿puede ser correcta la lectura de 10/10 ms a 512 muestras en Reaper 7.69, dado que ambos tamaños de búfer vecinos informan una latencia de salida significativamente mayor?

        10. La notificación de latencia 10/10 con un tamaño de búfer de 512 es correcta, aunque no muy intuitiva.

          Si el tamaño del búfer ASIO coincide exactamente con el tamaño del paquete del controlador, no necesitamos ningún búfer adicional. En su caso, el tamaño mínimo del paquete (que funciona correctamente con este controlador) es de 512 muestras.

          Si no hay una coincidencia exacta de tamaño, debemos sumar el tamaño completo del paquete a la duración del búfer ASIO (menos 1 muestra, en teoría). No es fácil de entender, ¡y además es diferente para la entrada!

          He creado otra versión de prueba para que puedas trabajar con ella, por el momento: https://asio4all.org/downloads/ASIO4ALL_2_20_AMD_HAP.exe

          De hecho, poseo al menos dos sistemas con un diseño de hardware idéntico o similar, y presentan un comportamiento parecido. Sin embargo, vivir en dos continentes supone un reto logístico. Tendré acceso a estos sistemas dentro de dos semanas; quizás entonces pueda solucionar el problema de que funcionen con un tamaño de paquete de 256.

          1. Antes que nada, gracias por esta compilación para AMD con HAP (Realtek). Si necesitas probar algo con un sistema AMD, con gusto colaboraré en las pruebas beta antes del lanzamiento de la versión 2.20. Aprecio mucho tu dedicación a este proyecto ASIO. Revisaré esta publicación de vez en cuando para ver si puedo ayudarte en algo más. ¡Hasta luego!

  5. ¡Gracias por vuestro excelente trabajo en ASIO4ALL!
    En la versión 2.19 se corrigió lo siguiente:
    “Se corrige un problema de agregación que se produce al mezclar la salida de WaveCyclic con los dispositivos de entrada sondeados de WaveRT, lo que provoca distorsión de la señal de entrada.”
    Pero la combinación inversa sigue teniendo el mismo error:
    Entrada: WaveCyclic (dispositivo de audio USB 1.1)
    Salida: WaveRT consultado (audio Realtek integrado)
    Sintomas:
    Desviación del búfer de audio con el tiempo
    Aumento del retardo de salida
    Distorsión de la señal de salida, crujidos, ruido estático
    Se trata del mismo problema de deriva/sincronización del reloj, solo que en la salida en lugar de la entrada.
    ¿Es este el problema que pretendía solucionar la compensación de deriva del búfer mencionada anteriormente?
    ¿Podrían corregir este caso inverso en una versión futura?
    Muchos usuarios con entradas USB 1.1 sufren este problema desde hace años.
    ¡Gracias!

    1. Avatar de Michael Tippach
      Michael Tippach

      La corrección de la deriva del reloj aún no está implementada. La función de visualización de la frecuencia de muestreo actualmente solo ayuda a determinar si la deriva del reloj podría ser un problema en dispositivos individuales.

Deje un comentario

Su dirección de correo electrónico no será publicada. Las areas obligatorias están marcadas como requeridas *

Este sitio usa Akismet para reducir el correo no deseado. Conozca cómo se procesan los datos de sus comentarios.

Derechos de autor © Michael Tippach

Aviso Legal | Política de privacidad

Powered by WordPress

ASIO es una marca comercial de Tecnología de la información y comunicaciones Steinberg.  Todas las demás marcas comerciales son propiedad de sus respectivos dueños y se utilizan únicamente con fines de identificación del producto.

  • Introducción

    Introducción

    ¡Bienvenido a ASIO4ALL! Este manual le permitirá sacar el máximo provecho de su instalación de ASIO4ALL, especialmente en lo que respecta a las funciones avanzadas recientemente introducidas en esta versión de ASIO4ALL. Para lograr los mejores resultados posibles con ASIO4ALL, se recomienda que su computadora esté configurada adecuadamente. Para actualizaciones, ayuda e información adicional,

    más

  • Primeros pasos

    Primeros pasos

    Configuración del software de audio. Para usar ASIO4ALL, debe configurar su software de audio como corresponda. La forma de hacerlo depende de su aplicación específica. Generalmente, debe acceder al menú de configuración de audio y seleccionar ASIO -> ASIO4ALL v2. Ahora debería haber un botón para iniciar el...

    más

  • Lista de dispositivos WDM

    Lista de dispositivos WDM

    Esta es la lista de dispositivos de audio que se encuentran en su sistema. Resalte el dispositivo que desea modificar. Nota: ¡Todos los cambios de parámetros solo se aplican al dispositivo seleccionado! Active el dispositivo que desea usar haciendo clic en el botón junto a su nombre. En la imagen de arriba,

    más