ASIO, DPC, Qualität und Latenz - what the f#ckety f#ck!?

Audioquelle von außen werden von deinen Audio-Interfacen umgewandelt. sowie im Treiber im Gerät eingestellt. Das müsste deine Rechner nur marginal interesieren
. deine DAW mit korrekt eingestellten Ein-und Ausgabequellen lassen die Plugins und Trackdatein von den CPUS berechnen. Gibt hier Unterschiede in Sachen Anzahl und Art der Plugins, sowieso Größe des Tracks?
Und externe Audio Programme wie z.B. von der Grafikkarte (wenn eine drin sein sollte) sollten deinstalliert sein. Auch so Komische Anwendungen wie THX und 3d Sound.
 

Ich konnte das Problem damals als ich noch auf Windows unterwegs war auf modern standby eingrenzen. Aktuelle computer nutzen alle ausnahmslos den modern standby und nicht mehr die ACPI power states. Die Einstellungen von früher "maximale leistung" etc gibt es nicht mehr bzw. haben keine Auswirkung aufs System. Das Problem am modern standby ist, dass der Rechner selbst unter Volllast zum Energiesparen gezwungen wird und die CPU ihre threads von einem Kern zum anderen schiebt. Dabei kommt es zu Knacksern.

Vor einigen Jahren konnte man diese powerstates komplett über einen Registryeintrag und reboot deaktivieren und die Energieverwaltung manuell übernehmen. Damit war das Problem damals für mich "gelöst". Mit dem Nachteil, dass im Alltagsbetrieb ohne Recording die Energiesparmodi komplett unbrauchbar waren.

Du kannst mal googeln ob es für dein Laptop eine Möglichkeit gibt, den S0 bis S3 power state wieder zu aktivieren. S0 ist dann normale Leistung mit weniger Effizienz aber besser für Audio.
 
Die DPC Latenz hat nichts mit Audio zu tun.
Grob gesagt: sie schaut, wie lange irgendein wichtiger Prozess ungestört arbeiten kann bevor er von einer anderen Aufgabe unterbrochen wird.
Du kannst ja gleichzeitig in Word schreiben und Spotify hören.

Wenn der wichtige Prozess der ASIO Treiber ist, aber der Treiber der GFX Karte sagt ich bin noch wichtiger. Dann haut der einfach immer dazwischen.
Das wird von den Treiber/Software festgelegt und hat weder mit Hardware noch Windows zu tun.
Aber da liegt ein großer Unterschied, ob du ein System für Audio optimierst und dem alles hintenanstellst oder als Gaming System der Grafikleistung.

Ein Beispiel: was auch eine Clash sein könnte: zu wenig Ram und zuviele oder zu hungrige Programme auf. Dann fängt Windows (wie Linus und MacOS auch) an, Daten aus dem Hauptspeicher auszulagern. Und dann.. tataaa... werd der SSD Treiber ziemlich sicher wichtiger sein wollen... und es hackt die in deinen Audio Stream rein.

Nicht umsonst macht viel Speicher und Swap/Auslagern ausschalten Sinn. Auf meinem MacBook brauch ich um das für Cubase mit Plugins und Instrumenten zu gewährleisten 64GB Ram. Ohne die Instrumente 32GB.

Die Anzahl der Kerne o Threats ist auch nicht aussagekräftig, da eine Software Extra drauf programmiert werden muss, dass sie auch mehrere Kerne usw parallel nutzt.


Wenns DCP sein sollte:
Was du versuchen könntest: leg den Asio Prozess bzw ggf die DAW fest auf einen Core deines Prozessors. Wenn du Glück hast, bleibt der unbekannte Störenfried auf einem anderen Core. Das geht bei Windows. Ich weiß aber nicht mehr genau wo.
 
Das wird von den Treiber/Software festgelegt und hat weder mit Hardware noch Windows zu tun.
Aber da liegt ein großer Unterschied, ob du ein System für Audio optimierst und dem alles hintenanstellst oder als Gaming System der Grafikleistung.
Bei Laptops und vorgefertigten WIndows Systemen hat man da wenig Einfluss drauf. Die genannten Probleme konnte ich auch schon bei mehreren auf Werkszustand zurückgesetzten Rechnern feststellen. Einzige Lösung war die Holzhammermethode mit Deaktivierung von modern standby. Priorisierung von Prozessen und Kernzuweisung hat auch nix gebracht.
 
Bei Laptops und vorgefertigten WIndows Systemen hat man da wenig Einfluss drauf. Die genannten Probleme konnte ich auch schon bei mehreren auf Werkszustand zurückgesetzten Rechnern feststellen. Einzige Lösung war die Holzhammermethode mit Deaktivierung von modern standby. Priorisierung von Prozessen und Kernzuweisung hat auch nix gebracht.

Richtig und können auch wieder kommen, wenn ein Treiber update kommt. Das "modern standby" hat bei mir auch nicht immer geholfen. Letztlich wie immer: wenn ein Audio System steht und geht, dann vom Netz nehmen und nicht mehr ändern. Aber Laptops sind halt auch keine expliciten Audioworkstations.
 
Vielleicht hilft s die auch?
Sorry for the delay. In dem verlinkten Post gibt es nen Link auf ein sehr interessantes Howto. Hab's überflogen, und da sind ein paar wirklich vielversprechende Ansätze, welche ich am Wochenende mal testen werde. Thanks!

Noch ein Paar Infos:

die im S17 verbaute GPU ist ebenfalls als Heissläufer berüchtigt,
Die NVIDIA GPU nutze ich fast nie im Graphik Mode, sondern fast immer zum Rendern. Heisst: es immer nur die Intel GPU aktiv.

Gibt hier Unterschiede in Sachen Anzahl und Art der Plugins, sowieso Größe des Tracks?
Nein. Wenn ich aufnehme, dann sowieso immer "Dry"...


Komische Anwendungen wie THX und 3d Sound.
Alles disabled


eine Möglichkeit gibt, den S0 bis S3 power state wieder zu aktivieren. S0 ist dann normale Leistung mit weniger Effizienz aber besser für Audio.
Irgendwas klingelt da was. Aber würde dann der Rechner nicht immer auf volle Leistung fahren?
Ich möchte ja im silent Modus arbeiten, wegen Düsentriebwerk im high performance mode.
Ich brauche aber kein "automatisches" Runtertakten, heisst: feste/leise Werte wären ok.

Die DPC Latenz hat nichts mit Audio zu tun.
Bin mir nicht sicher. Ich hatte mal mit dem LatencyMon Tool gemessen. Da gab es Issues mit NVIDIA und noch was (ACPI?). Wenn ich das Notebook manuell auf silent konfiguriert hatte, wurden die Werte besser. Und dann wieder schlechter.


zu wenig Ram und zuviele oder zu hungrige Programme auf.
Hab 32 GByte RAM, 8TB NVME SSD ... und bei "zeitkritischen" Themen läuft nur eine App.


Was du versuchen könntest: leg den Asio Prozess bzw ggf die DAW fest auf einen Core deines Prozessors. Wenn du Glück hast, bleibt der unbekannte Störenfried auf einem anderen Core. Das geht bei Windows. Ich weiß aber nicht mehr genau wo.
Ah, das klingt so verrückt, dass es mich reizt :-)


Aber Laptops sind halt auch keine expliciten Audioworkstations.
Na, heutzutage sind doch alle Komponenten im Grunde gleich, zumindest bei den Windows Kisten.


Da ist echt viel guter Input dabei, wirklich. Bin ja auch auf nem amerikanischen Forum, und ich muss Bassic mal wieder loben: obwohl ihr Deutsche seid, ist Bassic viel hilfreicher als der Rest des Internets. Will natürlich trotzdem mein Fahrrad zurück, aber soooooooo schlimm seid ihr nun auch wieder nicht :-) :-) :-)
 
Latencymon result:

_________________________________________________________________________________________________________
CONCLUSION
_________________________________________________________________________________________________________
Your system seems to be having difficulty handling real-time audio and other tasks. You may experience drop outs, clicks or pops due to buffer underruns. One or more DPC routines that belong to a driver running in your system appear to be executing for too long. One problem may be related to power management, disable CPU throttling settings in Control Panel and BIOS setup. Check for BIOS updates.
LatencyMon has been analyzing your system for 0:01:26 (h:mm:ss) on all processors.


_________________________________________________________________________________________________________
SYSTEM INFORMATION
_________________________________________________________________________________________________________
Computer name: RONIN
OS version: Windows 11, 10.0, version 2009, build: 26100 (x64)
Hardware: ROG Zephyrus S17 GX703HRD_GX703HR, ASUSTeK COMPUTER INC.
BIOS: GX703HRD.311
CPU: GenuineIntel 11th Gen Intel(R) Core(TM) i7-11800H @ 2.30GHz
Logical processors: 16
Processor groups: 1
Processor group size: 16
RAM: 32442 MB total


_________________________________________________________________________________________________________
CPU SPEED
_________________________________________________________________________________________________________
Reported CPU speed (WMI): 2304 MHz
Reported CPU speed (registry): 2304 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): 1264,70
Average measured interrupt to process latency (µs): 11,149151

Highest measured interrupt to DPC latency (µs): 1246,10
Average measured interrupt to DPC latency (µs): 4,577375


_________________________________________________________________________________________________________
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): 364,299479
Driver with highest ISR routine execution time: ACPI.sys - ACPI Driver for NT, Microsoft Corporation

Highest reported total ISR routine time (%): 0,003025
Driver with highest ISR total time: Wdf01000.sys - Kernel Mode Driver Framework Runtime, Microsoft Corporation

Total time spent in ISRs (%) 0,003160

ISR count (execution time <250 µs): 78066
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): 1391,056424
Driver with highest DPC routine execution time: Wdf01000.sys - Kernel Mode Driver Framework Runtime, Microsoft Corporation

Highest reported total DPC routine time (%): 0,123417
Driver with highest DPC total execution time: Wdf01000.sys - Kernel Mode Driver Framework Runtime, Microsoft Corporation

Total time spent in DPCs (%) 0,210290

DPC count (execution time <250 µs): 278922
DPC count (execution time 250-500 µs): 0
DPC count (execution time 500-10000 µs): 60
DPC count (execution time 1000-2000 µs): 1
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.
 
immer auf den neusten Stand
das ist in diesem fall und anwendungszweck nicht immer gut.

grundsätzlich gilt in der windowswelt noch immer: die eierlegende wollmilchsau gibts selten.

ich betreibe z. b. ein altes thinkpad mit einem coreduo, 4 gb arbeitspeicher und mixe mit dem ding bis 48 in/out mit sac. buffer: 64, keine aussetzer. sound kommt rein/geht raus über bis zu zwei alte digiface mit wandlern per adat. zeitgleich kann sam prox die inputs aufzeichnen. auf der kiste läuft ein optimiertes xp. optimiert bedeutet, dass ich mit https://www.resplendence.com/latencymon jeden störenfried ausgemacht und entweder deinstalliert, abgeschaltet oder befriedet habe. ein heißer tipp sind grafikchips und usb-schnittstellen inkl. usb-peripherie. hier hats bei mir gehakt.

die kiste ist für nichts anderes da, kommt nicht ins netzwerk, bekommt keine updates. streckt jemand die finger nach der kiste aus, amputiere ich großzügig oberhalb der schlüsselbeine.

schnapp dir https://www.resplendence.com/latencymon und lerne die einzelnen ausgaben zu bewerten, der farbige balken auf dem ersten tab ist nur show, details findest du weiter hinten unter den weiteren tabs. eine herangehensweise ist, alles, was nicht wirklich benötigt wird, im bios zu deaktivieren, ein frisches windows inkl treiber und updates ohne weiteren firlefanz zu installieren und dann schrittweise die störenfriede mit latencymon ausfindig zu machen und diese gezielt entweder über andere treiber (auch ältere) oder über die manuelle vergabe von systemresourcen gefügig zu machen. dazu systematisch ein problem nach dem anderen mit jeweils zwischenmessungen mit latencymon angehen. dokumentieren nicht vergessen (um auch sackgassen wieder verlassen zu können, die nicht gebracht haben).
 
kannst du die nvidia-grafik deaktivieren und mit der grafik der cpu nochmal messen?
Ist deaktiviert! Die messungen oben sind Intel GPU-only

1745576592822.png
 

gemacht? säuft hamburg schon ab?
Hahaha! nee, das mach ich nicht. Ich werde nichts testen, was zu lauten Lüftern führt.
Ausser, wenn ich da etwas lerne bezüglich silent mode.


ich sehe da noch immer einen nvidia-treiber.
Hmmm ... dann müsste ich im BIOS abschalten.
Bedeutet: ich kann die NVIDIA GPU nicht zum Rendern nutzen. Ansich kein Problem, aber wäre schön, wenn ich dafür nicht immer booten müsste.

Werde ich später mal testen!
 
Hahaha! nee, das mach ich nicht. Ich werde nichts testen, was zu lauten Lüftern führt.
Ausser, wenn ich da etwas lerne bezüglich silent mode.
dazu vielleicht nicht - jedoch evtl über die auswirkungen schlechter acpi-umsetzungen auf windows-systemen bezüglich dcp-latencen. mach mal. miss und dokumentiere. dann schalteste wieder um und pumpst hamburg trocken
 



Zurück
Oben Unten