Audio Stuttering - aufgrund - Wdf01000.sys - ROG Strix Scar 17

[Unti]

Wäre noch eine Möglichkeit, bin aber jetzt nicht so der Profi was Process Lasso angeht.
Schau ich mir mal bei Gelegenheit die Tage an.

Ergänzung (29. April 2024)

Was mir gerade noch kommt.

Kann "ProcessLasso" das selbe "ParkControl" oder benötige ich dann für das parken "ParkControl" und für die Zuweisung dann "ProcessLasso"?

Ich hätte mir das so gedacht.
C-State im BIOS ein.
Mit Park Control die 8 P-Cores aktiv halten (oder zumindest 4 davon).
Hardcore Tasks auf die P-Cores fest binden (meinetwegen auch mit der Pro Variante von ProcessLasso, dann kauft man die halt einmal).
Das selbe für die E-Cores - meinetwegen von den 16 Stück - 4 immer aktiv halten, da die Audio/Video Latenzkritischen Sachen immer drauflegen.
Und jede "Game.exe" als Anwendungsgesteuert in ParkControl so einstellen, dass währenddessen kein Core mehr parkt, sondern alle aktiv sind.

Das hätte ich jetzt gemacht.
Am Desktop wär mir das jetzt kein so wichtiges anliegen - der Hobel läuft eh nur wenn gezockt wird, mein Notebook ist in Zukunft aber "primär-PC" auf dem auch Office/Multimedia dauerhaft miterledigt werden muss.
Da wäre es fatal, wenn das Teil durchgehend hohen Verbrauch verursacht, nur weil der MS eigene Scheduling Prozess voller Bullshit ist.

Klingt das nach einem Plan? Oder hat jemand ne andere Idee?

 

[Unti]

Update:
ParkControl und Process Lasso mal getestet.
C-States sind wieder an und es werden 2 separate Power Plans verwendet.

High Performance und Balanced.
High Performance = ohne Core Parking - also deaktiviert
Balanced = Core Parking ein, und mit Process Lasso - Aktive Prozesse CPUs zugewiesen.

Wie man hier sehen kann hab ich testweise Spotify mal als Audio-Latenz-kritische Anwendung hergenommen.
Habe Spotify auf 2 E-Cores gebunden (16-17) und mal geschaut ob Audio noch Probleme macht wo aus Spotify kommt.

Ergebnis: bisher nicht, alles tutti.
Man sieht im Screenshot auch, dass er diese immer "aktiv" lässt und nicht parkt.
Beim Rest würfelt er wild durch.

Habe das selbe nun auch bei Edge (Videos + Audio) probiert und auch da geht es - als Beispiel hier:
msedge.exe + edgewebview sind den ersten 4 - P-Core Threads zugewiesen.
Diese bleiben im Vordergrund aktiv, im Hintergrund ist die Last zu niedrig, dann geht hin und wieder ein Core parken - je nach Last.
Aber solange die Prozesse zugewiesen sind und nicht rumgereicht werden dürfen über alle Cores bzw. Nodes (von P-Core Node to E-Core Node) scheint alles gut zu sein.

Weiß jetzt auch nicht was ich davon halten soll.
Mir sagt das jetzt am Ende: Windows ist scheiße, kriegt es selber ohne manuellen Eingriff nicht hin.
Kann ja nicht wirklich deren Ernst sein - da darf ich jetzt abschätzen wie stark welche Anwendung auslastet und zuweisen oder wie?
Nur damit ich kein Soundflackern hab.... geil. danke M$....