Hohe Latenz bei Audioausgabe

[Gorasuhl]

Hallo,

ich habe ein Problem mit der Latenz der Audioausgabe. Diese ist meines erachtens recht hoch.
Bei Musikwiedergabe merkt man logischerweise davon nichts. Mir ist das erstmals beim Rythmus-Spiel ADOFAI (A Dance of Fire and Ice) aufgefallen, als ich dort den Input Offset bestimmen wollte.
Beim Wiedergeben von Filmen via PCM bemerkt man den Delay auch, wenn man genau hinschaut. Da ich normalerweise, falls verfügbar, die DD oder DTS Spur via Passthrough sende, habe ich das geprüft und der Delay ist dann nicht mehr sichtbar.

In ADOFAI habe ich den Input Offset für die Soundkarte, den onboard Chip und über den Monitor getestet und bekam im Mittel folgende Werte:
325ms : Soundblaster Z (SBX-Profil aktiv, DDL aktiv) -> S/PDIF-> Z5500
220ms : Soundblaster Z (SBX-Profil aktiv, DDL inaktiv) -> S/PDIF-> Z5500
215ms : Soundblaster Z (SBX-Profil inaktiv, DDL inaktiv) -> S/PDIF-> Z5500
215ms : Soundblaster Z (SBX-Profil inaktiv, DDL inaktiv) -> Analog 5.1 -> Z5500
205ms : Realtec ALC887 -> Analog 5.1 -> Z5500
195ms : Nvidia GK104 -> HDMI -> Asus MX279

Ich weiß, dass Dolby Digital Live eine gewisse Zeit, in diesem Fall ca. 100ms zum Berechnen benötigt, allerdings sind die normalen 220ms im Vergleich zu meinem Laptop und dem Desktopsystem vor der Aufrüstung recht hoch. Bei meinem Laptop (Lenovo Ideapad G510, i7-4700MQ, Win8.1 Pro) habe ich nur um die 150ms Delay. Vor der Aufrüstung meines Desktopsystems (Teilaufrüstung 9 Jahre altes System auf Ryzen 5600X?) hatte ich unter Windows 7 auch nur um die 140ms.

Ich habe schon mit dpc latency checker geprüft, ob das System irgendwo probleme macht, aber das zeigt mir normale Werte um 20µs und vereinzelte Peaks von 500-900µs an. Sollte also rein theoretisch sogar quasi echtzeitfähig sein.

Ich habe schon folgendes getestet:
onboard Sound deaktiviert und Realtek treiber entfernt -> keine Verbesserung
alle Zusatzfunktionen (SBX, EQ) in der Creative Software deaktiviert -> verbesserung um eine Handvoll ms
ältere Treiberversion -> keine Verbesserung
Bitbreite von 24 auf 16 reduziert -> keine Verbesserung
Abtastfrequenz von allen Ausgängen und "What u Hear" auf 48Khz gesetzt um Resampling bei DDL zu vermeiden -> keine Verbesserung


Lassen sich die Latenzen noch irgendwie verbessern (Puffergröße reduzieren bspw.) oder liegt das vielleicht einfach nur an Windows 10 und man kann da nichts ändern?

Ich erwarte keine Latenzen um 10ms wie beim ansprechen via ASIO. Wenn ich mit aktivem DDL auf Werte um 200-220ms kommen könnte wäre ich an sich zufrieden.


aktuelles Setup:
OS: Windows 7 Edu, 20H2
CPU: Ryzen 5600X
MoBo: Asus Prime B550-Plus
Soundkarte: Creative Soundblaster Z
Laussprecher: Logitech Z5500
Treiber sind alle aktuell

 

[xexex]

Lassen sich die Latenzen noch irgendwie verbessern (Puffergröße reduzieren bspw.) oder liegt das vielleicht einfach nur an Windows 10 und man kann da nichts ändern? Ich erwarte keine Latenzen um 10ms wie beim ansprechen via ASIO.

Eigentlich wurde es unter Windows 10 optimiert und ASIO wurde dadurch stellenweise überflüssig. Mal testweise in den Energieoptionen "Höchstleistung" eingestellt?
https://docs.microsoft.com/en-us/windows-hardware/drivers/audio/low-latency-audio

Das Problem an dieser Stelle ist eher die Frage, welche API unter Windows nutzt das von dir genannte Spiel. Niedrige Latenzen gibt es mit WASAPI (Windows Audio Session), viele Spiele und Anwendungen dürften aber viel ältere APIs nutzen.

 

[john.smiles]

Sind irgendwelche BT Audiogeräte mit dem PC verbunden?

 

[coxon]

Die SBZ ist zwar nicht mehr taufrisch und ich weiß nicht ob Creative anständige ASIO Treiber liefert, aber genau die würde ich jetzt mal ausprobieren. 200-300ms Latenz sind eher normal für WASAPI. *gähn

Schau dir mal VoiceMeeter Banana Link und die Anleitung an und probiere die ASIO Treiber bei 128-256 Samples aus. Das sollte locker 200ms bringen und der Versatz zwischen Bild und Ton spürbar reduziert werden. Surround wird von dem Tool auch unterstützt, bedarf aber erst etwas Einarbeitung um das richtige Routing zu finden.

 

[xexex]

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

Das ist so nicht richtig.

Ultra-low latency with WASAPI
Starting with Windows 10, WASAPI removed most of its aforementioned inefficiencies, and introduced a new interface: AudioClient3. If you initialize your streams with this interface, and if your audio driver is implemented correctly, you can configure a device period of just 2.67ms at 48KHz.
http://blog.nirbheek.in/2018/03/low-latency-audio-on-windows-with.html

WASAPI in der aktuellen Version ist definitiv die API die man verwenden sollte, ASIO kann man hingegen eher als "deprecated" sehen.

ob Creative anständige ASIO Treiber liefert

Creative und anständige Treiber, passt schlichtweg nicht zusammen.

EDIT:
Die erste Anlaufstelle für Latenzprobleme ist und bleibt aber der Energiesparplan.

Ausbalanciert

Höchstleistung
https://www.resplendence.com/downloads

 

[coxon]

Dass ASIO als veraltet gilt, wäre mir neu. Es ist vielleicht alt, aber jeder der mal versucht hat eine DAW ohne Aussetzer mit WASAPI zu betreiben, wird wissen warum ASIO immer noch das Mittel der Wahl ist. Selbst im Consumerbereich hat man damit wesentlich mehr Kontrolle über Eingabe, Ausgabe, Routing und Latenz.

If you initialize your streams with this interface, and if your audio driver is implemented correctly, you can configure a device period of just 2.67ms at 48KHz.

Du scheinst zu vergessen, dass Hard- und Software es erst mal unterstützen müssen.

So that was the good news. Did I mention there's bad news too? Well, now you know.

The first bit is that these numbers are only achievable if you use Microsoft's implementation of the Intel HD Audio standard for consumer drivers. This is fine; you follow some badly-documented steps and it turns out fine.

Then you realize that if you want to use something more high-end than an Intel HD Audio sound card, unless you use one of the rare pro-audio interfaces that have drivers that use the new WaveRT driver model instead of the old WaveCyclic model, you still see 10ms device periods.

... aus deinem Link.

Die traurige Wahrheit ist, dass WASAPI mit Audioclient3 auf dem Papier ganz toll aussieht, aber eben doch nicht wirklich das kann, wozu ein billiges ASIO Interface bereits seit Jahrzehnten im Stande ist. Creative Karten unterstützen ASIO ootb, also kann er nur zu gewinnen. Je nach Puffergröße sind echte 20-40ms Versatz mit Voicemeeter durchaus realistisch.

 

[xexex]

Du scheinst zu vergessen, dass Hard- und Software es erst mal unterstützen müssen.

Das vergesse ich nicht, nur gehe ich davon aus, dass Softwarentwickler an den Optimierungen seitens Microsoft beteiligt waren, sonst bräuchte Microsoft hier nicht weiter zu optimieren.
https://docs.microsoft.com/en-us/windows-hardware/drivers/audio/low-latency-audio

Was wird denn wohl ein Spiel eher unterstützen, WASAPI was seit Vista Standard ist oder ASIO?

Mir ist das erstmals beim Rythmus-Spiel ADOFAI (A Dance of Fire and Ice) aufgefallen, als ich dort den Input Offset bestimmen wollte.

Ergänzung (27. Mai 2021)

... aus deinem Link.

Was du aus meinem Link weglässt.

It seems the pro-audio industry made the decision to stick with ASIO since it already provides <5ms latency. They don't care that the API is proprietary, and that most applications can't actually use it because of that. All the apps that are used in the pro-audio world already work with it.

Das Problem ist viel eher, dass Spiele noch häufig DirectSound verwenden dürften, was aber unter Windows aktuell nur noch emuliert wird.

 

[coxon]

Was wird denn wohl ein Spiel eher unterstützen, WASAPI was seit Vista Standard ist oder ASIO?

Das Problem ist viel eher, dass Spiele noch häufig DirectSound verwenden dürften, was aber unter Windows aktuell nur noch emuliert wird.

Sorry, absoluter Bullshit. Dem Spiel ist es absolut egal ob es über WASAPI oder ASIO läuft, denn das Spiel hat das überhaupt nicht zu entscheiden . Früher zu DOS Zeiten gabs das mal ...

Du weist das System an, Audio über WASAPI/ASIO auszugeben, nicht das Spiel selbst tut das.

Ich betreibe ASIO quasi 24/7 über VM Banana ohne Probleme mit ~15ms Input+Output Latenz bei 128 Samples.

 

[xexex]

Du weist das System an, Audio über WASAPI/ASIO auszugeben, nicht das Spiel selbst tut das.

Nein! Welche API für die Soundausgabe eine Applikation nutzt, entscheidet einzig und alleine die Applikation selbst. Bei einigen kannst du es festlegen, bei einem Spiel wird es meist von der Engine bestimmt.

Dazu kommt, dass ASIO wie bereits gesagt proprietär ist und nicht "einfach so" genutzt werden kann.

The ASIO technology was developed by German company Steinberg and is protected by a licensing agreement which prevents redistribution of its source code.

Audacity, as an open source program licensed under the GPL, is therefore currently unable to support ASIO, despite being ASIO-capable (providing the user's sound device is similarly capable). If ASIO support were distributed in Audacity builds this would either violate Steinberg's licence agreement if the code were included, or conversely would violate Audacity's GPL Licence if the code were withheld.
https://manual.audacityteam.org/man/asio_audio_interface.html

 

[coxon]

Wenn Voicemeeter als Standardgerät genutzt wird, kannst du das selbst entscheiden.

Gedankenspiel: Spiel sagt Direct Sound. Ich greif den Sound am Spiel direkt ab und route es zu ASIO weiter. Und nu?

Ergänzung (27. Mai 2021)

Dazu kommt, dass ASIO wie bereits gesagt proprietär ist.

Ok, und was stört dich jetzt daran? Voicemeeter ist umsonst, bzw. Donationware wenn man möchte.

Ich finds doch auch toll, dass MS jetzt eeeeeendlich auf den Audiozug aufgesprungen ist, aber 1. halt viel zu spät und 2. einfach mies implementiert. ASIO ist vll Vintage, dafür ausgereift und weit verbreitet.

 

[xexex]

Gedankenspiel: Spiel sagt Direct Sound. Ich greif den Sound am Spiel direkt ab und route es zu ASIO weiter. Und nu?

"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.

However, the DirectSound API was deprecated in Windows XP, and with Vista, it was removed and replaced with an emulation layer on top of the newly-released WASAPI. As a result, the plugin can't be configured to have less than 200ms of latency, which makes it unsuitable for all the low-latency use-cases mentioned above. The DirectSound API is quite crufty and unnecessarily complex anyway.

Wenn deine Applikation ASIO nutzt, wunderbar, dann verwende es. Das hilft dem TE aber keinen Schritt weiter.

 

[Gorasuhl]

Die erste Anlaufstelle für Latenzprobleme ist und bleibt aber der Energiesparplan.

Hat leider nichts bewirkt, die Latenzen bleiben bei beiden Einstellungen gleich.
Ich hatte vorher schon in allen 3 Modi die Diashow für den Desktophintergrund gestoppt, sowie die Energieeinstellungen für selektives USB-Energiesparen deaktiviert, da es bei den B550 und X570 Chipsätzen Probleme mit den USB Ports gibt (siehe: AGESA ComboAM4v2Pi 1.2.0.2: AMD will USB-Probleme mit Firmware-Update beheben). Bevor einer jetzt meint es könnte an den USB Problemen liegen, daran hatte ich zuerst auch gedacht (Tastatur und Maus sind via USB3 verbunden und Probleme machen bei mir mit dem aktuellen BIOS 2006 nur noch die USB2 Ports). Da die Problematik auch bei der Wiedergabe von Videos auftritt schließe ich das eigentlich weitestgehend aus.

Nachfolgend die Daten aus LatencyMon für beide Energiesparmodi.

Spoiler: LatencyMon Statistik - Ausbalanciert

_________________________________________________________________________________________________________
CONCLUSION
_________________________________________________________________________________________________________
Your system appears to be suitable for handling real-time audio and other tasks without dropouts.
LatencyMon has been analyzing your system for 0:07:59 (h:mm:ss) on all processors.


_________________________________________________________________________________________________________
SYSTEM INFORMATION
_________________________________________________________________________________________________________
Computer name:
OS version: Windows 10, 10.0, version 2009, build: 19042 (x64)
Hardware: System Product Name, ASUS
CPU: AuthenticAMD AMD Ryzen 5 5600X 6-Core Processor
Logical processors: 12
Processor groups: 1
RAM: 32680 MB total


_________________________________________________________________________________________________________
CPU SPEED
_________________________________________________________________________________________________________
Reported CPU speed: 370 MHz

Note: reported execution times may be calculated based on a fixed reported CPU speed. Disable variable speed settings like Intel Speed Step and AMD Cool N Quiet in the BIOS setup for more accurate results.


_________________________________________________________________________________________________________
MEASURED INTERRUPT TO USER PROCESS LATENCIES
_________________________________________________________________________________________________________
The interrupt to process latency reflects the measured interval that a usermode process needed to respond to a hardware request from the moment the interrupt service routine started execution. This includes the scheduling and execution of a DPC routine, the signaling of an event and the waking up of a usermode thread from an idle wait state in response to that event.

Highest measured interrupt to process latency (µs): 201,10
Average measured interrupt to process latency (µs): 3,945664

Highest measured interrupt to DPC latency (µs): 198,60
Average measured interrupt to DPC latency (µs): 1,349543


_________________________________________________________________________________________________________
REPORTED ISRs
_________________________________________________________________________________________________________
Interrupt service routines are routines installed by the OS and device drivers that execute in response to a hardware interrupt signal.

Highest ISR routine execution time (µs): 246,620
Driver with highest ISR routine execution time: dxgkrnl.sys - DirectX Graphics Kernel, Microsoft Corporation

Highest reported total ISR routine time (%): 0,008061
Driver with highest ISR total time: HDAudBus.sys - High Definition Audio Bus Driver, Microsoft Corporation

Total time spent in ISRs (%) 0,010693

ISR count (execution time <250 µs): 50103
ISR count (execution time 250-500 µs): 0
ISR count (execution time 500-1000 µs): 0
ISR count (execution time 1000-2000 µs): 0
ISR count (execution time 2000-4000 µs): 0
ISR count (execution time >=4000 µs): 0


_________________________________________________________________________________________________________
REPORTED DPCs
_________________________________________________________________________________________________________
DPC routines are part of the interrupt servicing dispatch mechanism and disable the possibility for a process to utilize the CPU while it is interrupted until the DPC has finished execution.

Highest DPC routine execution time (µs): 885,050
Driver with highest DPC routine execution time: nvlddmkm.sys - NVIDIA Windows Kernel Mode Driver, Version 466.27 , NVIDIA Corporation

Highest reported total DPC routine time (%): 0,003086
Driver with highest DPC total execution time: ntoskrnl.exe - NT Kernel & System, Microsoft Corporation

Total time spent in DPCs (%) 0,011757

DPC count (execution time <250 µs): 127244
DPC count (execution time 250-500 µs): 0
DPC count (execution time 500-10000 µs): 114
DPC count (execution time 1000-2000 µs): 0
DPC count (execution time 2000-4000 µs): 0
DPC count (execution time >=4000 µs): 0


_________________________________________________________________________________________________________
REPORTED HARD PAGEFAULTS
_________________________________________________________________________________________________________
Hard pagefaults are events that get triggered by making use of virtual memory that is not resident in RAM but backed by a memory mapped file on disk. The process of resolving the hard pagefault requires reading in the memory from disk while the process is interrupted and blocked from execution.

NOTE: some processes were hit by hard pagefaults. If these were programs producing audio, they are likely to interrupt the audio stream resulting in dropouts, clicks and pops. Check the Processes tab to see which programs were hit.

Process with highest pagefault count: steamwebhelper.exe

Total number of hard pagefaults 21
Hard pagefault count of hardest hit process: 9
Number of processes hit: 3


_________________________________________________________________________________________________________
PER CPU DATA
_________________________________________________________________________________________________________
CPU 0 Interrupt cycle time (s): 6,513192
CPU 0 ISR highest execution time (µs): 246,620
CPU 0 ISR total execution time (s): 0,615773
CPU 0 ISR count: 50042
CPU 0 DPC highest execution time (µs): 885,050
CPU 0 DPC total execution time (s): 0,566273
CPU 0 DPC count: 111213
_________________________________________________________________________________________________________
CPU 1 Interrupt cycle time (s): 3,128757
CPU 1 ISR highest execution time (µs): 0,0
CPU 1 ISR total execution time (s): 0,0
CPU 1 ISR count: 0
CPU 1 DPC highest execution time (µs): 425,670
CPU 1 DPC total execution time (s): 0,019476
CPU 1 DPC count: 2800
_________________________________________________________________________________________________________
CPU 2 Interrupt cycle time (s): 2,926658
CPU 2 ISR highest execution time (µs): 0,0
CPU 2 ISR total execution time (s): 0,0
CPU 2 ISR count: 0
CPU 2 DPC highest execution time (µs): 230,420
CPU 2 DPC total execution time (s): 0,003608
CPU 2 DPC count: 804
_________________________________________________________________________________________________________
CPU 3 Interrupt cycle time (s): 2,732034
CPU 3 ISR highest execution time (µs): 0,0
CPU 3 ISR total execution time (s): 0,0
CPU 3 ISR count: 0
CPU 3 DPC highest execution time (µs): 2,230
CPU 3 DPC total execution time (s): 0,000015
CPU 3 DPC count: 14
_________________________________________________________________________________________________________
CPU 4 Interrupt cycle time (s): 2,237799
CPU 4 ISR highest execution time (µs): 0,0
CPU 4 ISR total execution time (s): 0,0
CPU 4 ISR count: 0
CPU 4 DPC highest execution time (µs): 300,280
CPU 4 DPC total execution time (s): 0,018339
CPU 4 DPC count: 2869
_________________________________________________________________________________________________________
CPU 5 Interrupt cycle time (s): 2,170687
CPU 5 ISR highest execution time (µs): 0,0
CPU 5 ISR total execution time (s): 0,0
CPU 5 ISR count: 0
CPU 5 DPC highest execution time (µs): 279,810
CPU 5 DPC total execution time (s): 0,018056
CPU 5 DPC count: 2301
_________________________________________________________________________________________________________
CPU 6 Interrupt cycle time (s): 3,410913
CPU 6 ISR highest execution time (µs): 0,0
CPU 6 ISR total execution time (s): 0,0
CPU 6 ISR count: 0
CPU 6 DPC highest execution time (µs): 281,210
CPU 6 DPC total execution time (s): 0,013362
CPU 6 DPC count: 2482
_________________________________________________________________________________________________________
CPU 7 Interrupt cycle time (s): 2,287580
CPU 7 ISR highest execution time (µs): 0,0
CPU 7 ISR total execution time (s): 0,0
CPU 7 ISR count: 0
CPU 7 DPC highest execution time (µs): 287,890
CPU 7 DPC total execution time (s): 0,020908
CPU 7 DPC count: 3132
_________________________________________________________________________________________________________
CPU 8 Interrupt cycle time (s): 1,232578
CPU 8 ISR highest execution time (µs): 0,0
CPU 8 ISR total execution time (s): 0,0
CPU 8 ISR count: 0
CPU 8 DPC highest execution time (µs): 251,970
CPU 8 DPC total execution time (s): 0,001660
CPU 8 DPC count: 128
_________________________________________________________________________________________________________
CPU 9 Interrupt cycle time (s): 1,217385
CPU 9 ISR highest execution time (µs): 0,0
CPU 9 ISR total execution time (s): 0,0
CPU 9 ISR count: 0
CPU 9 DPC highest execution time (µs): 251,80
CPU 9 DPC total execution time (s): 0,002737
CPU 9 DPC count: 243
_________________________________________________________________________________________________________
CPU 10 Interrupt cycle time (s): 2,148490
CPU 10 ISR highest execution time (µs): 1,280
CPU 10 ISR total execution time (s): 0,000005
CPU 10 ISR count: 16
CPU 10 DPC highest execution time (µs): 220,580
CPU 10 DPC total execution time (s): 0,002749
CPU 10 DPC count: 352
_________________________________________________________________________________________________________
CPU 11 Interrupt cycle time (s): 1,845099
CPU 11 ISR highest execution time (µs): 0,810
CPU 11 ISR total execution time (s): 0,000022
CPU 11 ISR count: 45
CPU 11 DPC highest execution time (µs): 312,130
CPU 11 DPC total execution time (s): 0,009869
CPU 11 DPC count: 1020
_________________________________________________________________________________________________________

Spoiler: LatencyMon Statistik - Höchstleistung

_________________________________________________________________________________________________________
CONCLUSION
_________________________________________________________________________________________________________
Your system appears to be suitable for handling real-time audio and other tasks without dropouts.
LatencyMon has been analyzing your system for 0:13:05 (h:mm:ss) on all processors.


_________________________________________________________________________________________________________
SYSTEM INFORMATION
_________________________________________________________________________________________________________
Computer name:
OS version: Windows 10, 10.0, version 2009, build: 19042 (x64)
Hardware: System Product Name, ASUS
CPU: AuthenticAMD AMD Ryzen 5 5600X 6-Core Processor
Logical processors: 12
Processor groups: 1
RAM: 32680 MB total


_________________________________________________________________________________________________________
CPU SPEED
_________________________________________________________________________________________________________
Reported CPU speed: 370 MHz

Note: reported execution times may be calculated based on a fixed reported CPU speed. Disable variable speed settings like Intel Speed Step and AMD Cool N Quiet in the BIOS setup for more accurate results.


_________________________________________________________________________________________________________
MEASURED INTERRUPT TO USER PROCESS LATENCIES
_________________________________________________________________________________________________________
The interrupt to process latency reflects the measured interval that a usermode process needed to respond to a hardware request from the moment the interrupt service routine started execution. This includes the scheduling and execution of a DPC routine, the signaling of an event and the waking up of a usermode thread from an idle wait state in response to that event.

Highest measured interrupt to process latency (µs): 211,0
Average measured interrupt to process latency (µs): 3,621559

Highest measured interrupt to DPC latency (µs): 200,40
Average measured interrupt to DPC latency (µs): 1,417209


_________________________________________________________________________________________________________
REPORTED ISRs
_________________________________________________________________________________________________________
Interrupt service routines are routines installed by the OS and device drivers that execute in response to a hardware interrupt signal.

Highest ISR routine execution time (µs): 305,810
Driver with highest ISR routine execution time: dxgkrnl.sys - DirectX Graphics Kernel, Microsoft Corporation

Highest reported total ISR routine time (%): 0,013096
Driver with highest ISR total time: dxgkrnl.sys - DirectX Graphics Kernel, Microsoft Corporation

Total time spent in ISRs (%) 0,021023

ISR count (execution time <250 µs): 138946
ISR count (execution time 250-500 µs): 0
ISR count (execution time 500-1000 µs): 1
ISR count (execution time 1000-2000 µs): 0
ISR count (execution time 2000-4000 µs): 0
ISR count (execution time >=4000 µs): 0


_________________________________________________________________________________________________________
REPORTED DPCs
_________________________________________________________________________________________________________
DPC routines are part of the interrupt servicing dispatch mechanism and disable the possibility for a process to utilize the CPU while it is interrupted until the DPC has finished execution.

Highest DPC routine execution time (µs): 716,270
Driver with highest DPC routine execution time: nvlddmkm.sys - NVIDIA Windows Kernel Mode Driver, Version 466.27 , NVIDIA Corporation

Highest reported total DPC routine time (%): 0,006227
Driver with highest DPC total execution time: nvlddmkm.sys - NVIDIA Windows Kernel Mode Driver, Version 466.27 , NVIDIA Corporation

Total time spent in DPCs (%) 0,018192

DPC count (execution time <250 µs): 329955
DPC count (execution time 250-500 µs): 0
DPC count (execution time 500-10000 µs): 102
DPC count (execution time 1000-2000 µs): 0
DPC count (execution time 2000-4000 µs): 0
DPC count (execution time >=4000 µs): 0


_________________________________________________________________________________________________________
REPORTED HARD PAGEFAULTS
_________________________________________________________________________________________________________
Hard pagefaults are events that get triggered by making use of virtual memory that is not resident in RAM but backed by a memory mapped file on disk. The process of resolving the hard pagefault requires reading in the memory from disk while the process is interrupted and blocked from execution.

NOTE: some processes were hit by hard pagefaults. If these were programs producing audio, they are likely to interrupt the audio stream resulting in dropouts, clicks and pops. Check the Processes tab to see which programs were hit.

Process with highest pagefault count: firefox.exe

Total number of hard pagefaults 95
Hard pagefault count of hardest hit process: 43
Number of processes hit: 9


_________________________________________________________________________________________________________
PER CPU DATA
_________________________________________________________________________________________________________
CPU 0 Interrupt cycle time (s): 10,531116
CPU 0 ISR highest execution time (µs): 305,810
CPU 0 ISR total execution time (s): 1,980110
CPU 0 ISR count: 138003
CPU 0 DPC highest execution time (µs): 716,270
CPU 0 DPC total execution time (s): 1,494137
CPU 0 DPC count: 292155
_________________________________________________________________________________________________________
CPU 1 Interrupt cycle time (s): 3,551165
CPU 1 ISR highest execution time (µs): 0,0
CPU 1 ISR total execution time (s): 0,0
CPU 1 ISR count: 0
CPU 1 DPC highest execution time (µs): 380,330
CPU 1 DPC total execution time (s): 0,020738
CPU 1 DPC count: 4673
_________________________________________________________________________________________________________
CPU 2 Interrupt cycle time (s): 1,457092
CPU 2 ISR highest execution time (µs): 0,0
CPU 2 ISR total execution time (s): 0,0
CPU 2 ISR count: 0
CPU 2 DPC highest execution time (µs): 238,820
CPU 2 DPC total execution time (s): 0,008058
CPU 2 DPC count: 2298
_________________________________________________________________________________________________________
CPU 3 Interrupt cycle time (s): 3,115104
CPU 3 ISR highest execution time (µs): 0,0
CPU 3 ISR total execution time (s): 0,0
CPU 3 ISR count: 0
CPU 3 DPC highest execution time (µs): 167,710
CPU 3 DPC total execution time (s): 0,000747
CPU 3 DPC count: 186
_________________________________________________________________________________________________________
CPU 4 Interrupt cycle time (s): 2,422409
CPU 4 ISR highest execution time (µs): 0,0
CPU 4 ISR total execution time (s): 0,0
CPU 4 ISR count: 0
CPU 4 DPC highest execution time (µs): 246,470
CPU 4 DPC total execution time (s): 0,003843
CPU 4 DPC count: 998
_________________________________________________________________________________________________________
CPU 5 Interrupt cycle time (s): 2,456418
CPU 5 ISR highest execution time (µs): 0,0
CPU 5 ISR total execution time (s): 0,0
CPU 5 ISR count: 0
CPU 5 DPC highest execution time (µs): 337,240
CPU 5 DPC total execution time (s): 0,009145
CPU 5 DPC count: 1795
_________________________________________________________________________________________________________
CPU 6 Interrupt cycle time (s): 3,762249
CPU 6 ISR highest execution time (µs): 0,0
CPU 6 ISR total execution time (s): 0,0
CPU 6 ISR count: 0
CPU 6 DPC highest execution time (µs): 329,590
CPU 6 DPC total execution time (s): 0,140747
CPU 6 DPC count: 23178
_________________________________________________________________________________________________________
CPU 7 Interrupt cycle time (s): 3,846189
CPU 7 ISR highest execution time (µs): 0,0
CPU 7 ISR total execution time (s): 0,0
CPU 7 ISR count: 0
CPU 7 DPC highest execution time (µs): 265,950
CPU 7 DPC total execution time (s): 0,017338
CPU 7 DPC count: 1988
_________________________________________________________________________________________________________
CPU 8 Interrupt cycle time (s): 1,185657
CPU 8 ISR highest execution time (µs): 1,050
CPU 8 ISR total execution time (s): 0,000205
CPU 8 ISR count: 588
CPU 8 DPC highest execution time (µs): 189,910
CPU 8 DPC total execution time (s): 0,002888
CPU 8 DPC count: 515
_________________________________________________________________________________________________________
CPU 9 Interrupt cycle time (s): 1,124667
CPU 9 ISR highest execution time (µs): 0,770
CPU 9 ISR total execution time (s): 0,000014
CPU 9 ISR count: 37
CPU 9 DPC highest execution time (µs): 216,980
CPU 9 DPC total execution time (s): 0,002417
CPU 9 DPC count: 358
_________________________________________________________________________________________________________
CPU 10 Interrupt cycle time (s): 1,885110
CPU 10 ISR highest execution time (µs): 0,840
CPU 10 ISR total execution time (s): 0,000069
CPU 10 ISR count: 203
CPU 10 DPC highest execution time (µs): 298,690
CPU 10 DPC total execution time (s): 0,006911
CPU 10 DPC count: 981
_________________________________________________________________________________________________________
CPU 11 Interrupt cycle time (s): 2,048350
CPU 11 ISR highest execution time (µs): 12,230
CPU 11 ISR total execution time (s): 0,000053
CPU 11 ISR count: 116
CPU 11 DPC highest execution time (µs): 280,870
CPU 11 DPC total execution time (s): 0,006755
CPU 11 DPC count: 932
_________________________________________________________________________________________________________

Schau dir mal VoiceMeeter Banana Link und die Anleitung an und probiere die ASIO Treiber bei 128-256 Samples aus. Das sollte locker 200ms bringen und der Versatz zwischen Bild und Ton spürbar reduziert werden. Surround wird von dem Tool auch unterstützt, bedarf aber erst etwas Einarbeitung um das richtige Routing zu finden.

Voicemeeter schaue ich mir später mal an. Wenn ich das richtig verstanden habe Leite ich mit der Software den Datenstrom um den Windows Mixer herum, also eine Anwendung leitet ihren Datenstrom an Voicemeeter und dieses spricht dann z.B. den ASIO Treiber der Soundblaster Z an, richtig?

Ich glaube Standartmäßig ist der ASIO Treiber von Creative auf 50ms gestellt. Wenn man den Wert unoptimiert nutzt und dazu noch die 100ms vom DDL Encoding und zur Sicherheit nochmal 15ms drauf packt sollte die Latenz bei rund 165ms, also fast der Hälfte vom jetzigen liegen.

Sind irgendwelche BT Audiogeräte mit dem PC verbunden?

Nein, keine BT Geräte, Lautsprecher via Toslink und ggf. Analog via 3x Stereo Klinke, Headset auch Analog via Stereo Klinke.

Das Problem an dieser Stelle ist eher die Frage, welche API unter Windows nutzt das von dir genannte Spiel. Niedrige Latenzen gibt es mit WASAPI (Windows Audio Session), viele Spiele und Anwendungen dürften aber viel ältere APIs nutzen.

Gute Frage. Das Spiel ist mit Unity entworfen worden. Es gibt da möglichkeiten für WASAPI oder ASIO, nur glaube ich nicht, dass der Entwickler die genutzt hat. Ich denke da mal an standard DirectSound.

 

[coxon]

Voicemeeter schaue ich mir später mal an. Wenn ich das richtig verstanden habe Leite ich mit der Software den Datenstrom um den Windows Mixer herum, also eine Anwendung leitet ihren Datenstrom an Voicemeeter und dieses spricht dann z.B. den ASIO Treiber der Soundblaster Z an, richtig?

Richtig. VM ist ein eigenständiger Audiotreiber der dir mehr Kontrolle und mehr Komfort bietet als Windows das ootb kann. Du stellst ihn als Standardtreiber in der Soundsteuerung ein und er übernimmt den Rest nach deinem Gusto.

DS, WASAPI, ASIO, CoreAudio und das Linuxteil sind Software zur Verarbeitung und Weitergabe von Daten an Hardware. Wie gut, bzw. zuverlässig diese Module funktionieren, hängt von ihrer Programmierung, Implementierung und dem Nutzer samt Hard- und Software ab.

und wie bei jeder Emulation kommen vor allem Nüsse bei heraus.

Das seh ich genauso. Bis auf die Emulation, und die Nüsse. 😁

 

[xexex]

Nachfolgend die Daten aus LatencyMon für beide Energiesparmodi.

Das finde ich ehrlich gesagt ziemlich erschreckend, auch wenn natürlich hier wohl eher der Schnitt zählt

Highest measured interrupt to process latency (µs): 211,0
Average measured interrupt to process latency (µs): 3,621559

Highest measured interrupt to DPC latency (µs): 200,40
Average measured interrupt to DPC latency (µs): 1,417209

Bei mir i7-8086K bekomme ich folgendes im Energiesparplan "Höchstleistung"

Highest measured interrupt to process latency (µs): 91,40
Average measured interrupt to process latency (µs): 2,313243

Highest measured interrupt to DPC latency (µs): 59,30
Average measured interrupt to DPC latency (µs): 0,675561

Jetzt bin ich aber weder ein AMD Profi, noch habe ich hier mehrere Rechner zur Verfügung um zu behaupten, das es irgendwas mit deinem System zu tun haben muss. Hast du denn die Chipsatztreiber von AMD installiert? Gibt es da nicht noch andere Energieprofile?

DAS ist nämlich extrem "strange".

Sollte im "Höchstleistung" Profil definitiv mindestens beim Grundtakt liegen, da die CPU in dem Profil nicht mehr im Stromsparmodus schalten sollte.

Was sagt denn bei dir HWInfo? Es sollte im dem Profil dauerhaft so aussehen.

EDIT: Aha!

https://community.amd.com/t5/processors/missing-power-plans-on-amd-ryzen-5000-series/td-p/259920

Stelle mal den Regler nach ganz rechts und teste nochmal!

 

[coxon]

Es fehlt die Zeit über die gemessen wurde und welches Modul die Spitzen verursacht, aber da er ne Nvidia hat, tippe ich auf nvdd... wddm und/oder directx.

Ansich ein typischer Wert für eine Kepler GPU, falls

195ms : Nvidia GK104 -> HDMI -> Asus MX279

GK104 für eine Keppler GPU steht.

Im Logfile steht es: Die Uralt-GPU, bzw deren Treiber. Möglich, dass eine andere Treiberversion Abhilfe schafft, ist aber wie die Suche nach der Nadel im Heuhaufen.

 

[Gorasuhl]

Hast du denn die Chipsatztreiber von AMD installiert?

Ja, müsste Version 2.11.26.106 sein.

Was sagt denn bei dir HWInfo? Es sollte im dem Profil dauerhaft so aussehen.

Sieht bei mir wie nachfolgend aus. Basistakt ist 3700Mhz. Bei Ausgeglichen geht der Takt runter auf 3600Mhz und bei Höchstleistung auf 3675Mhz. Der kurzzeitige Boosttakt liegt bei 4650Mhz.

Stelle mal den Regler nach ganz rechts und teste nochmal!

Hat den gleichen Effekt wie bei Höchstleistung. Die Werte in LatencyMon sind auch unverändert, daher spare ich mir hier die neuen Werte anzuheften.

Im Logfile steht es: Die Uralt-GPU, bzw deren Treiber. Möglich, dass eine andere Treiberversion Abhilfe schafft, ist aber wie die Suche nach der Nadel im Heuhaufen.

Treiber Version 466.47 ist die aktuelle Version von Nvidia für meine Karte. Ja ist eine etwas ältere Karte mit Keppler GPU, und zwar eine GTX 670 Sig2 von Evga. Reicht mir aber für meine Anwendungszwecke.

Und jetzt wird es interessant. Ich habe Voicemeeter Banana installiert und eingerichtet. Ich habe den Auxilary Eingang als Standard festgelegt und als Ausgang A1 den SBZ mit ASIO. Die Latenz ist mit den Standarteinstellungen nochmal eine ganze ecke Höher als vorher (ca. 460ms). Ich habe dann angefangen und die Buffermenge reduziert. Ohne Hörbare Fehler kam ich auf ca. 360-380ms (Einstellung siehe nachfolgende Bilder). Wenn ich die Latenz radikal aufs Minimum reduziere, also 1024 Input und 2ms für ASIO bekomme ich zwar hin und wieder Aussetzer und Störgeräusche (Knacksen), aber die Latenz nähert sich nur den vorherigen 325ms an. Alle Werte sind mit aktiven Dolby Digital Live.
Gleiches gilt aber auch wenn DDL inaktiv ist, nur dann halt um die 350ms statt den 220ms. Getestet habe ich auch WDM und MME, sind aber nochmal so rund 20-40ms träger. Optisch oder Analog verbunden macht auch keinen Unterschied, Analog via onBoard Realtek Chip ebenfalls nicht.

Hier noch die Bilder der Einstellungen.

 

[xexex]

Und jetzt wird es interessant.

Daran ist nichts "Interessant".

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

Es war auch leider nicht anders zu erwarten.

Mein Vorschlag wäre ein neuer Thread in AMD Bereich, vielleicht hat da jemand noch ein paar Tricks wie man die Latenz bei dir reduziert. Wie gesagt stimmt da in meinen Augen was nicht und es würde Sinn machen es mit jemandem der auch ein AMD System hat zu vergleichen.
https://www.computerbase.de/forum/forums/mainboards-und-cpus-probleme-mit-amd.98/

Ich habe an meinem System nichts besonderes optimiert und die Werte zwischen Ausbalanciert und Höchstleistung waren komplett unterschiedlich. Bei dir kommt es mir hingegen so vor, als würde sich bei Höchstleistung nichts an der Latenz verändern.

Der einzige Tipp von mir, wäre die Info aus LatencyMon:

Note: reported execution times may be calculated based on a fixed reported CPU speed. Disable variable speed settings like Intel Speed Step and AMD Cool N Quiet in the BIOS setup for more accurate results.

Wenn du noch ein wenig selbst mit dem LatencyMon herumspielen willst, würde es Sinn machen wenn du es laufen lässt während du dein Spiel nutzt. Dann sollten eigentlich auch die Prozesse erfasst werden die während der Ausführung genutzt werden.

 

[coxon]

Hi. Du hast falsche Einstellungen im Voicemeeter vorgenommen. Es ist nicht die Latenz die du verstellt hast, sondern die interne puffergröße des Mixers. Zudem hast du auch die Standardpuffergröße von WDM MME und KS verstellt. Das sollte immer auf standard stehen. Die richtige Puffergröße und Latenz findest du in deinem ASIO Treiber der Creative Soundkarte, nicht im Mixer. Bitte noch mal dringend in die Anleitung schauen.

 

[PHuV]

Dazu kommt, dass ASIO wie bereits gesagt proprietär ist und nicht "einfach so" genutzt werden kann.

Äh, nein, das ist schon lange Standard im Semi-/Profi-Audioumfeld. Nenne mir doch mal bitte einen gängigen Audio-Geräte- und Softwarehersteller (DAWs, Plugins etc.) im Studiobereich, der KEINEN ASIO-Treiber anbietet. Das ist ganz weit von proprietär entfernt.

Ergänzung (28. Mai 2021)

WASAPI in der aktuellen Version ist definitiv die API die man verwenden sollte, ASIO kann man hingegen eher als "deprecated" sehen.

Watt? Wo hast Du diesen Quatsch her? Veraltet ist das noch lange nicht, siehe oben. Im Semi-/Profiumfeld verwendet keiner dieser Hersteller WASAPI, keiner! coxon hat Dich ja schon an vielen Stellen korriert, und sorry, Dein Halbwissen in dieser Materie ist wirklich irritierend und verwirrend bzw. grottenfalsch.

@Gorasuhl
Na ja, man muß auch eines sehen, daß Soundblaster seit langem meilenweit weg von "gut" bzgl. Treiber sind. Es gab hier schon zu Vista-Zeiten immer wieder üble Probleme mit allen Arten von Soundblaster-Karten, so daß ich sie vor einigen Jahren alle konsequenterweise rausgehauen habe. Schade, die waren früher mal richtig gut, aber heute schaffen sie mehr Probleme. Und sobald man eh ein bißchen ernster sich irgendwo im Audio-Umfeld bewegt, holt man sich eh was besseres und gescheiteres als dieses Soundblaster-Zeugs. Und der AISO-Treiber von SB war schon immer besch...eiden. Mal als kurzer Workaround für eine DAW ohne sonstigen Sound war ok, aber sonst leider immer zu buggy und zu träge, verglichen mit einer ASIO-Lösung einer selbst günstigen semiprofessionellen Audiokarte.

 

[Gorasuhl]

Hi. Du hast falsche Einstellungen im Voicemeeter vorgenommen. Es ist nicht die Latenz die du verstellt hast, sondern die interne puffergröße des Mixers. Zudem hast du auch die Standardpuffergröße von WDM MME und KS verstellt. Das sollte immer auf standard stehen. Die richtige Puffergröße und Latenz findest du in deinem ASIO Treiber der Creative Soundkarte, nicht im Mixer. Bitte noch mal dringend in die Anleitung schauen.

Öhm, ich habe geschrieben, dass ich mit den Standarteinstellungen schon hohe Latenzen hatte. Die in den Screenshots gezeigten Werte sind die, bei welchen ich schon experimentiert habe um die Latenzen zu reduzieren.

Und die Aussage, dass ich nicht die Latenz, sondern nur den Puffer verstellt habe stimmt so nicht ganz. Die Latenz lässt sich bei einem Digitalen Audsiosystem nicht direkt verändern, sondern nur indirekt. Entweder kann dies über die Diemnsionierung der Puffer geschehen oder die Samplerate.
Der größte Puffer ist der Puffer Eingangsseitig. Beim Voicemeeter ist dieser Standard auf 7168 Samples. Bei einer Samplerate von 44.1000Samples/sec entsteht dadruch eine Verzögerung von 162msec bis der Puffer gefüllt ist und die Daten weitergeleitet werden.
Typische Werte für den Ausgangspuffer bei ASIO sind 256Samples. Bei 44.100Samples/ses erzeugt dieser eine Verzögerungszeit von rund 5,8msec.

Der ASIO Treiber der Karte arbeitet normal. Ich habe zum Testen mal mein altes Cubase SX ausgekramt, Line-Out und Line-In mechanisch verbunden und die Verzögerung von Line-Out zu Line-In gemessen. Ergebnis sind 14-15msec. Der Wert beinhaltet die Verzögerung durch die Puffer der Ein-und Ausgabe via ASIO, sowie die Zeiten des DAC und ADC.

Ich habe an meinem System nichts besonderes optimiert und die Werte zwischen Ausbalanciert und Höchstleistung waren komplett unterschiedlich. Bei dir kommt es mir hingegen so vor, als würde sich bei Höchstleistung nichts an der Latenz verändern.

Wieso sollten die Werte auch großartig voneinander abweichen? Die CPU hat dauerhaft alle Module aktiv. Ich habe im BIOS nur das XMP Profil des Arbeitsspeichers aktiviert und, bis auf die normale boost-Funktion, die Übertaktungsfunktionen, wie TPU, deaktiviert.
Entsprechend läuft die CPU bei Höchstleistung nicht permanent mit dem Boosttakt. Bei Ausgeglichen reduziert das System die Taktrate etwas auf 3600Mhz und bei Höchstleistung sollte das System eigentlich mit den von AMD angegebenen 3700Mhz laufen. Der Boosttakt ist in beiden Fällen 4650Mhz, wodurch die Messwerte von LatencyMon fast gleich sind. Würde ich den Boost deaktivieren, dann sollte eine Differenz zwischen 3600 und den 3675Mhz messbar sein. Eine gute Frage wäre, wieso der Basistakt bei Höchstleistung nicht auf die angegebenen 3700Mhz steigt, sondern nur bei 3675Mhz liegt.

Daran ist nichts "Interessant".

Für mich ist es interessant. Das kommt immer auf den Betrachter an. Ich könnte alternativ auch erstaunlich benutzen.
Und wieso sollte ich nicht erstaunt sein. Es wurde genannt, dass Voicemeeter den Windows Mixer ersetzt und sich die Verzögerung verbessern sollte. Stattdessen hatte ich die Verzögerung wie vorher über den Windows Mixer plus die von Voicemeeter obendrauf.

@Gorasuhl
Na ja, man muß auch eines sehen, daß Soundblaster seit langem meilenweit weg von "gut" bzgl. Treiber sind. Es gab hier schon zu Vista-Zeiten immer wieder üble Probleme mit allen Arten von Soundblaster-Karten, so daß ich sie vor einigen Jahren alle konsequenterweise rausgehauen habe. Schade, die waren früher mal richtig gut, aber heute schaffen sie mehr Probleme. Und sobald man eh ein bißchen ernster sich irgendwo im Audio-Umfeld bewegt, holt man sich eh was besseres und gescheiteres als dieses Soundblaster-Zeugs. Und der AISO-Treiber von SB war schon immer besch...eiden. Mal als kurzer Workaround für eine DAW ohne sonstigen Sound war ok, aber sonst leider immer zu buggy und zu träge, verglichen mit einer ASIO-Lösung einer selbst günstigen semiprofessionellen Audiokarte.

Dass Creative Labs Probleme mit ihren Treibern hat ist nichts neues. Hatte bei meiner Audigy unter XP schon einige Probleme, dass z.B. einfach mal die Karte nach einem Neustart nicht mehr erkannt wurde oder sich regelmäßig die Einstellungen zurückgesetzt haben.
ASIO ging bei mir aber auch unter XP früher eigentlich recht gut. Mit um die 10ms zwar kein Wunderwerk, bezogen auf den Preis gegenüber einem guten DI konnte ich aber nicht meckern. Für einfache Aufnahmen von Schlagzeug, Gitarre oder Bass habe ich mir vor einigen Jahren mal ein DI von Line6 geholt. Hat über ASIO ich meine um die 4ms, das reicht mir für meine paar Hobbyaufnahmen allemal.


Ich habe in Erfahrung bringen können, dass der Entwickler des Spiels unterschiedliche Standadrtwerte für den Input Offset festgelegt hat. Unter Windows 7 oder 8 150ms und bei Windows 10 170ms und für Mac habe ich was von 40ms gelesen. Es wird schon einen Grund geben wieso der Entwickler den Grundwert bei Win10 höher gesetzt hat. Das deckt sich zumindest mit meinem Beobachtungen, da ich auch primär Windows 10 für den Verursacher halte.
Ich habe auch noch keine Idee wieso Voicemeeter nicht wie erwartet funktioniert hat, da scheinbar noch irgendwas seitens Windows mitwirkt.


Wenn sich die Latenz nicht so richtig verbessern lässt ist das für mich auch kein Beinbruch. Für die Videowiedergabe kann ich den Delay in VLC händisch eintragen oder, falls vorhanden, passthrough nutzen. Bei den handvoll übrigen Anwendungen/Spielen finde ich mich damit erstmal ab.