Page d'accueil officielle d'ASIO4ALL

Pilote ASIO universel pour Windows

Version 2.19

  • Aucune nouvelle fonctionnalité, uniquement des corrections de bugs.
  • Cette version prend officiellement en charge Windows 10 et Windows 11.
  • Il est également confirmé qu'il fonctionnera avec Windows 7 et Windows 8, avec toutefois quelques artefacts visuels mineurs de l'interface graphique.
  • Signaler des bogues à feedback@asio4all.com!

Modifications apportées depuis la version 2.18

  • Correction d'un problème d'agrégation lors du mélange de périphériques de sortie WaveCyclic et d'entrées interrogées WaveRT, entraînant une distorsion du signal d'entrée.
  • Correction d'une boucle de réinitialisation sporadique de l'hôte dans Studio One (et peut-être aussi dans d'autres hôtes).
  • Supprimer l'identifiant PnP de la fenêtre d'info-bulle du périphérique, ce qui simplifie quelque peu l'interface graphique.
  • Correction de la détection de l'état de connexion/déconnexion des appareils Bluetooth. Auparavant, certains appareils connectés disparaissaient tandis que d'autres, déconnectés, restaient visibles.
  • Correction d'une fuite mineure de ressources lors des requêtes de réinitialisation de l'hôte.
  • Quelques ajustements mineurs apportés à la gestion des tampons WaveRT.

Télécharger ASIO4ALL 2.19 ⮱

Publié

in

,

by

admin

Tags:

Commentaires

44 réponses à « Version 2.19 »

  1. Avatar de Miki
    Miki

    Je rencontre des problèmes de coupures audio, de craquements et de lecture instable lorsque j'utilise ASIO4ALL avec une interface de guitare USB basée sur le codec USB TI PCM2902 (affiché sous Windows comme périphérique audio USB PnP).
    Mon système est stable et LatencyMon ne signale aucun problème majeur de latence DPC, mais les problèmes persistent spécifiquement avec cet appareil.
    Configuration actuelle :
    Fenêtres 10 x64
    ASIO4ALL 2.19
    44.1 kHz

    J'ai essayé plusieurs tailles de tampon (256 / 512 / 1024)
    Ce problème se produit dans Guitar Rig et les simulateurs d'amplis.
    L'entrée audio fonctionne et le signal est détecté, mais la lecture grésille ou se coupe souvent.
    Pourriez-vous étudier les améliorations de compatibilité ou de stabilité pour les périphériques audio USB basés sur le PCM2902 ?
    Merci pour votre travail sur ASIO4ALL.

    Répondre
    1. administrateur Avatar
      admin

      Legacy WaveCylic est la prochaine chose sur la liste des choses à faire.
      Pour le moment, cette version ne comporte plus les redémarrages fréquents :
      https://asio4all.org/downloads/test/ASIO4ALL_2_21_test.exe

      Il reste encore du travail à faire pour améliorer la latence aller-retour, mais les déconnexions devraient avoir disparu.

      Répondre
      1. Avatar de Miki
        Miki

        Bonjour,
        Merci pour la version de test et pour avoir examiné le problème lié à Legacy WaveCyclic.
        J'ai testé la nouvelle version de test ASIO4ALL 2.21 avec mon interface de guitare TI PCM2902 USB CODEC (USB PnP Sound Device).

        Les coupures audio complètes semblent désormais résolues, ce qui constitue une nette amélioration.

        Cependant, après 3 à 5 minutes de jeu, le son commence à grésiller et à se distordre progressivement. Curieusement, si je clique sur n'importe quel élément du panneau ASIO4ALL ou si je rouvre le panneau de configuration, le son redevient immédiatement clair pendant quelques minutes.

        Ce comportement se répète systématiquement.

        Ma configuration :

        Fenêtres 10 x64
        44.1 kHz
        J'ai essayé plusieurs tailles de tampon (256/512/1024).
        Guitar Rig / Fortin Nameless
        Entrée : Codec USB TI PCM2902
        Sortie : Haut-parleurs Realtek

        LatencyMon ne signale aucun problème majeur de latence DPC.

        On a presque l'impression que le flux audio ou la synchronisation du tampon se décale au fil du temps jusqu'à ce qu'ASIO4ALL soit « rafraîchi » par une interaction avec le panneau.

        J'espère que ces informations vous aideront à déboguer.

        Merci encore pour votre travail et votre soutien.

        Répondre
      2. Farzad Avatar
        farzad

        La dernière version permettant à ma carte son Audient iD14 de communiquer avec ASIO4ALL via le noyau est la version 2.17 bêta 2 et les versions antérieures. Les mises à jour ultérieures ne permettent pas la communication avec le noyau de ma carte son. Par exemple, le temps d'aller-retour audio avec contournement de sécurité était de 3 millisecondes avec la version 2.16, contre 13 millisecondes avec les mises à jour plus récentes. Ceci indique un problème de communication avec la carte son. J'ai également testé la version 2.21, sans succès.

        Répondre
        1. administrateur Avatar
          admin

          Comment avez-vous mesuré la latence aller-retour ?

          Répondre
          1. Farzad Avatar
            farzad

            J'ai utilisé les calculs internes de Fender Studio pour le mesurer.
            Même à l'oreille, on peut constater que la latence aller-retour est correcte.

        2. administrateur Avatar
          admin

          Votre séquenceur ne mesure rien. Il interroge simplement le pilote ASIO et affiche les données renvoyées. Ainsi, je peux vous créer un pilote ASIO à latence « nulle » sans problème, même si c'est techniquement impossible.

          Plus d'informations sur la latence aller-retour : https://asio4all.org/latency-compensation/

          Répondre
          1. Farzad Avatar
            farzad

            J'ai un système optimisé, mais j'ai un problème avec le pilote de ma carte son : une sécurité intégrée m'empêche d'obtenir une latence plus faible. J'utilise asio4all pour contourner cette limitation 🙁

  2. Manny Avatar
    Manny

    La version 2.18/2.19 représente une amélioration par rapport à la version 2.17 qui avait causé des problèmes sur mon système. Merci pour ces améliorations.

    Répondre
  3. Avatar de KJ
    KJ

    J'ai découvert un nouveau bug dans ASIO4ALL. Lors de l'utilisation de « Studio One » en mode périphérique WaveRT, la demande de la taille du tampon échoue.
    Pourriez-vous examiner ce problème ? Merci beaucoup.
    Bien cordialement 🙂

    Répondre
    1. L Avatar
      L

      L'utilisation de l'interface utilisateur ASIO4ALL était un bug depuis la version 2.17.

      Répondre
    2. administrateur Avatar
      admin

      Laisser l'hôte modifier la taille du tampon ASIO est une conception obsolète. Cette approche engendrera toujours un problème de dépendance circulaire.

      La taille du tampon ASIO peut *toujours* être définie dans le panneau de contrôle ASIO4ALL.
      Nous allons supprimer la possibilité pour l'hôte de passer outre. Cela ne présente aucun avantage pratique, et c'est source de confusion et d'erreurs.

      Répondre
      1. Avatar de KJ
        KJ

        Ce problème est inédit ; il vient tout juste d'apparaître. Je vous le signale simplement pour vous demander s'il est possible de le résoudre, et non pour polémiquer sur l'origine du problème (la poule ou l'œuf). On a toujours considéré que la poule était apparue avant l'œuf, et cette conclusion était déjà établie. À présent, il ne s'agit pas de débattre du bien et du mal ; le problème est là, et je sollicite votre aide pour le résoudre.
        Même si je pense que tu as raison, soulever ce genre de dilemme de la poule et de l'œuf donne l'impression que tu te la pètes, tu vois ? Je t'en ai parlé uniquement parce que je te fais confiance. Sinon, je n'aurais rien dit du tout.

        Répondre
        1. administrateur Avatar
          admin

          Sauf votre respect, vous vous trompez !

          Le premier poulet est (nécessairement) issu d'un œuf, pondu par un animal qui n'était pas encore tout à fait un poulet (ne répondant pas nécessairement pleinement aux critères d'un « poulet », à ce stade).

          L'œuf était donc en premier.

          En ce qui concerne la taille du tampon ASIO, le mécanisme est le suivant :
          1) Le pilote communique à l'hôte la taille de tampon qu'il préfère.
          2.) L'hôte appelle « CreateBuffers() », avec un argument de taille de tampon qui est soit égal à la valeur préférée du pilote, soit complètement différent.

          Rien n'empêche donc Studio One d'ignorer la taille de tampon préférée du pilote et de définir la sienne. Absolument rien !

          Mais en réalité, non. Studio One s'attend plutôt à ce que le pilote modifie également ses propres préférences lors du prochain appel à GetBufferSize() par l'hôte. Si le pilote persiste à renvoyer sa taille préférée (qui n'est qu'une suggestion), Studio One ignorera la modification de la taille du tampon dans sa boîte de dialogue des paramètres audio, sans aucune raison apparente.

          Voilà donc votre cercle vicieux de la poule et de l'œuf.

          Certes, on pourrait ajouter un mécanisme permettant au pilote de reprendre le contrôle de ses préférences dès que l'utilisateur modifie la taille du tampon ASIO dans le panneau de configuration ASIO. Cela complexifierait inutilement une solution qui ne fonctionne que dans 90 % des cas.

          La version de test contient ceci : https://asio4all.org/downloads/ASIO4ALL_2_20_test.exe

          – ou bien nous pourrions simplement indiquer à l'hôte qu'il doit se conformer à la taille de tampon définie par le pilote (en définissant max=min=preferred) et ainsi éviter toute forme d'ambiguïté.

          Répondre
      2. Avatar de KJ
        KJ

        Les pilotes ASIO standard permettent à l'application hôte de modifier la fréquence d'échantillonnage. Je ne porte aucun jugement sur la pertinence de cette pratique ; c'est une pratique courante. Je soulève simplement ce point pour alimenter la discussion, sans chercher à vous contredire. Même si je pense que vous avez raison, je voulais simplement évoquer cette question.

        Répondre
      3. Avatar de KJ
        KJ

        Vous pourriez même ajouter une option permettant aux utilisateurs de choisir si l'hôte peut modifier la fréquence d'échantillonnage ou non, au lieu de vous lancer dans ce débat sur la poule et l'œuf.

        Répondre
  4. L Avatar
    L

    Pour une raison inconnue, la version 2.19 [Final] ne fonctionne pas chez de nombreuses personnes : aucun son n'est produit. En revanche, la version 2.19_Test (dont le lien figurait dans votre message concernant la version 2.18) fonctionne correctement. https://asio4all.org/downloads/ASIO4ALL_2_19_Test.exe Cela fonctionne très bien. J'utilise Realtek Audio ; WASAPI et Steinberg intégré fonctionnent tous deux parfaitement.

    Répondre
    1. Avatar de Michael Tippach
      Michel Tippach

      Essayez de régler la taille du tampon ASIO à au moins 15 ms, à titre expérimental. Cela change-t-il quelque chose ?

      Répondre
      1. L Avatar
        L

        Oui, ça fonctionne pour moi avec cette configuration :

        Taille du tampon ASIO : 768 spls (16/21 ms)
        Mode basse consommation : désactivé
        Entrée : désactivée
        Sortie : casque uniquement
        Compensation de latence (entrée/sortie) : 16 échantillons
        Fréquence d'échantillonnage : 48 kHz
        DAW : Reaper 7.69 (avril 2026)
        Système d'exploitation : Windows 11 Famille 25H2 (avril 2026)
        Pilotes audio : Realtek 6.0.9915.1 (17 novembre 2025)

        Répondre
        1. administrateur Avatar
          admin

          Avez-vous pu choisir une taille de buffet ASIO inférieure à 10 ms sur les versions précédentes ?

          Répondre
          1. L Avatar
            L

            Uniquement avec les versions 2.19_Test et 2.16

        2. administrateur Avatar
          admin

          Nouvelle expérience : https://asio4all.org/downloads/ASIO4ALL_2_20_TRACE.exe
          Il s'agit d'une version de débogage qui générera un fichier « ASIO4ALL Debug Log.txt » sur votre bureau.

          Les passages les plus intéressants :

          [INFO] Vérification de la plage de taille du tampon…
          [INFO] Plage de taille de bloc (Spls) MIN =
          [INFO] Plage de taille de bloc (Spls) MAX =

          Pouvez-vous les trouver ?

          Répondre
          1. L Avatar
            L

            Oui. Voici vos résultats :

            [INFO] Vérification de la plage de taille du tampon…
            [INFO] Plage de taille de bloc (Spls) MIN = 256
            [INFO] Plage de taille de bloc (Spls) MAX = 96000

            Merci d'avance pour le temps que vous consacrerez à l'amélioration d'ASIO4ALL.

        3. Avatar de Michael Tippach
          Michel Tippach

          Cette version de débogage devrait donc fonctionner pour vous, même avec des tailles de tampon inférieures à 512 échantillons. N'est-ce pas ?

          Répondre
          1. L Avatar
            L

            J'ai essayé de tester avec la version de débogage ( https://asio4all.org/downloads/ASIO4ALL_2_20_TRACE.exe Mais ça ne fonctionne pas. La configuration ASIO normale (ASIO + Débogage + Paramètres hors ligne) fonctionne correctement, mais la version TRACE fait planter Reaper 7.69 presque immédiatement après son lancement, si rapidement que le fichier « ASIO4ALL Debug Log » (.txt) apparaît sur le bureau juste après le plantage.
            —Configuration de test : Reaper 7.69 avec piano VSL (VST3i) + iamreverb 1.4.3 (VST3) + Pro-Q4 (VST3) + Puis, pression accrue avec : 2e piste avec Kontakt 8.9 (tous les VST3/i mis à jour en avril 2026)
            Fréquence d'échantillonnage demandée : 48 kHz, aucune entrée, 1 sortie

            Comparaison des versions (même configuration de base pour toutes)
            2.16 Paramètres par défaut. 512 échantillons → Latence de 10/11 ms (12 ms avec compensation de 16 échantillons). Aucun artefact. En cas de charge VST plus importante, 640 échantillons sont nécessaires → 14/14 ms.
            2.17 Paramètres par défaut, mode basse consommation désactivé. 512 échantillons → 10/11 ms. Aucun artefact. En cas de charge plus importante, 576 échantillons sont nécessaires → 13/23 ms.
            2.18 Paramètres par défaut, mode basse consommation désactivé. 512 échantillons → 10/11 ms. Aucun artefact. En cas de charge plus importante, 576 échantillons sont nécessaires → 12/21 ms.
            2.19 Paramètres par défaut, mode basse consommation désactivé. Fonctionne uniquement à 768 échantillons → 16/21 ms. Aucun artefact. La mémoire tampon est déjà tellement importante que l'ajout de plugins VST supplémentaires ne me force pas à l'augmenter davantage ; Reaper ne bronche même pas.
            2.19_Test Le Gagnant
            Paramètres par défaut, mode basse consommation désactivé. Fonctionnement impeccable à 512 échantillons → 10/11 ms. Aucun artefact. Mieux encore : même avec une charge VST importante, la latence reste de 512 échantillons → 10/11 ms. Aucun ajustement de la mémoire tampon n'est nécessaire. C'est la seule version qui garantit une faible latence ET une faible consommation de ressources, même sous forte sollicitation.

          2. L Avatar
            L

            Deuxième réponse :
            Après des tests supplémentaires avec la version 2.16 (juin 2024), même si elle n'est plus vraiment d'actualité en 2026, voici les résultats obtenus avec les pilotes Realtek 6.0.9915.1 (novembre 2025) de Lenovo et Windows 11 Famille 25H2 (avril 2026) : ma configuration ne supporte pas les valeurs inférieures à 512 échantillons, et la plupart des valeurs supérieures génèrent des artefacts en cas de forte charge. Seuls les niveaux de 512 et 768 échantillons fonctionnent correctement. Toutes les valeurs intermédiaires provoquent des dysfonctionnements.

            Comme je l'ai dit précédemment, votre version 2.19_Test (la meilleure) :
            Paramètres par défaut, mode basse consommation désactivé. Fonctionnement impeccable à 512 échantillons → 10/11 ms. Aucun artefact. Mieux encore : même avec une charge VST importante, la latence reste de 512 échantillons → 10/11 ms. Aucun ajustement de la mémoire tampon n'est nécessaire. C'est la seule version qui garantit une faible latence ET une faible consommation de ressources, même sous forte sollicitation.

        4. administrateur Avatar
          admin

          Si nous parvenons à déterminer pourquoi la version de débogage fait planter Reaper, il y a de fortes chances que vous puissiez réduire la taille du tampon ASIO jusqu'à 64 échantillons à l'avenir.

          S'agit-il d'un système AMD et du pilote audio « Realtek (xyz) avec HAP » ?

          Répondre
          1. L Avatar
            L

            Oui, processeur : AMD Ryzen 5 5500U (UEFI : 19 mars 2025, version du firmware SMU : 55.93.0)
            Pilotes de chipset AMD : 8.02.18.557 (mars 2026)
            Système d'exploitation : Windows 11 Famille 25H2 (avril 2026)
            Matériel audio : Realtek : HDAUDIO\FUNC_01&VEN_10EC&DEV_0257&SUBSYS_17AA38BC&REV_1000
            Pilote audio : Realtek 6.0.9915.1 (17 novembre 2025) / hdxacplv.inf

          2. L Avatar
            L

            Mise à jour : j’ai réussi à faire fonctionner la version 2.20 avec Reaper 7.69. Voici la solution : désinstallez ASIO4ALL, lancez Reaper, sélectionnez WASAPI comme moteur audio, fermez Reaper, puis réinstallez et configurez ASIO4ALL 2.20. Ensuite, tout fonctionne correctement.
            Comparaison avec la version 2.19 (finale) : en 2.20, la taille minimale de mon tampon de travail est de 576 échantillons, ce qui entraîne une latence de 12/21 ms. C’est plus élevé que souhaité, mais l’avantage est l’absence d’artefacts.
            Bonus sans rapport avec le sujet : ASIO4ALL est désormais compatible avec Foobar2000 2.26 et AIMP 6 (ASIO + VST2/3). Testé avec des écouteurs intra-auriculaires et mesuré sur un B&K 5128 avec une égalisation cible en champ diffus (5128), le son d'AIMP est nettement supérieur à celui de Foobar. Certes, il y a une latence, mais ASIO4ALL, associé à un égaliseur paramétrique comme FabFilter Pro-Q 4 (4.12), change la donne si vous souhaitez profiter d'une playlist sans avoir à lancer un séquenceur audio numérique complet.

        5. administrateur Avatar
          admin

          Le bruit du crash reste étrange, cependant.

          Voici une version de test sans traces. Veuillez activer l'option « Débogage » lors de l'installation ! Cela devrait permettre de générer un fichier de vidage mémoire en cas de réapparition du problème.

          https://www.asio4all.org/downloads/ASIO4ALL_2_20_test.exe – Version de test sans journalisation.

          Il est toujours intéressant de constater que la réduction de la taille du tampon ASIO n'améliore pas nécessairement les performances. Avec un tampon ASIO inférieur ou égal à 512, obtient-on du son (malgré quelques coupures occasionnelles) ou aucun son du tout ?

          https://www.asio4all.org/downloads/ASIO4ALL_2_20_TRACE.exe – Version de traçage mise à jour.

          Définissez la taille du tampon ASIO à 320 échantillons par exemple et examinez la trace pour les lignes qui ressemblent à :
          [INFO] Configuration du tampon SPL pour <192 <=512 >512 (échantillons) MIN = 256 | MIN*2 = 256 | MAX = 480
          [INFO] Initialisation SPL | Taille du tampon de petits paquets = 1000 | broche = 2BC

          Des déconnexions occasionnelles indiquent que votre système souffre de problèmes d'adéquation en temps réel, généralement résolubles par des modifications de configuration. Par exemple, avez-vous désactivé la détection de présence ?

          Répondre
          1. L Avatar
            L

            J'ai envoyé un courriel à feedback@asio4all.com avec mon analyse de la situation et des solutions de contournement, et pièces jointes : CRA4D43.tmp (vidage mémoire en cas de plantage) et journal de débogage ASIO4ALL.

            Avec la version 2.20_Trace, la taille du tampon ASIO est définie sur 512 échantillons, sous la valeur que vous avez demandée dans le journal de débogage : « [INFO] Set SPL Buffer for <192 512 (samples) MIN = 256 | MIN*2 = 256 | MAX = 480 ».

            [INFO] Initialisation SPL | Taille du tampon de petits paquets = 800 | broche = 65C
            [INFO] Initialisation SPL | Taille du tampon de petits paquets = 800 | broche = 668
            [INFO] Initialisation SPL | Taille du tampon de petits paquets = 800 | broche = 694
            [INFO] Initialisation SPL | Taille du tampon de petits paquets = 800 | broche = 2F4
            ...
            Etc

            REMARQUE : Aucune coupure n'a été observée sur les versions 2.16 à 2.20. Seules les versions 2.19 Final (768 échantillons) et 2.20_Test/Trace (576 échantillons) entraînent une latence élevée sans artefacts. À 512 échantillons, aucun son n'est produit. De plus, la version 2.20 présente un comportement anormal de la mémoire, signe d'une fuite.

            Merci d'avance.

        6. administrateur Avatar
          admin

          J'ai vérifié moi-même : si vous désinstallez ASIO4ALL, Reaper sélectionnera simplement le pilote ASIO suivant dans la liste. Si ce dernier est défectueux, Reaper plantera, même sans qu'ASIO4ALL soit installé. Il semblerait que ce soit un problème lié à Reaper.

          J'ai mis à jour les versions de test (avec et sans journalisation). Veuillez utiliser les liens ci-dessus.

          Le problème de mémoire devrait être résolu. Le plantage aussi.

          Expérience intéressante : que se passe-t-il si vous réduisez la taille du tampon ASIO à 192 échantillons ? Et que se passe-t-il si vous descendez en dessous de 192 échantillons ?

          Répondre
          1. L Avatar
            L

            Bonne nouvelle ! Plus de plantage, et je peux désormais effectuer les mises à jour entre les versions sans problème (par exemple, de 2.20_Test à 2.20_Trace). À noter : j’ai configuré Steinberg Built-in 1.0.9 comme pilote de secours. La version précédente plantait avec cette configuration, contrairement à la version actuelle.

            Les résultats sont impressionnants : 512 échantillons = latence de 10/11 ms, sans artefacts. Nouveau seuil minimal pour un son clair : 192 échantillons = 4/11 ms, sans artefacts. En dessous de 192 échantillons, le pilote tente d’émettre un signal, mais ne parvient qu’à produire un léger craquement occasionnel avant de se couper complètement.

            Informations sur la compilation du suivi :

            [INFO] Vérification de la plage de taille du tampon…
            [INFO] Plage de taille de bloc (Spls) MIN = 256
            [INFO] Plage de taille de bloc (Spls) MAX = 96000
            ---
            [INFO] Configuration du tampon SPL pour <192 512 (échantillons) MIN = 256 | MIN*2 = 256 | MAX = 480
            [INFO] Initialisation SPL | Taille du tampon de petits paquets = f00 | broche = 570

            Merci.

        7. administrateur Avatar
          admin

          Place à un peu d'« ingénierie logicielle empirique » !
          J'ai mis à jour la version de test (sans journal) une fois de plus.

          En supposant que le pilote Realtek sur les systèmes AMD soit quelque peu « spécial », en ce sens qu'il ne prend pas en charge une taille de paquet de 256 échantillons, malgré le fait qu'il ait été annoncé comme tel.

          Il prend cependant en charge une taille de paquet de 480 échantillons, ce qui correspond exactement à 10 ms.
          10 ms, ce n'est pas exceptionnel ; essayons donc de réduire ce temps par paliers de 1 ms. On sait que 4 ms ne fonctionne pas, car c'était le comportement des versions précédentes.

          La version de test vous permettra d'essayer tous les incréments de 5 à 10 ms en configurant la taille du tampon ASIO comme ceci :

          <192 – 5 ms
          <256 – 6 ms
          <320 – 7 ms
          <384 – 8 ms
          <480 – 9 ms
          480 et plus : 10 ms

          Pouvez-vous trouver un réglage inférieur à 480 qui fonctionne encore ?

          Répondre
          1. L Avatar
            L

            | Taille du tampon (échantillons) | Latence (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 |

            En dessous de 192 échantillons, aucun signal audio n'est produit. Les indicateurs de volume du séquenceur continuent d'afficher une activité, mais aucun son n'atteint la sortie.

        8. administrateur Avatar
          admin

          Euh… je voulais juste vérifier que vous utilisez bien la version affichant « Development Preview 2604212037 » dans l’interface graphique et Reaper x64 ? Sinon, les valeurs de latence de sortie semblent un peu étranges.

          Si vous passez la souris sur le résultat, que dit l'infobulle : « Sondage » ou « SPL » ?

          Répondre
          1. L Avatar
            L

            Oui, j'exécute la version préliminaire de développement 2604212037 sur Reaper 7.69 x64.

            1. (SPL) Mode basse consommation.
            2. Synchronisation alternative du tampon (anciennement le commutateur « Autoriser le mode de tirage »).
            3. Toujours rééchantillonner à 44.1 kHz / 48 kHz.

            Les trois options étaient désactivées.

            Lorsque je survole ma sortie unique avec ma souris, rien n'apparaît concernant : SPL ou Polling.

            J'ai ensuite testé la synchronisation alternative des tampons ; résultats mesurés dans Reaper 7.69 (latence en ms) :

            | Taille du tampon (échantillons) | Après (ABS [Activé] + LC [0/0]) | Avant (sans ABS et avec 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 |
            Remarque : je n'ai pas pu atteindre exactement 9/9.0 ni 7/7.0.

            Voici les valeurs affichées par l'interface de Reaper. Concernant la qualité audio sur ma configuration actuelle : le son commence à être audible à partir de 288 échantillons (6.0/6.0 ms), mais avec de nombreux artefacts. Ce n'est qu'à 512 échantillons (10/10 ms) que la sortie est parfaitement nette.

            Résumé des résultats obtenus sur ma configuration matérielle, sans artefacts même sous forte charge :
            Utilisation de 512 échantillons seulement :
            Latence : 10/10 ms avec la synchronisation de tampon alternatif activée.
            Latence : 10/11 ms avec synchronisation de tampon alternatif activée plus compensation de latence (IN/OUT) à 16 échantillons.

            Il convient de noter qu'avec la synchronisation de tampon alternative désactivée et la compensation de latence (IN/OUT) réglée sur 16 échantillons, mon matériel produit un son propre (sans artefacts) sous charge élevée sur toute la plage, de 192 échantillons (4/11 ms) à 512 échantillons (10/11 ms).

        9. administrateur Avatar
          admin

          Oubliez un instant la « synchronisation alternative des tampons ». Cela risque de mettre l'appareil en mode d'interrogation, ce qui n'est pas très utile ici.

          J'ai placé une autre version de test ici : https://asio4all.org/downloads/ASIO4ALL_2_20_test.exe (aucun journal de traces)
          https://asio4all.org/downloads/ASIO4ALL_2_20_test_TRACE.exe (avec journal de suivi)

          L'horodatage dans la barre de titre de la fenêtre de l'interface graphique doit être : 202604221115

          Correction du rapport de la latence de sortie, qui ne devrait *pas* rester constant lorsque la taille du tampon ASIO varie considérablement.

          La relation entre la taille du tampon ASIO et la taille des paquets internes reste inchangée. Si vous obtenez du son avec un tampon ASIO de 256 octets, par exemple, veuillez effectuer une capture et rechercher les lignes ressemblant à :

          [INFO] Initialisation SPL | Taille du tampon de petits paquets = 600 | broche = 578
          [INFO] KSPROPERTY_RTAUDIO_BUFFER_WITH_NOTIFICATION | Taille non SPL = 15c0 | Broche = 578
          [INFO] GetRtProperty() 5 | pin = 578 | octets renvoyés = 16
          [INFO] Base = E9C0D00 | Taille = 600 | MemBarrier = 1

          « Size » sur la première ligne correspond à la taille demandée, et « size » sur la dernière ligne à la taille du tampon renvoyée. Sur votre système, « F00 » correspond à une taille de paquet de 10 ms. Plus la taille est petite, mieux c’est.

          Répondre
          1. L Avatar
            L

            Version testée : 2604221115 (2026/04/22 11:15)

            Configuration:
            – Mode basse consommation : désactivé
            – Compensation de latence (ENTRÉE/SORTIE) : 0 échantillon
            Fréquence d'échantillonnage demandée par REAPER 7.69 x64 : 48 kHz
            – Entrée : Aucune
            – Sortie : 1 (Sortie audio Realtek HD avec HAP)

            Résultats concernant la taille du tampon :

            Taille minimale du tampon sans artefacts audio : 192 échantillons = Latence : 4.0 ms en entrée / 14 ms en sortie
            Taille minimale du tampon avec artefacts audio : 64 échantillons = Latence : ~1.3 ms en entrée / 6.7 ms en sortie

            Lectures du journal de débogage :

            Sur 192 échantillons (sans artefacts) :

            [INFO] Initialisation SPL | Taille du tampon de petits paquets = f00 | broche = A40
            [INFO] KSPROPERTY_RTAUDIO_BUFFER_WITH_NOTIFICATION | Taille non SPL = 1000 | Broche = A40
            [INFO] GetRtProperty() 5 | broche = A40 | octets renvoyés = 16
            [INFO] Base = 910000 | Taille = 1000 | Barrière mémoire = 0

            À 64 échantillons (avec artefacts) :

            [INFO] Initialisation SPL | Taille du tampon de petits paquets = 900 | broche = 448
            [INFO] KSPROPERTY_RTAUDIO_BUFFER_WITH_NOTIFICATION | Taille non SPL = 600 | Broche = 448
            [INFO] GetRtProperty() 5 | broche = 448 | octets renvoyés = 16
            [INFO] Base = D480000 | Taille = 1000 | Barrière mémoire = 0

          2. L Avatar
            L

            Deuxième réponse :
            Je soupçonne qu'il puisse y avoir une valeur incorrectement rapportée dans la version 2604221115 (2026/04/22 11:15).
            À 512 échantillons, Reaper indique 10/10 ms (entrée/sortie). Cependant, les tailles de tampon immédiatement supérieures et inférieures renvoient des valeurs asymétriques :

            480 échantillons → 10/20 ms
            512 échantillons → 10/10 ms
            576 échantillons → 12/22 ms

            Je comprends qu'il y a des limitations matérielles en jeu, mais ma question est la suivante : la lecture de 10/10 ms à 512 échantillons dans Reaper 7.69 peut-elle être réellement correcte, étant donné que les deux tailles de tampon voisines signalent une latence de sortie nettement plus élevée ?

        10. administrateur Avatar
          admin

          Le rapport de latence de 10/10 avec une taille de tampon de 512 est correct, bien que peu intuitif.

          Si la taille du tampon ASIO correspond exactement à la taille des paquets du pilote, aucun tampon supplémentaire n'est nécessaire. Dans votre cas, la taille minimale des paquets (compatible avec ce pilote) est de 512 échantillons.

          S'il n'y a pas de correspondance de taille exacte, il faut ajouter la taille complète d'un paquet à la durée du tampon ASIO (en théorie, moins un échantillon). Ce n'est pas évident à comprendre, et c'est même différent pour l'entrée !

          J'ai créé une autre version de test que vous pourrez utiliser en attendant : https://asio4all.org/downloads/ASIO4ALL_2_20_AMD_HAP.exe

          Je possède même au moins deux systèmes basés sur une conception matérielle identique ou similaire, et ils présentent un comportement comparable. Cependant, le fait de vivre sur deux continents complique la logistique. Je n'aurai accès à ces systèmes que dans deux semaines ; je pourrai peut-être alors résoudre le problème de leur fonctionnement avec une taille de paquet de 256.

          Répondre
          1. L Avatar
            L

            Tout d'abord, merci pour cette version pour AMD avec HAP (Realtek). Si vous avez besoin de tests sur un système AMD, je serai ravi de contribuer aux tests bêta avant la sortie de la version 2.20. J'apprécie vraiment votre implication dans ce projet ASIO. Je consulterai régulièrement cette discussion pour voir si je peux vous être utile. À bientôt !

  5. Avatar de KJ
    KJ

    Merci pour votre excellent travail sur ASIO4ALL !
    Dans la version 2.19, vous avez corrigé :
    « Correction d'un problème d'agrégation lors du mélange de périphériques de sortie WaveCyclic et d'entrées interrogées WaveRT, entraînant une distorsion du signal d'entrée. »
    Mais la combinaison inverse présente toujours le même bug :
    Entrée : WaveCyclic (périphérique audio USB 1.1)
    Sortie : WaveRT interrogé (audio Realtek intégré)
    Symptômes:
    dérive du tampon audio au fil du temps
    Augmentation du délai de sortie
    Distorsion du signal de sortie, craquements, bruit statique
    Il s'agit du même problème de dérive/synchronisation d'horloge, mais en sortie au lieu d'en entrée.
    Est-ce là le problème que la compensation de dérive du tampon mentionnée précédemment était censée résoudre ?
    Pourriez-vous corriger ce problème de casse inversée dans une version ultérieure ?
    De nombreux utilisateurs disposant d'entrées USB 1.1 rencontrent ce problème depuis des années.
    Je vous remercie!

    Répondre
    1. Avatar de Michael Tippach
      Michel Tippach

      La correction de la dérive d'horloge n'est pas encore implémentée. L'affichage de la fréquence d'échantillonnage permet actuellement uniquement de déterminer si la dérive d'horloge constitue un problème potentiel pour certains appareils.

      Répondre

Laissez un commentaire

Votre adresse courriel n'apparaitra pas. Les champs obligatoires sont marqués *

Ce site utilise Akismet pour réduire les spams. Découvrez comment vos données de commentaire sont traitées.

Droits d'auteur © Michael Tippach

Mentions légales | Protection des renseignements personnels

Sécurité accrue. Efforts réduits. Succès durable. WordPress

ASIO est une marque déposée de Steinberg Media Technologies GmbH.  Toutes les autres marques commerciales sont la propriété de leurs propriétaires respectifs et sont utilisées uniquement à des fins d'identification des produits.

  • Taille de la mémoire tampon ASIO

    Taille de la mémoire tampon ASIO

    Utilisez le curseur pour ajuster la taille du tampon ASIO du périphérique actuellement sélectionné. Un tampon plus petit signifie une latence plus faible. Dès que vous entendez des craquements ou que le son se distord, vous devez augmenter la taille du tampon. La taille du tampon ASIO est directement liée à la latence audio. Il est donc conseillé d'opter pour une valeur relativement faible.

    plus

  • Charger les paramètres par défaut

    Charger les paramètres par défaut

    Appuyez sur ce bouton pour réinitialiser toutes les options de configuration à leurs valeurs par défaut initiales. À utiliser lorsque l'audio fonctionnait initialement et que vous vous êtes ensuite perdu dans le processus de configuration. De plus, si vous avez mis à jour votre ASIO4ALL vers une nouvelle version, cette option chargera les paramètres recommandés par la nouvelle version.

    plus

  • Passer en mode avancé

    Passer en mode avancé

    Permet de basculer le panneau de configuration en mode « avancé », où vous pouvez corriger les problèmes ou les dérégler complètement à votre guise. Le mode « avancé » est expliqué dans la section « Configuration avancée » de ce document.

    plus