Offizielle Homepage von ASIO4ALL

Universeller Windows ASIO-Treiber

Version 2.19

  • Keine neuen Funktionen, nur Fehlerbehebungen.
  • Diese Version unterstützt offiziell Windows 10 und Windows 11.
  • Funktioniert nachweislich auch mit Windows 7 und Windows 8, allerdings mit einigen geringfügigen visuellen Artefakten in der Benutzeroberfläche.
  • Fehler melden an feedback@asio4all.com!

Änderungen seit Version 2.18

  • Behebung eines Aggregationsproblems beim Mischen von WaveCyclic-Ausgabe und WaveRT-abgefragten Eingabegeräten, das zu Verzerrungen des Eingangssignals führt.
  • Behebt sporadische Host-Reset-Schleifen in Studio One (und möglicherweise auch in anderen Hosts).
  • Entfernen der PnP-ID aus dem Geräte-Tooltip-Fenster, wodurch die Benutzeroberfläche etwas übersichtlicher wird.
  • Die Erkennung des Verbindungs-/Trennungsstatus von Bluetooth-Geräten muss korrigiert werden. Dies hätte dazu geführt, dass einige verbundene Geräte verschwunden und einige getrennte Geräte angezeigt worden wären.
  • Behebt ein kleineres Ressourcenleck bei Host-Reset-Anfragen.
  • Einige kleinere Anpassungen an der WaveRT-Pufferverwaltung.

ASIO4ALL 2.19 herunterladen ⮱

Gesendet

in

,

by

Admin

Stichworte:

Kommentare

44 Antworten auf „Version 2.19“

  1. Miki-Avatar
    Miki

    Ich habe Probleme mit Audioaussetzern, Knackgeräuschen und instabiler Wiedergabe, wenn ich ASIO4ALL mit einem USB-Gitarreninterface verwende, das auf dem TI PCM2902 USB-CODEC basiert (in Windows als USB PnP-Soundgerät angezeigt).
    Mein System ist stabil und LatencyMon meldet keine größeren DPC-Latenzprobleme, aber die Probleme bestehen weiterhin speziell bei diesem Gerät.
    Aktuelles Setup:
    Windows-10 x64
    ASIO4ALL 2.19
    44.1 kHz

    Mehrere Puffergrößen ausprobiert (256 / 512 / 1024)
    Das Problem tritt in Guitar Rig und Verstärkersimulatoren auf.
    Der Geräteeingang funktioniert und ein Audiosignal wird erkannt, aber die Wiedergabe knackt oder setzt häufig aus.
    Könnten Sie bitte die Kompatibilität oder Stabilität von USB-Audiogeräten auf PCM2902-Basis untersuchen?
    Vielen Dank für Ihre Arbeit an ASIO4ALL.

    antworten
    1. Administrator-Avatar
      Admin

      Legacy WaveCylic steht als nächstes auf der To-do-Liste.
      In dieser Version wurden die häufigen Neustarts vorerst behoben:
      https://asio4all.org/downloads/test/ASIO4ALL_2_21_test.exe

      Es bedarf noch einiger Verbesserungen hinsichtlich der Roundtrip-Latenz, aber die Verbindungsabbrüche sollten nun behoben sein.

      antworten
      1. Miki-Avatar
        Miki

        Hallo,
        Vielen Dank für die Testversion und dafür, dass Sie sich mit dem Problem der Legacy WaveCyclic-Version befasst haben.
        Ich habe den neuen ASIO4ALL 2.21 Test-Build mit meinem TI PCM2902 USB CODEC (USB PnP Sound Device) Gitarreninterface getestet.

        Die kompletten Audioaussetzer scheinen nun behoben zu sein, was eine große Verbesserung darstellt.

        Nach etwa 3–5 Minuten Wiedergabezeit beginnt der Ton jedoch zunehmend zu knistern und zu verzerren. Interessanterweise ist der Ton sofort wieder klar, sobald ich im ASIO4ALL-Panel etwas anklicke oder die Systemsteuerung erneut öffne – und das für einige Minuten.

        Dieses Verhalten wiederholt sich regelmäßig.

        Meine Einrichtung:

        Windows-10 x64
        44.1 kHz
        Es wurden verschiedene Puffergrößen ausprobiert (256/512/1024).
        Guitar Rig / Fortin Nameless
        Eingang: TI PCM2902 USB-Codec
        Ausgang: Realtek-Lautsprecher

        LatencyMon meldet keine größeren DPC-Latenzprobleme.

        Es fühlt sich fast so an, als ob die Synchronisation des Audiostreams oder des Puffers mit der Zeit abdriftet, bis ASIO4ALL durch Interaktion mit dem Bedienfeld „aktualisiert“ wird.

        Ich hoffe, diese Informationen helfen beim Debuggen.

        Nochmals vielen Dank für Ihre Arbeit und Unterstützung.

        antworten
      2. Farzad Avatar
        farzad

        Die letzte Version, mit der meine Audient iD14-Soundkarte über den Kernel mit ASIO4ALL kommunizieren kann, ist Version 2.17 Beta 2 und älter. Neuere Updates können nicht mehr mit dem Kernel meiner Soundkarte kommunizieren. Beispielsweise betrug die Audio-Roundtrip-Zeit in Version 2.16 mit Sicherheitsumgehung 3 Millisekunden, bei neueren Updates hingegen 13 Millisekunden. Dies deutet auf ein Kommunikationsproblem mit der Soundkarte hin. Ich habe auch Version 2.21 getestet, das Problem besteht jedoch weiterhin.

        antworten
        1. Administrator-Avatar
          Admin

          Wie haben Sie die Round-Trip-Latenz gemessen?

          antworten
          1. Farzad Avatar
            farzad

            Ich habe die internen Berechnungen von Fender Studio verwendet, um dies zu messen.
            Selbst mit Gehör kann man feststellen, dass die Roundtrip-Latenz korrekt ist.

        2. Administrator-Avatar
          Admin

          Ihre DAW misst nichts. Sie fragt lediglich den ASIO-Treiber ab und zeigt die gemeldeten Werte an. So kann ich Ihnen einen ASIO-Treiber mit „Null“-Latenz erstellen – kein Problem –, obwohl das technisch unmöglich ist.

          Mehr zum Thema Roundtrip-Latenz: https://asio4all.org/latency-compensation/

          antworten
          1. Farzad Avatar
            farzad

            Ich habe ein optimiertes System, aber ein Problem mit meinem Soundkartentreiber, da dieser eine Sicherheitsvorkehrung enthält und ich dadurch keine niedrigere Latenz erreichen kann. Ich verwende asio4all, um diese Einschränkung zu umgehen 🙁

  2. Manny Avatar
    Manny

    Version 2.18/2.19 ist eine Verbesserung gegenüber Version 2.17, die meine Installation beschädigt hat. Danke für die Verbesserungen.

    antworten
  3. KJ-Avatar
    KJ

    Ich habe einen neuen Fehler in ASIO4ALL entdeckt. Bei Verwendung von „Studio One“ im WaveRT-Gerätemodus schlägt die Anforderung der Puffergröße fehl.
    Könnten Sie sich bitte dieses Problems annehmen? Vielen Dank.
    Viele Grüße

    antworten
    1. L Avatar
      L

      Die Verwendung der ASIO4ALL-Benutzeroberfläche (User Interface) war seit Version 2.17 ein Fehler.

      antworten
    2. Administrator-Avatar
      Admin

      Die Möglichkeit für den Host, die ASIO-Puffergröße zu überschreiben, ist ein Relikt aus längst vergangenen Zeiten. Dieser Ansatz wird immer ein Henne-Ei-Problem mit sich bringen.

      Die ASIO-Puffergröße kann *immer* im ASIO4ALL-Bedienfeld eingestellt werden.
      Wir werden die Option für den Host, die Einstellungen zu überschreiben, entfernen. Es gibt schlichtweg keinen praktischen Nutzen – und es ist verwirrend und fehleranfällig.

      antworten
      1. KJ-Avatar
        KJ

        Dieses Problem gab es vorher nicht; es ist erst jetzt aufgetreten. Ich möchte Sie lediglich darauf aufmerksam machen, um zu fragen, ob es behoben werden kann, nicht um mit Ihnen darüber zu streiten, was zuerst da war – die Henne oder das Ei. Man ging schon immer davon aus, dass die Henne vor dem Ei da war, und diese Schlussfolgerung war bereits etabliert. Wir sollten jetzt nicht über richtig oder falsch diskutieren; das Problem ist aufgetreten, und ich bitte Sie um Ihre Hilfe bei der Lösung.
        Auch wenn ich denke, dass du Recht hast, wirkt es so, als würdest du mit diesem Henne-Ei-Dilemma nur angeben wollen, verstehst du? Ich habe das nur angesprochen, weil ich dir vertraue. Sonst hätte ich gar nichts gesagt.

        antworten
        1. Administrator-Avatar
          Admin

          Bei allem Respekt, Sie haben es genau umgekehrt!

          Das erste Huhn stammte (notwendigerweise) aus einem Ei, das von einem noch nicht ganz fertigen Huhn gelegt wurde (das also noch nicht vollständig als „Huhn“ bezeichnet werden konnte).

          Demnach war das Ei zuerst da.

          Hinsichtlich der ASIO-Puffergröße ist der Mechanismus wie folgt:
          1.) Der Treiber meldet dem Host seine bevorzugte Puffergröße.
          2.) Der Host ruft „CreateBuffers()“ auf, wobei das Argument für die Puffergröße entweder dem vom Treiber bevorzugten Wert entspricht oder einen völlig anderen Wert hat.

          Nichts hindert Studio One also daran, die vom Treiber bevorzugte Puffergröße zu ignorieren und stattdessen eine eigene festzulegen. Absolut nichts!

          Das passiert aber nicht. Vielmehr erwartet das System, dass der Treiber seine eigenen Einstellungen ändert, sobald der Host das nächste Mal `GetBufferSize()` aufruft. Sollte der Treiber seine Meinung nicht ändern und weiterhin stur seine bevorzugte Größe (die lediglich ein Vorschlag ist) zurückgeben, ignoriert Studio One die Überschreibung der Puffergröße im eigenen Audioeinstellungsdialog – völlig grundlos.

          Hier haben Sie also Ihre Henne-Ei-Schleife.

          Natürlich könnten wir einen Mechanismus einbauen, der es dem Treiber ermöglicht, die Kontrolle über seine Einstellungen zurückzuerlangen, sobald der Benutzer die ASIO-Puffergröße in der ASIO-Systemsteuerung ändert. Das würde die Lösung unnötig verkomplizieren, da sie nur in 90 % der Fälle funktioniert.

          Die Testversion enthält Folgendes: https://asio4all.org/downloads/ASIO4ALL_2_20_test.exe

          – oder wir könnten dem Host einfach mitteilen, dass er sich an die vom Treiber definierte Puffergröße halten muss (durch die Einstellung max=min=preferred) und so jegliche Form von Mehrdeutigkeit vollständig vermeiden.

          antworten
      2. KJ-Avatar
        KJ

        Standardmäßige ASIO-Treiber ermöglichen es der Host-Anwendung, die Abtastrate zu ändern. Ich bewerte das nicht als richtig oder falsch; es ist einfach gängige Praxis. Ich bringe das nur zur Diskussion, nicht um mit Ihnen über Richtig oder Falsch zu streiten. Auch wenn ich Ihre Meinung teile, spreche ich das Thema einfach an.

        antworten
      3. KJ-Avatar
        KJ

        Man könnte sogar einen Schalter hinzufügen, mit dem die Benutzer auswählen können, ob der Host die Abtastrate ändern darf oder nicht, anstatt mit mir diese ganze Henne-Ei-Diskussion zu führen.

        antworten
  4. L Avatar
    L

    Aus irgendeinem Grund funktioniert Version 2.19 [Final] bei vielen Nutzern nicht; sie gibt überhaupt keinen Ton von sich. Version 2.19_Test (die in Ihrem Beitrag zu Version 2.18 verlinkt war) hingegen funktioniert. https://asio4all.org/downloads/ASIO4ALL_2_19_Test.exe Funktioniert einwandfrei. Ich verwende Realtek Audio; sowohl WASAPI als auch die integrierten Soundkarten von Steinberg funktionieren problemlos.

    antworten
    1. Michael Tippach Avatar
      Michael Tippach

      Versuchen Sie testweise, die ASIO-Puffergröße auf >= 15 ms einzustellen. Macht das einen Unterschied?

      antworten
      1. L Avatar
        L

        Ja, mit dieser Konfiguration funktioniert es bei mir:

        ASIO-Puffergröße: 768 Spls (16/21 ms)
        Energiesparmodus: Aus
        Eingabe: deaktiviert
        Ausgang: Nur Kopfhörer
        Latenzkompensation (Ein-/Ausgang): 16 Abtastungen
        Abtastrate: 48 kHz
        DAW: Reaper 7.69 (Apr 2026)
        Betriebssystem: Windows 11 Home 25H2 (April 2026)
        Audiotreiber: Realtek 6.0.9915.1 (17. November 2025)

        antworten
        1. Administrator-Avatar
          Admin

          Konnten Sie in früheren Versionen eine ASIO-Buffetgröße von weniger als 10 ms auswählen?

          antworten
          1. L Avatar
            L

            Nur mit 2.19_Test und 2.16

        2. Administrator-Avatar
          Admin

          Neues Experiment: https://asio4all.org/downloads/ASIO4ALL_2_20_TRACE.exe
          Dies ist eine Debug-Version, die eine Datei namens „ASIO4ALL Debug Log.txt“ auf Ihrem Desktop erzeugt.

          Die interessantesten Zeilen darin:

          [INFO] Überprüfe Puffergrößenbereich…
          [INFO] Blockgrößenbereich (Spls) MIN =
          [INFO] Blockgrößenbereich (Spls) MAX =

          Kannst du diese finden?

          antworten
          1. L Avatar
            L

            Ja. Hier sind Ihre Ergebnisse:

            [INFO] Überprüfe Puffergrößenbereich…
            [INFO] Blockgrößenbereich (Spls) MIN = 256
            [INFO] Blockgrößenbereich (Spls) MAX = 96000

            Vielen Dank im Voraus für Ihre Zeit, ASIO4ALL zu verbessern.

        3. Michael Tippach Avatar
          Michael Tippach

          Diese Debug-Version sollte also auch bei Ihnen funktionieren – auch bei Puffergrößen < 512 Samples. Stimmt das?

          antworten
          1. L Avatar
            L

            Ich habe versucht, mit dem Debug-Build zu testen ( https://asio4all.org/downloads/ASIO4ALL_2_20_TRACE.exe Das funktioniert aber nicht. Normales ASIO (ASIO + Debug + Offline-Einstellungen) läuft einwandfrei, die TRACE-Version hingegen lässt Reaper 7.69 fast unmittelbar nach dem Laden abstürzen, so schnell, dass die Datei „ASIO4ALL Debug Log“ (.txt) direkt nach dem Absturz auf dem Desktop landet.
            —Testaufbau: Reaper 7.69 mit VSL Piano (VST3i) + iamreverb 1.4.3 (VST3) + Pro-Q4 (VST3) + Dann mehr Druck mit: 2. Spur mit Kontakt 8.9 (alle VST3/i auf dem Stand April 2026)
            Angeforderte Abtastrate: 48 kHz, kein Eingang, 1 Ausgang

            Versionsvergleich (gleiche Basiskonfiguration auf allen Systemen)
            2.16 Standardeinstellungen. 512 Samples → 10/11 ms Latenz (12 ms mit 16-Sample-Kompensation). Keine Artefakte. Bei höherer VST-Last werden 640 Samples benötigt → 14/14 ms.
            2.17 Standardeinstellungen, Energiesparmodus deaktiviert. 512 Abtastwerte → 10/11 ms. Keine Artefakte. Unter höherer Last werden 576 Abtastwerte benötigt → 13/23 ms.
            2.18 Standardeinstellungen, Energiesparmodus deaktiviert. 512 Abtastwerte → 10/11 ms. Keine Artefakte. Unter höherer Last werden 576 Abtastwerte benötigt → 12/21 ms.
            2.19 Standardeinstellungen, Energiesparmodus deaktiviert. Funktioniert nur bei 768 Samples → 16/21 ms. Keine Artefakte. Der Puffer ist bereits so hoch, dass das Hinzufügen weiterer VSTs keine weitere Belastung verursacht; Reaper reagiert problemlos.
            2.19_Testen Sie den Gewinner
            Standardeinstellungen, Energiesparmodus deaktiviert. Läuft sauber mit 512 Samples → 10/11 ms. Keine Artefakte. Und jetzt kommt der Clou: Selbst unter hoher VST-Last bleibt die Latenz bei 512 Samples → 10/11 ms. Kein Buffer-Buffer nötig. Dies ist die einzige Version, die unter Volllast sowohl niedrige Latenz als auch geringen Ressourcenverbrauch gewährleistet.

          2. L Avatar
            L

            Zweite Antwort:
            Nach weiteren Tests mit Version 2.16 (Juni 2024), die zwar 2026 nicht mehr relevant sein dürfte, erzielte ich mit Lenovos Realtek-Treibern 6.0.9915.1 (November 2025) und Windows 11 Home 25H2 (April 2026) folgende Ergebnisse: Mein System kommt mit Werten unter 512 Samples nicht zurecht, und die meisten Werte darüber führen unter hoher Last zu Artefakten. Nur 512 und 768 Samples laufen fehlerfrei. Alles dazwischen führt zu Problemen.

            Wie ich bereits sagte, Ihre Version 2.19_Test (die beste):
            Standardeinstellungen, Energiesparmodus deaktiviert. Läuft sauber mit 512 Samples → 10/11 ms. Keine Artefakte. Und jetzt kommt der Clou: Selbst unter hoher VST-Last bleibt die Latenz bei 512 Samples → 10/11 ms. Kein Buffer-Buffer nötig. Dies ist die einzige Version, die unter Volllast sowohl niedrige Latenz als auch geringen Ressourcenverbrauch gewährleistet.

        4. Administrator-Avatar
          Admin

          Wenn wir herausfinden, warum der Debug-Build Reaper zum Absturz bringt, besteht eine gute Chance, dass Sie den ASIO-Puffer in Zukunft bis auf 64 Samples reduzieren können.

          Handelt es sich um ein AMD-System und den Audiotreiber „Realtek (xyz) mit HAP“?

          antworten
          1. L Avatar
            L

            Ja, CPU: AMD Ryzen 5 5500U (UEFI: 19. März 2025, SMU Firmware Rev. 55.93.0)
            AMD-Chipsatztreiber: 8.02.18.557 (März 2026)
            Betriebssystem: Windows 11 Home 25H2 (April 2026)
            Audio-Hardware: Realtek: HDAUDIO\FUNC_01&VEN_10EC&DEV_0257&SUBSYS_17AA38BC&REV_1000
            Audiotreiber: Realtek 6.0.9915.1 (17. November 2025) / hdxacplv.inf

          2. L Avatar
            L

            Update: Version 2.20 läuft jetzt mit Reaper 7.69. Der Trick: ASIO4ALL deinstallieren, Reaper starten, das Audio-Backend auf WASAPI umstellen, Reaper schließen und anschließend ASIO4ALL 2.20 neu installieren und konfigurieren. Danach funktioniert es einwandfrei.
            Nun zum Kompromiss gegenüber Version 2.19 (Final): In Version 2.20 beträgt meine minimale Puffergröße 576 Samples → 12/21 ms Latenz. Höher als gewünscht, aber immerhin keine Artefakte.
            Ein weiterer Pluspunkt: ASIO4ALL funktioniert jetzt einwandfrei mit Foobar2000 2.26 und AIMP 6 (ASIO + VST2/3). Mit In-Ear-Monitoren und einem B&K 5128 mit Diffused Field (5128) EQ-Ziel klingt AIMP deutlich besser als Foobar. Zwar gibt es Latenz, aber ASIO4ALL in Kombination mit einem parametrischen Equalizer wie FabFilter Pro-Q 4 (4.12) ist ein echter Gamechanger, wenn man eine Playlist genießen möchte, ohne gleich eine komplette DAW starten zu müssen.

        5. Administrator-Avatar
          Admin

          Das Krachen klingt aber immer noch seltsam.

          Hier ist eine Testversion ohne Spuren. Bitte aktivieren Sie während der Installation die Option „Debug“! Dadurch wird hoffentlich ein Absturzprotokoll erstellt, falls das Problem erneut auftritt.

          https://www.asio4all.org/downloads/ASIO4ALL_2_20_test.exe – Testversion ohne Protokoll.

          Es ist immer noch interessant, warum man keine bessere Leistung erzielen sollte, wenn man die ASIO-Puffergröße verringert. Erhält man bei einer ASIO-Puffergröße von maximal 512 Byte Ton – wenn auch mit gelegentlichen Aussetzern – oder gar keinen Ton?

          https://www.asio4all.org/downloads/ASIO4ALL_2_20_TRACE.exe – Aktualisierte Trace-Version.

          Stellen Sie die ASIO-Puffergröße beispielsweise auf 320 Samples ein und überprüfen Sie die Ablaufverfolgung auf Zeilen wie die folgenden:
          [INFO] SPL-Puffer für <192 <=512 >512 (Samples) setzen: MIN = 256 | MIN*2 = 256 | MAX = 480
          [INFO] SPL-Initialisierung | Kleine Paketpuffergröße = 1000 | Pin = 2BC

          Gelegentliche Verbindungsabbrüche deuten darauf hin, dass Ihr System erhebliche Probleme mit der Echtzeitfähigkeit aufweist, die sich in den meisten Fällen durch Konfigurationsänderungen beheben lassen. Haben Sie beispielsweise die Anwesenheitserkennung deaktiviert?

          antworten
          1. L Avatar
            L

            Ich habe eine E-Mail an feedback@asio4all.com mit meiner Analyse der Situation und möglichen Umgehungen sowie den Anhängen: CRA4D43.tmp (Absturzprotokoll) & ASIO4ALL Debug-Protokoll.

            Mit 2.20_Trace: Die ASIO-Puffergröße wurde auf 512 Samples eingestellt, entsprechend dem Wert, den Sie im Debug-Log angefordert haben: „[INFO] Set SPL Buffer for <192 512 (samples) MIN = 256 | MIN*2 = 256 | MAX = 480“.

            [INFO] SPL-Initialisierung | Kleine Paketpuffergröße = 800 | Pin = 65C
            [INFO] SPL-Initialisierung | Kleine Paketpuffergröße = 800 | Pin = 668
            [INFO] SPL-Initialisierung | Kleine Paketpuffergröße = 800 | Pin = 694
            [INFO] SPL-Initialisierung | Kleine Paketpuffergröße = 800 | Pin = 2F4
            ...
            Usw.

            HINWEIS: Bei keiner Version von 2.16 bis 2.20 traten Aussetzer auf. Lediglich die Versionen 2.19 Final (768 Samples) und 2.20_Test/Trace (576 Samples) führten zu erhöhter Latenz ohne Artefakte; bei 512 Samples erfolgte keine Audioausgabe. Version 2.20 zeigte zudem ein ungewöhnliches Speicherverhalten, das auf ein Speicherleck hindeutet.

            Vielen Dank im Voraus.

        6. Administrator-Avatar
          Admin

          Ich habe es selbst getestet: Wenn man ASIO4ALL deinstalliert, wählt Reaper einfach den nächsten ASIO-Treiber in der Liste. Ist dieser fehlerhaft, stürzt Reaper ab – und das, obwohl ASIO4ALL gar nicht installiert ist. Scheint ein Problem mit Reaper zu sein.

          Ich habe die Testversionen aktualisiert (sowohl mit als auch ohne Protokollierung). Bitte verwenden Sie die obigen Links.

          Das Speicherproblem sollte behoben sein. Auch der Absturz sollte behoben sein.

          Das interessante Experiment: Was passiert nun, wenn man die ASIO-Puffergröße auf 192 Samples reduziert? Und: Was passiert, wenn man unter 192 Samples geht?

          antworten
          1. L Avatar
            L

            Gute Neuigkeiten! Kein Absturz mehr, und ich kann jetzt problemlos zwischen den Builds aktualisieren (z. B. von 2.20_Test auf 2.20_Trace). Wichtig: Ich habe Steinberg Built-in 1.0.9 als Backup-Treiber konfiguriert. Die vorherige Version stürzte mit dieser Konfiguration ab, die aktuelle nicht.

            Die Ergebnisse sind beeindruckend: 512 Samples = 10/11 ms Latenz, keine Artefakte. Neuer Mindestwert für sauberes Audio: 192 Samples = 4/11 ms, keine Artefakte. Unterhalb von 192 Samples versucht der Treiber, ein Signal auszugeben, erzeugt aber nur gelegentlich ein einzelnes Knacken, bevor er vollständig verstummt.

            Trace-Build-Informationen:

            [INFO] Überprüfe Puffergrößenbereich…
            [INFO] Blockgrößenbereich (Spls) MIN = 256
            [INFO] Blockgrößenbereich (Spls) MAX = 96000
            ---
            [INFO] SPL-Puffer für <192 512 (Samples) setzen: MIN = 256 | MIN*2 = 256 | MAX = 480
            [INFO] SPL-Initialisierung | Kleine Paketpuffergröße = f00 | Pin = 570

            Danke.

        7. Administrator-Avatar
          Admin

          Zeit für ein bisschen „Empirisches Software-Engineering“!
          Ich habe den Test-Build (ohne Protokoll) noch einmal aktualisiert.

          Angenommen, der Realtek-Treiber auf AMD-Systemen ist in gewisser Weise „speziell“, da er eine Paketgröße von 256 Samples nicht unterstützt, obwohl er damit geworben hatte.

          Es unterstützt jedoch eine Paketgröße von 480 Samples, was genau 10 ms entspricht.
          10 ms sind allerdings nicht gerade berauschend – versuchen wir also, die Latenz in 1-ms-Schritten zu verringern. Wir wissen, dass 4 ms nicht funktionieren, da dies in älteren Versionen so war.

          Mit der Testversion können Sie alle Schritte von 5 bis 10 ms ausprobieren, indem Sie die ASIO-Puffergröße wie folgt festlegen:

          <192 – 5 ms
          <256 – 6 ms
          <320 – 7 ms
          <384 – 8 ms
          <480 – 9 ms
          480 und mehr: 10 ms

          Gibt es eine Einstellung unter 480, die noch funktioniert?

          antworten
          1. L Avatar
            L

            | Puffergröße (Samples) | Latenz (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 |

            Unterhalb von 192 Samples erfolgt keine Audioausgabe. Die Lautstärkeanzeigen der DAW zeigen zwar weiterhin Signalaktivität an, aber es erreicht kein Signal den Ausgang.

        8. Administrator-Avatar
          Admin

          Ähm… nur um sicherzugehen, dass Sie die Version verwenden, die in der GUI „Development Preview 2604212037“ anzeigt, und Reaper x64? Andernfalls sehen die Latenzwerte etwas merkwürdig aus.

          Wenn Sie mit der Maus über die Ausgabe fahren, was zeigt der Tooltip an: „Polling“ oder „SPL“?

          antworten
          1. L Avatar
            L

            Ja, ich verwende die Entwicklungsvorschau 2604212037 auf Reaper 7.69 x64.

            1. (SPL) Energiesparmodus.
            2. Alternative Puffersynchronisation (vorher der Schalter „Pull-Modus zulassen“).
            3. Immer 44.1 kHz / 48 kHz neu abtasten.

            Alle drei Optionen waren AUS.

            Wenn ich mit der Maus über meinen einzelnen Ausgang fahre, wird nichts angezeigt, was mit SPL oder Polling zu tun hat.

            Anschließend testete ich die alternative Puffersynchronisation; Ergebnisse gemessen in Reaper 7.69 (Latenz in ms):

            | Puffergröße (Samples) | Nach (ABS [Ein] + LC [0/0]) | Vorher (ohne ABS und mit 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 |
            Anmerkung: Ich konnte weder genau 9/9.0 noch 7/7.0 erreichen.

            Das sind die Werte, die die Reaper-Oberfläche meldet. Was die Audioqualität auf meiner aktuellen Hardware angeht: Ab 288 Samples (6.0/6.0 ms) ist Ton zu hören, allerdings mit starken Artefakten. Erst ab 512 Samples (10/10 ms) ist die Ausgabe völlig fehlerfrei.

            Zusammenfassung der Ergebnisse auf meiner Hardware, frei von Artefakten unter hoher Last:
            Verwendung von nur 512 Proben:
            Latenz: 10/10 ms bei aktivierter alternativer Puffersynchronisation.
            Latenz: 10/11 ms bei aktivierter alternativer Puffersynchronisation plus Latenzkompensation (IN/OUT) bei 16 Abtastwerten.

            Es ist erwähnenswert, dass meine Hardware bei deaktivierter alternativer Puffersynchronisation und einer Latenzkompensation (IN/OUT) von 16 Samples unter hoher Last über den gesamten Bereich von 192 Samples (4/11 ms) bis 512 Samples (10/11 ms) ein sauberes Audiosignal (ohne Artefakte) erzeugt.

        9. Administrator-Avatar
          Admin

          Vergessen Sie für einen Moment die „Alternative Puffersynchronisierung“. Dadurch wird das Gerät wahrscheinlich in den Abfragemodus versetzt, was hier nicht sehr hilfreich ist.

          Ich habe hier einen weiteren Test-Build bereitgestellt: https://asio4all.org/downloads/ASIO4ALL_2_20_test.exe (kein Protokoll)
          https://asio4all.org/downloads/ASIO4ALL_2_20_test_TRACE.exe (mit Protokolldatei)

          Der Zeitstempel in der Titelleiste des GUI-Fensters sollte lauten: 202604221115

          Die Meldung der Ausgabeverzögerung wurde korrigiert; diese sollte *nicht* konstant bleiben, wenn sich die ASIO-Puffergröße über einen weiten Bereich ändert.

          Verhältnis von ASIO-Puffergröße zu interner Paketgröße wie zuvor. Falls Sie bei z. B. einem ASIO-Puffer von 256 Byte Ton hören, erstellen Sie bitte einen Trace und suchen Sie nach Zeilen wie:

          [INFO] SPL-Initialisierung | Kleine Paketpuffergröße = 600 | Pin = 578
          [INFO] KSPROPERTY_RTAUDIO_BUFFER_WITH_NOTIFICATION | Non SPL size = 15c0 | pin = 578
          [INFO] GetRtProperty() 5 | pin = 578 | zurückgegebene Bytes = 16
          [INFO] Basis = E9C0D00 | Größe = 600 | Speicherbarriere = 1

          „Größe“ in der ersten Zeile ist die angeforderte Größe, „Größe“ in der letzten Zeile die zurückgegebene Puffergröße. In Ihrem System entspricht „F00“ einer Paketgröße von 10 ms. Je kleiner, desto besser.

          antworten
          1. L Avatar
            L

            Getesteter Build: 2604221115 (2026/04/22 11:15)

            Konfiguration:
            – Energiesparmodus: Deaktiviert
            – Latenzkompensation (EIN/AUS): 0 Abtastungen
            – Von REAPER 7.69 x64 angeforderte Abtastrate: 48 kHz
            – Eingabe: Keine
            – Ausgang: 1 (Realtek HD-Audioausgang mit HAP)

            Ergebnisse der Puffergrößenberechnung:

            Minimale Puffergröße ohne Audioartefakte: 192 Samples = Latenz: 4.0 ms Eingang / 14 ms Ausgang
            Minimale Puffergröße bei Audioartefakten: 64 Samples = Latenz: ~1.3 ms Eingang / 6.7 ms Ausgang

            Debug-Log-Einträge:

            Bei 192 Proben (artefaktfrei):

            [INFO] SPL-Initialisierung | Kleine Paketpuffergröße = f00 | Pin = A40
            [INFO] KSPROPERTY_RTAUDIO_BUFFER_WITH_NOTIFICATION | Non SPL size = 1000 | pin = A40
            [INFO] GetRtProperty() 5 | pin = A40 | Anzahl zurückgegebener Bytes = 16
            [INFO] Basis = 910000 | Größe = 1000 | Speicherbarriere = 0

            Bei 64 Proben (mit Artefakten):

            [INFO] SPL-Initialisierung | Kleine Paketpuffergröße = 900 | Pin = 448
            [INFO] KSPROPERTY_RTAUDIO_BUFFER_WITH_NOTIFICATION | Non SPL size = 600 | pin = 448
            [INFO] GetRtProperty() 5 | pin = 448 | zurückgegebene Bytes = 16
            [INFO] Basis = D480000 | Größe = 1000 | Speicherbarriere = 0

          2. L Avatar
            L

            Zweite Antwort:
            Ich vermute, dass in Build 2604221115 (2026/04/22 11:15) ein falsch gemeldeter Wert vorliegt.
            Bei 512 Abtastwerten meldet Reaper 10/10 ms (Ein-/Ausgabe). Die unmittelbar darüber und darunter liegenden Puffergrößen liefern jedoch asymmetrische Werte:

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

            Mir ist bewusst, dass es Hardwarebeschränkungen gibt, aber meine Frage ist: Kann die Messung von 10/10 ms bei 512 Abtastwerten in Reaper 7.69 tatsächlich korrekt sein, wenn man bedenkt, dass beide benachbarten Puffergrößen eine deutlich höhere Ausgabelatenz melden?

        10. Administrator-Avatar
          Admin

          Die Angabe einer Latenz von 10/10 bei einer Puffergröße von 512 ist korrekt, wenn auch nicht sehr intuitiv.

          Wenn die ASIO-Puffergröße exakt der Treiberpaketgröße entspricht, ist keine zusätzliche Pufferung erforderlich. In Ihrem Fall beträgt die minimale Paketgröße (die mit diesem Treiber funktioniert) 512 Samples.

          Wenn keine exakte Größenübereinstimmung besteht, müssen wir die volle Paketgröße zur ASIO-Pufferdauer addieren (theoretisch minus 1 Sample). Das ist nicht leicht zu verstehen – und für Eingabedaten gilt das sogar noch anders!

          Ich habe für Sie vorübergehend eine weitere Testversion erstellt: https://asio4all.org/downloads/ASIO4ALL_2_20_AMD_HAP.exe

          Ich besitze sogar mindestens zwei Systeme mit identischer oder ähnlicher Hardwarearchitektur, und diese zeigen ein ähnliches Verhalten. Da ich auf zwei Kontinenten lebe, gestaltet sich die Sache jedoch etwas schwieriger. Ich habe erst in zwei Wochen wieder Zugriff auf diese Systeme – vielleicht kann ich das Problem mit der Paketgröße von 256 Bytes dann lösen.

          antworten
          1. L Avatar
            L

            Zunächst einmal vielen Dank für diesen Build für AMD mit HAP (Realtek). Falls Sie etwas mit einem AMD-System testen möchten, helfe ich gerne beim Betatest vor der Veröffentlichung von Version 2.20. Ich weiß Ihr Engagement für dieses ASIO-Projekt sehr zu schätzen. Ich werde diesen Beitrag immer mal wieder besuchen, um zu sehen, ob ich noch irgendwie helfen kann. Bis später.

  5. KJ-Avatar
    KJ

    Vielen Dank für Ihre großartige Arbeit an ASIO4ALL!
    In Version 2.19 wurde Folgendes behoben:
    „Behebung eines Aggregationsproblems beim Mischen von WaveCyclic-Ausgabe und WaveRT-abgefragten Eingabegeräten, das zu Verzerrungen des Eingangssignals führt.“
    Aber auch die umgekehrte Kombination weist denselben Fehler auf:
    Eingang: WaveCyclic (USB 1.1 Audiogerät)
    Ausgabe: WaveRT-Abfrage (Onboard-Realtek-Audio)
    Symptome:
    Audiopufferdrift im Laufe der Zeit
    Erhöhung der Ausgabeverzögerung
    Ausgangssignalverzerrung, Knistern, statisches Rauschen
    Es handelt sich um dasselbe Taktdrift-/Synchronisationsproblem, nur dass es sich um den Ausgang anstatt um den Eingang handelt.
    Ist dies das Problem, das durch die zuvor erwähnte Pufferdriftkompensation behoben werden sollte?
    Könnten Sie diesen umgekehrten Fall bitte in einer zukünftigen Version beheben?
    Viele Benutzer mit USB 1.1-Eingängen haben dieses Problem schon seit Jahren.
    Vielen Dank!

    antworten
    1. Michael Tippach Avatar
      Michael Tippach

      Die Korrektur von Taktdrift ist noch nicht implementiert. Die Anzeige der Abtastrate dient derzeit lediglich dazu, festzustellen, ob Taktdrift bei einzelnen Geräten ein Problem darstellen könnte.

      antworten

Schreiben Sie bitte einen Kommentar.

E-Mail-Adresse wird nicht veröffentlicht. Pflichtfelder sind MIT * gekennzeichnet. *

Diese Seite verwendet Akismet, um Spam zu reduzieren. Erfahren Sie, wie Ihre Kommentardaten verarbeitet werden.

Copyright © Michael Tippach

Impressum | Datenschutz

Erhöhte Sicherheit. Geringerer Aufwand. Nachhaltiger Erfolg. WordPress

ASIO ist ein Warenzeichen von Steinberg Media Technologies GmbH.  Alle anderen Marken sind Eigentum der jeweiligen Inhaber und werden nur zu Zwecken der Produktidentifikation verwendet.

  • Einführung

    Einführung

    Willkommen bei ASIO4ALL! Dieses Handbuch hilft Ihnen, Ihre ASIO4ALL-Installation optimal zu nutzen, insbesondere die neuen, erweiterten Funktionen dieser Version. Um mit ASIO4ALL die bestmöglichen Ergebnisse zu erzielen, empfiehlt sich eine entsprechende Konfiguration Ihres Computers. Für Updates, Hilfe und weitere Informationen,

    Mehr

  • Erste Schritte

    Erste Schritte

    Einrichtung Ihrer Audio-Software Um ASIO4ALL nutzen zu können, müssen Sie Ihre Audio-Software entsprechend konfigurieren. Die Vorgehensweise hängt von Ihrer jeweiligen Software ab. Im Allgemeinen rufen Sie das Audio-Konfigurationsmenü auf und wählen ASIO -> ASIO4ALL v2. Anschließend sollte eine Schaltfläche zum Starten des Programms vorhanden sein.

    Mehr

  • WDM-Geräteliste

    WDM-Geräteliste

    Dies ist die Liste der in Ihrem System gefundenen Audiogeräte. Markieren Sie das Gerät, an dem Sie Änderungen vornehmen möchten. Hinweis: Alle Parameteränderungen gelten immer nur für das aktuell markierte Gerät! Aktivieren Sie das gewünschte Gerät, indem Sie auf die Schaltfläche neben dem Gerätenamen klicken! Im obigen Bild ist das

    Mehr