Hohe Latenz bei Audioausgabe

[coxon]

Ich wiederhole mich gern: es liegt an deiner Grafikkarte. In deinem LatencyMon Log steht es eindeutig drin, dass der nvidiatreiber die hohen DCP Latenzen erzeugt. Dabei ist es egal ob ASIO oder anderes Ausgabemodul. Mit diesem Problem hatte ich bei meiner 1050Ti auch massiv zu kämpfen. Erst ein alter Treiber hat Besserung gebracht. Das Problem besteht also auf Hardwareebene und wirkt sich dadurch auch auf die Audioausgabe aus.

Offen gestanden, hab ich hier wohl etwas falsch angesetzt und kein Audiomodul, weder ASIO noch WASAPI wird Besserung bringen wenn die DCP Latenzen (durch den NV Treiber hervorgerufen) nicht beseitigt werden.

Mein Rat: schaff dir ne AMD Graka an. Dein aktuelles Ryzen System kommt wohl überhaupt nicht mir der Keppler-Karte zurecht. Auf Treiberversion(en) runterstufen, bei der du die Probleme nicht hattest wäre mein nächster Ansatz.

Dann möchte ich noch mal drauf hinweisen, dass die hohen Latenzen in deinem Spiel wohl ein zusammengerechneter Wert der gesamten Ein- und Ausgabekette mit Bild und Ton sind und definitiv nicht für die Zeit stehen die dein Audio zur Ausgabe braucht. Sieht man sehr gut daran, dass Cubase mit 15ms Latenz läuft. Falls doch, liegt es an der Graka, dem Treiber oder einer Inkompatibilität der Teile mit deinem System. Kann mir gut vorstellen, dass die Creative der Nvidia Karte Probleme macht.

Kommt halt davon wenn man 8-10 Jahre alte Technik in ein aktuelles PC System baut.
Kann klappen, muss aber nicht.

 

[xexex]

Und wieso sollte ich nicht erstaunt sein.

"Und nu", hast du eine Direct Sound Emulation auf Basis von ASIO

Verstehe mich bitte nicht falsch an dieser Stelle, ich finde es toll wieviel Mühe du dir damit gemacht hast und wie du alles verglichen hast. Nur kann im Gegensatz zu der Behauptung von coxon eine andere API, die man an das Spiel anfügt, nicht die Latenzen reduzieren, die vom Spiel selbst verursacht werden. Nichts anderes habe ich bis dahin auch geschrieben.

WASAPI ist unter Windows 10 sehr gut optimiert worden und hätten die Entwickler da entsprechend Wert drauf gelegt, ließen sich damit sehr niedrige Latenzen erreichen. Das wurde aber versäumt oder wie wir mittlerweile wissen, sogar absichtlich anders ausgelegt.

Meine Intention war an dieser Stelle deshalb, die Latenzen vom System zu reduzieren. Wenn der Buffer natürlich absichtlich festgelegt wurde, sind weitere Maßnahmen sowieso für die Katz.

Wieso sollten die Werte auch großartig voneinander abweichen?

Ganz einfach! Weil es zwischen den verschiedenen Stromsparmodis erhebliche Unterschiede gibt, was die Latenz anbetrifft.

Zwar hat Intel hier durch Speed Shift in den letzten CPU Generationen einiges optimiert, trotzdem sieht man bei mir einen großen Sprung zwischen "Ausbalanciert" und "Höchstleistung".

Bei dir sahen die Werte in beiden Fällen jedoch aus, wie bei mir mit dem Stromsparprofil.

 

[coxon]

@xexex mag ja sein, dass die Energiesparpläne bei dir einen sichtbaren Unterschied anzeigen, das tun sie bei mir allerdings nicht, müssen sie auch nicht zwangsweise bei ihm.

ASIO ist defakto als Audio API einfach besser als WASAPI, aber bleib du ruhig bei deiner Meinung. Wir sprechen uns dann wieder, wenn du ein Pro-Audio System konfigurierst und es selbst feststellst. Mag sein, dass WASAPI mit dem ein oder anderen Programm sehr gut funktioniert, aber das gilt einfach nicht für die Mehrheit der Anwendungen!

Falls du es überlesen hast, ja, ich hab einen falschen Ansatz mit ASIO verfolgt. Mittlerweile bin ich mir aber sehr sicher, dass die Konstellation von urlalten Creative + Nvidia Karten mit dem neuen System die Probleme verursacht.

 

[xexex]

ASIO ist defakto als Audio API einfach besser als WASAPI, aber bleib du ruhig bei deiner Meinung.

Ich habe es dir an dieser Stelle schon ausdrücklich erklärt, das ASIO ihre Stärken nur dann ausspielen kann, wenn es direkt von der Software unterstützt wird. Das ist bei professionellerer Audio Software durchaus sehr häufig der Fall, hier nimmt man auch in Kauf, das ASIO eine proprietäres API der Firma Steinberg ist.

Bei Spielen, "einfachen" Anwendungen oder freier Software ist das hingegen meist nicht der Fall und unter Windows wirst du bei Software wie Teamspeak oder Discord eben WASAPI als Schnittstelle der Wahl vorfinden, weil es die Windows Sound API ist und sich mit ihr mittlerweile wunderbar niedrige Latenzen erreichen lassen.

Falls du es überlesen hast, ja, ich hab einen falschen Ansatz mit ASIO verfolgt.

Ich habe es nicht überlesen, ich habe dich mehrfach drauf aufmerksam gemacht, das du mit einer zwischengeschalteten API nicht die Latenzprobleme eines Spiels reduzieren kannst, wenn sie im Spiel selbst entstehen. WASAPI war hier an keiner Stelle der Verursacher, nur kann es auch nicht die Daten schneller verarbeiten, als sie vom Spiel geliefert werden.

"Und nu", hast du eine Direct Sound Emulation auf Basis von ASIO, das Spiel "spricht" weiterhin nur Direct Sound. Das gleiche hast du wenn du unter Windows 10 Direct Sound verwendest, dann wird es durch WASAPI emuliert und wie bei jeder Emulation kommen vor allem Nüsse bei heraus.

Auch wenn du es nicht geglaubt hast, es sind Nüsse dabei herausgekommen.

ASIO ist defakto als Audio API einfach besser als WASAPI

Es gibt an dieser Stelle nicht ein "einfach besser", weil sich sowohl mit ASIO als auch mit WDM Latenzen unter 10ms erreichen lassen. Besser ist an dieser Stelle das, was von der Applikation besser unterstützt wird. Deshalb wirst du auch bei dem von dir genannten "professionellen Audioequipment", die Unterstützung beider Schnittstellen vorfinden.

Nimm dir mal so ein Universal Audio Teil, da wird es auch einfach und simpel erklärt.

Windows WDM system audio is typically used for audio I/O in media players, web browsers, and similar programs, while ASIO is typically used for audio I/O in DAW programs. WDM and ASIO are different subsystems that are configured separately.
https://help.uaudio.com/hc/en-us/ar...ows-WDM-System-Audio-with-Apollo-Thunderbolt-

Oder bei Presonus

Studio One supports most audio devices, including those that run on ASIO or WASAPI (Windows) or Core Audio (macOS) drivers.

When using a WASAPI audio device in Windows, note that WASAPI offers Exclusive and Shared modes of operation. Shared mode is the default setting. In Exclusive mode lower latency can be achieved, but other applications (such as Windows Media Player) cannot use the audio device at the same time. On your Windows computer, navigate to Windows Control Panel/Hardware and Sound/Sound to configure the options for your WASAPI device.
https://s1manual.presonus.com/Content/Setup_Topics/Set_Up_Your_Audio_Device.htm

Ich spreche ASIO nicht den Nutzen ab, es ist und bleibt aber etwas proprietäres was man nutzt, weil man es in diesem Segment "schon immer" genutzt hat. Es ist und bleibt aber unter allen Systemen, eine zusätzliche API zu den systemeigenen ALSA/Core Audio/WDM und die kann vom Treiber als auch von der Software unterschiedlich gut oder schlecht implementiert sein.

 

[PHuV]

Ich habe es dir an dieser Stelle schon ausdrücklich erklärt, das ASIO ihre Stärken nur dann ausspielen kann, wenn es direkt von der Software unterstützt wird. Das ist bei professionellerer Audio Software durchaus sehr häufig der Fall, hier nimmt man auch in Kauf, das ASIO eine proprietäres API der Firma Steinberg ist.

Nochmals, wenn es alle anderen Hersteller auch benutzen, was ist dann daran noch "proprietär"? Du verwendest das Wort hier schlichtweg falsch! Klar kommt ASIO von Steinberg, genauso wie VST. Da es aber heute ein herstellerunabhängiges Format geworden ist, was von allen, wirklich allen verwendet wird, ist das eben nicht mehr proprietär, kannst ja gerne noch genauer die Definition nachschlagen. Du hättest recht, wenn es nur ausschließlich von Steinberg-Produkten verwenden werden könnte.

Ich spreche ASIO nicht den Nutzen ab, es ist und bleibt aber etwas proprietäres was man nutzt, weil man es in diesem Segment "schon immer" genutzt hat. Es ist und bleibt aber unter allen Systemen, eine zusätzliche API zu den systemeigenen ALSA/Core Audio/WDM und die kann vom Treiber als auch von der Software unterschiedlich gut oder schlecht implementiert sein.

MME, WDM, DirectSound und Co. wurden immer schon von den meisten Audioprogrammen und DAWs unterstützt, das war schon seit Windows 95 so. Nur war es eben immer schlecht, sobald man darauf umgestellt hat. Die Latenzen waren hoch, multi war es auch nie, usw. Daher, wo ist da nun die Kunst? Jetzt gibts mit WASAPI und DSD eine bessere Unterstützung, mehr aber auch nicht.

Ergänzung (28. Mai 2021)

Falls du es überlesen hast, ja, ich hab einen falschen Ansatz mit ASIO verfolgt. Mittlerweile bin ich mir aber sehr sicher, dass die Konstellation von urlalten Creative + Nvidia Karten mit dem neuen System die Probleme verursacht.

Mein Rat: schaff dir ne AMD Graka an. Dein aktuelles Ryzen System kommt wohl überhaupt nicht mir der Keppler-Karte zurecht. Auf Treiberversion(en) runterstufen, bei der du die Probleme nicht hattest wäre mein nächster Ansatz.

Ich habe hier für meine DAW mit einem i9-10920X auch immer noch eine GTX 960 drin, ohne daß Dir mir irgendwelche Probleme macht.
Daher würde ich eher die Creative raushauen, als eine aktuell überteuerte AMD GPU kaufen.

Kommt halt davon wenn man 8-10 Jahre alte Technik in ein aktuelles PC System baut.
Kann klappen, muss aber nicht.

Daher ja auch meine Frage @Gorasuhl, warum nicht auf die SB verzichten?

Da mir das keine Ruhe lies, habe ich LatencyMon bei mir mal auf einigen Systemen (Spiele, Server, Anwendung) das mal laufen lassen. Alles Intel-Systeme, alles Onboardsounds, nirgends habe ich so ein Latenzproblem wie Du. Und ich kann mir jetzt ehrlich nicht vorstellen, daß es bei AMD plötzlich so ein Problem sein soll. Somit würde ich mal vorschlagen, sichere mal Dein System komplett, mach die SB raus, installiere neu, nur die grundlegendsten Treiber drauf, und schaue dann mal, wie die Latenz ist. Wenn Du noch einen freien Datenträger hast, kannst Du das natürlich auch ohne Sicherung so mal durchspielen. Dann einfach alle bisherigen Datenträger abstecken, und nur ein Datenträger mit dem neuen Windows draufmachen.

 

[xexex]

Nochmals, wenn es alle anderen Hersteller auch benutzen, was ist dann daran noch "proprietär"? Du verwendest das Wort hier schlichtweg falsch!

Ich verwende es falsch?
https://de.wikipedia.org/wiki/Proprietär

Die Software ist von Steinberg und wird nur von Steinberg weiterentwickelt. Es ist genauso wenig ein "Standard" wie CUDA. Die breite Verwendung dieser API macht es nicht weniger proprietär und die Tatsache dass es "Closed Source" ist, macht den Einsatz dieser API bei diversen Projekten schwer bis unmöglich, weshalb man nun auch JACK als Alternative entwickelt hat.

The reason for Audacity's lack of ASIO support is licensing not technical. Steinberg do not alow the ASIO SDK to be redistributed (as required by open source projects) and anyway, In adition, Audacity is GPL licensed and so is incompatible with the SDK licence.

Ergänzung (28. Mai 2021)

Und ich kann mir jetzt ehrlich nicht vorstellen, daß es bei AMD plötzlich so ein Problem sein soll.

Zumindest du und ich haben beide die gleiche Feststellung gemacht, auf einem Intel System gibt es diese hohen Latenzen nicht, weshalb ich bereits empfohlen habe ein Post im entsprechenden Forum hier abzusetzen, damit auch ein paar AMD Nutzer den Test machen.

Vielleicht funktioniert nur die Software nicht gut auf AMD Systemen, vielleicht kann man was im UEFI optimieren, aber ohne ein anderes AMD System zum Vergleich, lässt sich das schlecht feststellen.

Ergänzung (28. Mai 2021)

Daher, wo ist da nun die Kunst? Jetzt gibts mit WASAPI und DSD eine bessere Unterstützung, mehr aber auch nicht.

Die Kunst? Die steht hinter demjenigen der die APIs entwickelt und unternehmen die Treiberunterstützung dafür bauen. Hinter ASIO steht Steinberg, mit Sicherheit ein renommiertes Unternehmen, aber letztlich doch im Vergleich eine kleine "Klitsche".

Der Punkt an der Sache ist, ASIO muss entsprechend unterstützt werden und die API interessiert abseits professioneller Audiosoftware kaum jemanden. Vergleiche ASIO einfach mal mit OpenGL, die Unterstützung dafür wirst du in jedem CAD Programm und jeder professionellen Grafikkarte finden, abseits davon spielt es aber keine Rolle und die Hersteller sparen sich Optimierungen oder lassen die Unterstützung ganz weg.

 

[coxon]

@xexex ich glaube, du hast den Signalweg leider nicht ganz verstanden und wie VoiceMeeter in eben diesem bei Windows Funktioniert. App (DS zBsp.) -> API (WDM/KS/ASIO) -> Treiber (alles noch im µs-Bereich) -> Hardware (Wandlung - hier entstehen die echten Millisekunden). VM Banana ist eine GUI die Windows so nicht bietet und die dir die Konfiguration deines Signalwegs erleichtert. Welche API du letztendlich darüber benutzt, ist dir und ihren Fähigkeiten überlassen. Die Latenzen sind abhäng von deiner Software, Hardware, deinem Anwendugsszenario und Dir selbst, bzw. deinem Know-How. Ich kann nur nicht nachvollziehen warum du so am Bashen bist wegen proprietärer Software? Ich gehe jede Wette ein, du benutzt auch Windows und lauter andere propriätere Software auf deinem PC.

Ergänzung (28. Mai 2021)

Ich habe hier für meine DAW mit einem i9-10920X auch immer noch eine GTX 960 drin

Die hatten wir in der DAW am SAE auch, allerdings mit ProTools HD, lief top. Es gibt hin und wieder einfach das DCP Problem bei bestimmten Konfigurationen aus HW mit Nvidia GPU und Treiber. Habe das ewig gegoogelt, eben weil ich dieses Problem hatte. Für mich stellen sich die Indizien hier so dar, dass beim TE eben dieses Problem vorliegt. Dein Lösungsansatz ist top, so würde ich auch wieder vorgehen, stünde ich abermals vor dem gleichen Problem.

 

[xexex]

Ich kann nur nicht nachvollziehen warum du so am Bashen bist wegen proprietäre Software?

Tue ich das? Ich würde einfach behaupten du tust so als wäre ASIO die Lösung aller Weltprobleme, dabei hat Windows bereits eine ebenfalls proprietäre, dafür aber fest integrierte API, die sowieso von jeder Software und jedem Treiber unter Windows unterstützt wird.

Hast du nicht versucht mit ASIO ein Problem zu beheben, was gar nicht an dieser Stelle behebbar war? Nennst du es "Bashing" wenn ich das für Blödsinn deklariere? Wenn du professionelle Audiohardware mit professioneller Audiosoftware nutzt, mag ASIO die API der Wahl sein. Der einzige Grund dafür ist allerdings, dass es eben in dem Bereich stark ist und dementsprechend darauf vermutlich besser optimiert wird.

Außerhalb von diesem Markt hat ASIO aber keine Bedeutung und löst eben nicht alle Weltprobleme, erst recht dann nicht, wenn die Software bereits optimiert die APIs der BS-Hersteller nutzt.

VM Banana ist eine GUI die Windows so nicht bietet und die dir die Konfiguration deines Signalwegs erleichtert.

VM Banana ist ein Mixer, womit du versucht hast den Output einer Applikation umzuleiten, damit die Ausgabe dann über ASIO an den Treiber weitergereicht wird und von der Hardware verarbeitet werden kann. Das hätte nur funktionieren können, wenn WASAPI selbst an dieser Stelle irgendeine Form von Latenz produzieren würde, was aber spätestens mit Windows 10 eben nicht mehr der Fall ist.

200-300ms Latenz sind eher normal für WASAPI. *gähn

Das ist Bashing und Blödsinn oben drauf.

 

[coxon]

Emuliers dir ruhig wies brauchst, dann kommen wieder Nüsse bei raus. 😘

 

[Gorasuhl]

Vielen Dank für die Hilfe, ich hatte die letzten 2 Wochen leider zu wenig Zeit um mich damit weiter auseinanderzusetzten.

Also, die Daten zur CPU-Frequenz in HWInfo und LatencyMon kann man vernachlässigen. Ich habe dies bezüglich mal das Netz durchforstet und man findet dazu zig Foreneinträge, auch hier im CB Forum, dass einige der angezeigten Werte (u.a. Frequenz) nicht so richtig stimmen und man dafür besser das Ryzen Master Tool von AMD nutzen sollte.

Damit konnte ich zumindest ein Problem feststellen. Die CPU Parkt ganz normal bis zu 5 der 6 physischen Kerne und taktet den Übrigen, soweit wie möglich, runter (min. ca. 290Mhz, mittel ca. 800Mhz). Ich gehe davon aus, dass das im Balanced Mode auch normal ist. Das Problem ist nun, dass die CPU sich bei Höchstleistung oder Energiesparen genau so, unverändert, weiter verhält. Der minimale und höchste Leistungsmodus der Prozessorenergieverwaltung ist für Höchstleistung jeweils auf 100% gesetzt.
Das Spiel verlangt dem Prozessor auch fast nichts ab. Im Spiel sind 3 Kerne geparkt und 2 der übrigen laufen bei um die 300Mhz und der bevorzugte auf um die 900-1100Mhz. Ich sehe zwar optisch keine lags, jedoch habe ich bei schnellen Songs mit >12 Anschlägen pro Sekunde festgestellt, dass immer mal sporadisch ein paar Eingaben verzögert eingehen, obwohl die Anschläge akustisch eigentlich gepasst haben müssten.

Als erste Maßnahme habe ich für den Chipsatz den aktuellen Treiber von AMD installiert. Das brachte leider keine Änderung.

Um das Problem mit den Energiemodi zu beheben wird es wohl besser sein, wenn ich dafür einen neuen Thread in der AMD Sektion erstelle und auf diesen Thread hier einen Verweis einfüge. Falls das Problem danach noch bestehen sollte werde ich den Thread hier dann nochmal anstupsen.

 

[xexex]

Ich gehe davon aus, dass das im Balanced Mode auch normal ist. Das Problem ist nun, dass die CPU sich bei Höchstleistung oder Energiesparen genau so, unverändert, weiter verhält. Der minimale und höchste Leistungsmodus der Prozessorenergieverwaltung ist für Höchstleistung jeweils auf 100% gesetzt.

Ich kenne mich zwar mit AMD Systemen nicht so gut aus, aber bei Servern gibt es meist im UEFI eine Option um die Energieeinstellungen vom System zu überschreiben. Ich kann mir vorstellen, dass es bei dir ebenfalls der Fall ist.