KomuraSoft LLC
Kontakt
Menü

Warum setzt der Ton aus, obwohl die CPU-Auslastung niedrig ist? — Gedacht von Puffern und Fristen her

· Aktualisiert am: · · Windows, Audio, Leistung, Fehlerbehebung

Sie hören Musik, und immer wieder bricht sie mit einem Knacken ab. Sie öffnen den Task-Manager, und die CPU-Auslastung liegt bei etwa 10 %. Video läuft weiter, und die Maus bewegt sich normal.

Man möchte fragen: „Bei all diesem Spielraum ist Audio wiedergeben also zu viel verlangt?“

Was Audio braucht, ist aber nicht nur die Fähigkeit, viel Arbeit schnell zu erledigen. Es braucht auch, dass der nächste Abschnitt Klang bereitliegt, bevor das jetzt Laufende ausgeht. Dieser Artikel verfolgt dieses verspätete Nachfüllen, den Mechanismus hinter einem typischen Aussetzer.1

Wir beginnen bei der Musikwiedergabe auf einem PC. Die Abschnitte 1 bis 4 schließen die Erörterung des Mechanismus ab, ab Abschnitt 5 folgen die Untersuchungsmethoden. Vorausgesetzt wird durchgängig Audioausgabe unter Windows 11, und die Zahlen sind Annahmen zur Erklärung.

1. Audio wird wiedergegeben, während ein wenig vom Folgenden vorgehalten wird

Eine auf dem PC gespeicherte Musikdatei bringt die Lautsprecher nicht zum Klingen, indem sie einfach dort liegt. Die Wiedergabeanwendung bereitet die Audiodaten auf und liefert sie über Windows und den Treiber an das Gerät, das den Ton erzeugt. Im üblichen gemeinsam genutzten Modus mischt die Windows-Audio-Engine unterwegs mehrere Streams und wendet Effekte an.2

Würde Audio Stück für Stück genau dann übergeben, wenn es gebraucht wird, schlüge die geringste Verzögerung in der Verarbeitung direkt auf die Wiedergabe durch. Deshalb wird ein wenig von dem, was als Nächstes wiedergegeben wird, im Voraus vorgehalten. Dieser vorübergehende Ablageort ist der Puffer. Während die Wiedergabe auf der Geräteseite fortschreitet, füllen die Anwendung und die Audioverarbeitung ihn mit den nächsten Daten nach.3

Etwas Klang vorpuffern und dann wiedergebenDer Ablauf, den Puffer mit aufbereiteten Audiodaten nachzufüllen und die nächsten Daten vorzubereiten, während die Wiedergabe auf der Geräteseite fortschreitet.Bevor der Rest ausgehtDie nächsten Audiodaten vorbereitenDen Puffer nachfüllenDas gepufferte Audio wiedergeben

Abbildung 1: Damit die Wiedergabe weiterläuft, muss das Nachfüllen mit der Seite Schritt halten, die das Audio verbraucht.

Nehmen wir an, der Puffer enthält gerade 10 Millisekunden Audio. Trifft das nächste Nachfüllen in 8 Millisekunden ein, schließt es an, solange noch etwas übrig ist. Kommt aber bis in 12 Millisekunden nichts, ist der Vorrat bei der 10-Millisekunden-Marke aufgebraucht.

Dieselben 10 Millisekunden Rest, anderes Ergebnis je nach Zeitpunkt des NachfüllensAls Annahme zur Erklärung wird gezeigt, dass bei 10 Millisekunden verbliebener Wiedergabedaten ein Nachfüllen nach 8 Millisekunden rechtzeitig ankommt, während eines nach 12 Millisekunden erst nach dem Aufbrauchen eintrifft.Jetzt noch 10 MillisekundenNachfüllen 8 ms späterSchließt an, solange etwas übrig istNachfüllen 12 ms späterVorrat bei 10 ms erschöpft

Abbildung 2: Ein vereinfachtes Beispiel in Zeitbegriffen. Entscheidend ist nicht nur, ob nachgefüllt wurde, sondern wann.

Auszugehen, weil die Lieferung der benötigten Audiodaten nicht rechtzeitig eintrifft, ist ein Unterlauf. Er führt zu Aussetzern, Knacksen und Ähnlichem. Selbst wenn die Daten verspätet auftauchen, lässt sich eine bereits gehörte Lücke nachträglich nicht füllen.1

Audiowiedergabe ist Arbeit, bei der „es wurde irgendwann berechnet“ nicht genügt; gebraucht wird „es war fertig, als es klingen musste“.

In der Abbildung kennzeichnet eine durchgezogene Linie eine stets geltende Beziehung und eine gestrichelte Linie eine bedingte (die Bedingungen stehen bei jeder Beziehung auf der Detailseite). Die vollständige Liste der Beziehungen (5 insgesamt, mit Beleg und Sicherheitsgrad) und die Definitionen der wichtigsten Konzepte sind auf der Detailseite der Wissenskarte (auf Japanisch) zusammengestellt. Daten: JSON-LD / Turtle

2. Warum das Nachfüllen zu spät kommt, obwohl die CPU im Leerlauf ist

Hört man das, liegt die Antwort nahe: „Dann füllt doch früher nach, wenn die CPU im Leerlauf ist.“

Die Zahl der CPU-Auslastung ist aber keine Zählung eingehaltener Audiofristen. Wie beschäftigt die gesamte CPU über einen Zeitraum war und ob das kurze Stück Arbeit, das Audio nachfüllt, im benötigten Augenblick laufen durfte, sind zweierlei. Eine niedrige Gesamtlast ist keine Garantie, dass die Audioarbeit jedes Mal sofort an die Reihe kommt.4

Im obigen Beispiel: Selbst wenn über den größten Teil einer Sekunde Spielraum besteht, erschöpft ein einziger Abschnitt, in dem 12 Millisekunden lang nicht nachgefüllt werden kann, die verbliebenen 10 Millisekunden Audio. Spielraum, der später in der Sekunde besteht, rettet dieses eine verspätete Eintreffen nicht.

Nicht langsames Rechnen, sondern Warten auf die Gelegenheit zu laufen

Angenommen, der Code, der die Audiodaten vorbereitet, wartet auf das Ende eines Dateilesevorgangs. Oder er wartet auf eine Sperre, die eine andere Arbeit innerhalb der Anwendung hält. Während er wartet, verbraucht dieser Code selbst wenig CPU. Das bereits laufende Audio läuft trotzdem weiter ab. Eine verspätete Datenlieferung und ein wartender Thread treten unabhängig vom Aufbrauchen der CPU auf.54

Die Wiedergabe schreitet auch während Wartezeiten fort, die keine CPU verbrauchenDie Wiedergabe schreitet fort, während die Audioverarbeitung auf Daten oder eine Sperre wartet, sodass der Puffer bei weiterhin niedriger CPU-Auslastung leerlaufen kann.Audioverarbeitung wartet auf DatenDiese Arbeit verbraucht keine CPUDie Wiedergabe läuft weiter und der Rest schrumpftEin verspätetes Nachfüllen bedeutet Ausgehen

Abbildung 3: „Die CPU nicht zu benutzen“ ist nicht dasselbe wie „die nötige Arbeit ist erledigt“.

Auch Geräte, die mit Audio nichts zu tun zu haben scheinen, können es aufhalten

Es gibt einen zweiten Fall, in dem die Reihe auf der Windows-Seite nicht herumkommt.

Trifft eine Meldung von einem Netzwerkgerät oder Ähnlichem ein, führt Windows Code aus, der den Interrupt behandelt. Das kurze erste Stück dieser Arbeit ist die ISR, und der Mechanismus, der die restliche Arbeit aufschiebt, ist der DPC. Während ein gewöhnlicher DPC oder eine ISR läuft, kann diese logische CPU keine gewöhnlichen Threads ausführen. Auch die Audioverarbeitung unterliegt dem.64

Läuft solche Arbeit lange oder häufig auf der CPU, auf der das Audio laufen muss, verschiebt sich die Gelegenheit zum Nachfüllen nach hinten. Microsofts Material zur Leistungsanalyse für Audio und Video erläutert ebenfalls, dass lange DPCs und ISRs von Netzwerk-, Speicher-, Grafik- und anderen Treibern Audiostörungen verursachen können.5

Wenn die Reaktion auf ein Gerät die Ausführung von Audio verzögertLäuft ein gewöhnlicher DPC oder eine ISR lange auf der CPU, die die Audioverarbeitung benötigt, verzögert sich die Thread-Ausführung und die Nachfüllfrist kann betroffen sein.Wenn er lange läuftDPC oder ISR auf derselben CPUDie Audioausführung wird aufgehaltenDas nächste Nachfüllen kommt zu spätEin Aussetzer, sobald der Rest ausgeht

Abbildung 4: Nicht nur das Gerät, das den Ton erzeugt; Arbeit für andere Geräte kann indirekt wirken.

Anders gesagt: Ein Aussetzer bedeutet nicht nur „die CPU ist zu langsam, um die Berechnung fertigzustellen“. Die Berechnung kann nicht starten, oder die benötigten Daten treffen nicht ein. Auch dieses Warten ist Zeit, die aus der Frist des Audios herausgefressen wird.

3. Warum dann nicht einfach viel Audio vorhalten?

Kommt das Nachfüllen etwas zu spät, scheint es vernünftig, genug Vorrat zu halten, um diese Verzögerung aufzufangen. Genau diese Überlegung führt dazu, den Audiopuffer zu vergrößern.

Unter denselben Bedingungen lässt sich mit mehr vorgehaltenem Audio eine kurze Nachfüllverzögerung leichter überstehen. Aber jetzt wartet neu erzeugtes Audio hinter dem bereits vorgehaltenen.12

Wenn Sie nur Musik hören, stört ein kurzer Moment nach dem Drücken der Wiedergabe vielleicht nicht. Spielen Sie ein am PC angeschlossenes Keyboard oder bearbeiten Sie Ihre eigene Stimme von einem Mikrofon und hören sie selbst mit, wird dieses Warten zu einer Lücke zwischen Handlung und Klang.

Pufferspielraum und langsamere ReaktionMehr vorgehaltenes Audio macht vorübergehende Nachfüllverzögerungen leichter auffangbar, während auch die Wartezeit wächst, bis neues Audio wiedergegeben wird.Mehr Audio im Voraus vorhaltenNachfüllverzögerungen lassen sich leichter auffangenNeues Audio wartet dahinterMehr Verzögerung von der Handlung zum Klang

Abbildung 5: Den Puffer zu vergrößern ist eine Anpassung, die Spielraum gegen Reaktionsfähigkeit eintauscht.

Die Puffereinstellungen 128, 256 und 512 in Musikproduktionssoftware beziehen sich ebenfalls auf diese Zeit. In PCM heißt die Einheit, die die Abtastwerte aller Kanäle zum selben Zeitpunkt zusammenfasst, Frame. Bei 48 kHz sind 480 Frames 480 geteilt durch 48000 Sekunden, also 10 Millisekunden Audio. Bei gleicher Abtastrate gilt: je mehr Frames, desto länger der Audioabschnitt, den sie fassen.3

Gezählt wurde hier die Länge des Audios, die dieser Puffer darstellt. In der Praxis gibt es außerdem Verarbeitung in Anwendung, Treiber und Gerät, halten Sie das also von der Gesamtlatenz zwischen Tastendruck und gehörtem Ton getrennt. Auch teilen sich nicht alle Anwendungen unter Windows eine gemeinsame Puffereinstellung; die wählbaren Größen hängen ebenfalls von Gerät und Treiber ab.2

Kleiner ist also nicht höhere Leistung, und größer ist auch nicht die richtige Antwort. Die Anpassung besteht darin, die benötigte Reaktionsfähigkeit zu behalten und zugleich genug Spielraum zu nehmen, um Aussetzer zu vermeiden.

4. Was Audio braucht, ist Fristen einzuhalten, nicht Durchschnittsgeschwindigkeit

Zurück zur Ausgangsfrage.

Der Ton setzt bei niedriger CPU-Auslastung aus, weil Spielraum in der Gesamtverarbeitungskapazität und die rechtzeitige Lieferung des nächsten Klangabschnitts zweierlei sind.

Audio wird aus einer kleinen vorgehaltenen Menge wiedergegeben. Dieser Vorrat wird nachgefüllt, bevor er aufgebraucht ist. Ein einziges verspätetes Nachfüllen kann für eine Lücke genügen, und den Vorrat zu erhöhen bringt Spielraum, verlängert aber auch die Zeit, bis neues Audio zu hören ist.

Das ist der Kern des Mechanismus. Auch die Frage bei der Untersuchung ändert sich von „bei wie viel Prozent stand die CPU“ zu „worauf wartete im Augenblick des Tonabbruchs der nächste Klangabschnitt“. Ab hier folgt der Untersuchungsteil, um ein tatsächliches Symptom einzugrenzen.

5. Untersuchung: Finden Sie zuerst heraus, welche Kombination aussetzt

Ein gehörtes Knacken belegt für sich noch nicht den bisher beschriebenen Unterlauf. Das Ausgangsmaterial selbst, die Verarbeitung der Anwendung, Audioeffekte, das Ausgabegerät und andere Probleme erzeugen ähnliche Symptome. Microsofts Material zur Fehlerbehebung nennt ebenfalls Soundverbesserungen, das Format und Treiber unter den zu prüfenden Punkten.7

Ändern Sie zu Beginn nicht viele Einstellungen auf einmal. Geben Sie dieselbe kurze Quelle etwa gleich lang wieder und vergleichen Sie die Unterschiede einzeln. Tun Sie das außerhalb einer laufenden Besprechung oder Aufnahme, nachdem Sie Ihre Arbeit gesichert haben, und bei ohrenschonender Lautstärke.

Zu vergleichende Bedingung Was sie Ihnen sagt
Eine lokal gespeicherte Quelle gegenüber Wiedergabe über das Internet Ob es nur bei Wiedergabe über das Internet auftritt
Dieselbe Quelle in einer anderen Anwendung wiedergegeben Ob es sich auf eine Anwendung konzentriert
Ausgabe über Bluetooth und Ähnliches gegenüber eingebauter oder kabelgebundener Ausgabe Ob es sich auf einen Ausgabepfad konzentriert
Soundverbesserungen aktiviert gegenüber deaktiviert Ob die Kombination mit dieser Effektverarbeitung etwas ändert
In einer DAW oder Ähnlichem der aktuelle Puffer gegenüber einer Stufe größer Ob mehr vorgehaltener Spielraum etwas ändert

In dieser Reihenfolge lässt sich die einzeilige Klage „der Ton setzt aus“ so weit konkretisieren, dass sie lautet: „Er setzt nur in dieser Anwendung aus, wenn diese Ausgabe verwendet wird.“ Jede Änderung zurückzunehmen und es erneut zu versuchen erleichtert außerdem die Unterscheidung, ob das Symptom nur zufällig ausgeblieben ist.

Vergleich, der eine Bedingung ändert und sie dann zurücknimmtDie Reproduktion mit derselben Quelle bestätigen, eine Bedingung wie Anwendung oder Ausgabe ändern und das Ergebnis auch nach dem Zurücknehmen festhalten.Mit der ursprünglichen Kombination wiedergebenEine Bedingung ändern und wiedergebenZurücknehmen und wiedergebenBedingungen und Zeiten mit Aussetzern festhalten

Abbildung 6: Statt einer einzelnen Verbesserung bestätigen Sie, dass Bedingung und Symptom wiederholt zusammenpassen.

Beachten Sie, dass eine geänderte Ausgabe auch Treiber, Puffer und mehr ändert. „Über Kabel setzt es nicht aus“ ist ein Anhaltspunkt zur Untersuchung des Ausgabepfads, belegt für sich genommen aber nicht die Funkstrecke als Ursache. Ebenso ist eine Verbesserung durch einen größeren Puffer ein Anhaltspunkt dafür, dass zusätzlicher Zeitspielraum geholfen hat; sie beweist keinen Defekt eines bestimmten Treibers.

Um Soundverbesserungen zu vergleichen, wählen Sie in Windows unter „Einstellungen > System > Sound“ die betreffende Ausgabe aus und schalten Sie dort, wo verfügbar, „Soundverbesserungen“ aus und versuchen es erneut. Notieren Sie die ursprüngliche Einstellung und nehmen Sie sie zurück, wenn sie keinen Unterschied macht. Beziehen Sie Treiber von Windows Update oder aus der offiziellen Verteilung des Geräteherstellers und halten Sie die Versionen vor und nach der Änderung fest.7

6. Untersuchung: Den Augenblick des Aussetzers aufzeichnen und hineinzoomen

Wenn der Vergleich von Bedingungen die Sache nicht eingrenzt oder Sie Verarbeitung auf der Treiberseite vermuten, zeichnen Sie das Geschehen über einen kurzen Zeitraum auf. Der Windows Performance Recorder (WPR) nimmt die Aufzeichnung vor, und der Windows Performance Analyzer (WPA) ist das Werkzeug, um die aufgezeichnete Zeitachse im Detail zu untersuchen.8

Starten Sie die Aufzeichnung, bevor Sie es reproduzieren

Öffnen Sie auf einem Rechner, auf dem das Windows Performance Toolkit installiert ist, im WPR-Fenster „More Options“. Zu den eingebauten Profilen gehören „Audio glitches“ und „CPU usage“. Wählen Sie, ausgehend vom ersten, eine Aufzeichnung, mit der sich Audiounterbrechungen zusammen mit CPU-Aktivität untersuchen lassen. Prüfen Sie die verfügbaren Profile und ihre Anzeigenamen in der von Ihnen installierten Version.9

Starten Sie die Aufzeichnung und geben Sie dann Audio unter den zuvor gefundenen Bedingungen wieder. Notieren Sie die Zeiten der Aussetzer und was Sie taten, und beenden Sie die Aufzeichnung nach dem Reproduzieren des Symptoms mit „Save“, um die ETL-Datei zu schreiben. „Cancel“ speichert sie nicht. Etwas von einem sauberen Abschnitt einzuschließen gibt Ihnen einen Vergleichsmaßstab. Werden Sie aufgefordert, eine bestehende Aufzeichnung zu beenden, brechen Sie den Start ab und klären Sie es mit der zuständigen Person, damit keine andere Untersuchung unterbrochen wird.10

Eine kurze Aufzeichnung machen, die den Aussetzer enthältEine Aufzeichnung in WPR starten, das Symptom reproduzieren und die Zeit notieren, dann die Aufzeichnung beenden und speichern und sie in WPA untersuchen.Aufzeichnung in WPR startenDen Aussetzer unter denselben Bedingungen reproduzierenZeit und Handlungen notieren, dann speichernIn WPA in den umgebenden Zeitraum hineinzoomen

Abbildung 7: Bewahren Sie den Zeitraum, in dem das Symptom auftrat, nicht die CPU-Auslastung danach.

Eine ETL-Datei kann Prozessnamen, Dateipfade und Ähnliches enthalten, halten Sie sich also an die Regeln Ihrer Organisation und geben Sie sie nur an die Personen weiter, die sie brauchen. Das Aufzeichnen kann Rechte oder zusätzliche Werkzeuge erfordern; fragen Sie auf einem Firmen-PC die Administration. Da die Last des Aufzeichnens selbst das Symptom verändern kann, halten Sie fest, ob eine Aufzeichnung lief. Ziehen Sie eine kurze, auf Ihr Ziel abgestimmte Aufzeichnung einer langen mit allen aktivierten Anbietern vor. Halten Sie in einer Aufzeichnung, die verlorene Ereignisse meldet, die nicht sichtbaren Abschnitte nicht für unauffällig.10

Was gleichzeitig geschah, statt einer Rangfolge großer Zahlen

Zoomen Sie in WPA in den Bereich um den Aussetzer, anhand der erfassten Audioereignisse und der notierten Zeiten. Prüfen Sie über denselben Zeitbereich DPC/ISR sowie CPU Usage (Precise), das Thread-Ausführung und Wartezeiten zeigt. Fehlen diese Daten, prüfen Sie, ob das Profil die benötigten Ereignisse erfasst, und zeichnen Sie erneut auf. Ein Fehlen von Aufzeichnungen ist nicht dasselbe wie ein Fehlen eines Problems.49

Ausgangspunkt ist zu sehen, ob der audiobezogene Thread lauffähig war, aber auf seine Reihe wartete, oder nicht laufen konnte, weil er auf Daten oder Ähnliches wartete. Suchen Sie im ersten Fall nach DPCs, ISRs und Ähnlichem, die auf dieser CPU lange liefen. Verfolgen Sie im zweiten mit den verfügbaren Aufzeichnungen und Stacks, was das Warten beendete. Da auch ein laufender Thread unterbrochen werden kann, engen Sie nicht allein auf die Ready-Zeit ein; legen Sie die Abschnitte darüber, in denen DPCs und ISRs liefen.4

Untersuchen, wie während des Aussetzerzeitraums gewartet wurdeFür den Audiothread im betrachteten Zeitraum das Warten in lauffähigem Zustand vom Warten auf Daten oder Ähnliches trennen und die entsprechenden Aufzeichnungen abgleichen.Derselbe Zeitraum um den AussetzerLauffähig, aber auf die Reihe wartendAuf Daten oder Ähnliches wartendArbeit auf derselben CPU abgleichenVerfolgen, was das Warten beendete

Abbildung 8: Greifen Sie nicht allein die Höchstwerte heraus; lesen Sie sie überlagert mit dem Zeitraum, in dem die Audioverarbeitung gebraucht wurde.

Selbst wenn Sie einen langen DPC oder eine lange ISR finden, entscheiden Sie nicht nach dem Modulnamen sofort: „Dieser Treiber ist der Schuldige.“ Sie sehen womöglich einen großen Wert aus einer anderen Zeit oder eine gemeinsam genutzte Komponente, durch die mehrere Geräte laufen. Verbinden Sie die zeitliche Entsprechung zum Aussetzer, die beteiligten CPUs und die Ergebnisse geänderter Bedingungen und bitten Sie bei Bedarf den Gerätehersteller um Untersuchung.

Ebenso wenig lässt sich eine allgemeingültige Grenze ziehen wie „ein DPC unter so und so vielen Mikrosekunden verursacht auf keinem PC je einen Aussetzer“. Die Warnschwellen in der Dokumentation stehen unter der Bedingung dieser Bewertung. Verwenden Sie sie nicht als Bestanden-/Durchgefallen-Test losgelöst von der tatsächlichen Nachfüllfrist und dem Pufferspielraum.5

7. Für Entwickler: Bringen Sie keine langen Wartezeiten in den Code, der Audio übergibt

Wenn Sie selbst eine Audioanwendung bauen, ist der Ausgangspunkt derselbe. Der Code, der den nächsten Puffer füllt, muss jede Frist einhalten.

WASAPI bietet eine Möglichkeit, den Zeitpunkt, zu dem ein Puffer verarbeitet werden kann, als Ereignis zu empfangen. MMCSS wiederum erleichtert es, Threads mit zeitgebundener Multimedia-Arbeit CPU-Zeit zuzuteilen. Keines von beiden ist jedoch Magie, die Wartezeiten beseitigt. MMCSS bereitet Ihnen auch die Audiodaten von der Festplatte nicht im Voraus auf.111

Der Entwurf dafür besteht darin, den Code, der aus Dateien oder dem Netzwerk liest, vom Code zu trennen, der Audio übergibt. Erledigen Sie die Arbeit, deren Zeitverhalten schwer vorherzusagen ist, im Voraus, und verwenden Sie für die Übergabe einen vorab reservierten Puffer. Gestalten Sie es auf der Audioseite so, dass nicht auf eine UI-Antwort, eine lange Sperre, einen synchronen Log-Schreibvorgang oder Ähnliches gewartet werden muss. Das ist eine Entwurfsrichtlinie, um Datenwartezeiten von der Frist zu entkoppeln.

Schwer vorhersagbare Vorbereitung von der Audiolieferung trennenEin Entwurf, der Lesevorgänge und ähnliche Arbeit im Voraus erledigt und die aufbereiteten Daten über einen Puffer an die Audioverarbeitung übergibt, wodurch lange Wartezeiten kurz vor der Frist verringert werden.Daten in vorab erledigter Arbeit vorbereitenVorab reservierter ÜbergabebereichDer Audioverarbeitung übergeben, was sie brauchtDas Audioausgabeziel beliefern

Abbildung 9: Es geht nicht darum, langsame Arbeit zu beseitigen, sondern sie aus dem Augenblick kurz vor der Audioübergabe herauszunehmen.

Auch mit dieser Trennung geht der Vorrat aus, wenn die Vorbereitungsseite lange stockt. Halten Sie über die durchschnittliche Verarbeitungszeit hinaus die Gelegenheiten, bei denen Verarbeitung oder Warten lange dauerte, und die Anzahl fehlgeschlagener Lieferungen so fest, dass die Audioverarbeitung nicht gestört wird. Prüfen Sie die tatsächlich gewählte Puffergröße und Periode über die API oder den Treiber und gehen Sie nicht davon aus, dass „der von mir angegebene Wert unverändert übernommen wurde“.32

Vermeiden Sie es, Anwendern zu empfehlen, den gesamten Player auf Echtzeitpriorität zu setzen. Das birgt die Gefahr, andere wichtige Arbeit zu behindern, und die Priorität eines gewöhnlichen Threads anzuheben löst weder DPCs und ISRs noch Datenwartezeiten.124

8. Zusammenfassung: Niedrige CPU-Auslastung ist kein Beleg dafür, dass die Audiofrist eingehalten wurde

Es gibt drei Achsen, um über Aussetzer nachzudenken: Audio vorhalten, es nachfüllen, bevor es aufgebraucht ist, und ein verspätetes Nachfüllen bedeutet eine Lücke. Selbst bei niedriger CPU-Auslastung kann ein Warten im entscheidenden Augenblick das Nachfüllen verspäten.

Beginnen Sie damit, Anwendungen und Ausgaben mit derselben Quelle zu vergleichen, und zeichnen Sie den Zeitraum des Aussetzers auf, wenn das noch nichts erklärt. Der Übergang von „warum, wo die CPU doch Spielraum hat“ zu „worauf wartete sie in diesem Augenblick“ bringt das Nächste in den Blick, das zu untersuchen ist.

Verwandte Artikel

  1. Microsoft Learn, Exclusive-Mode Streams. Der Zeitpunkt der Pufferbelieferung und Audiostörungen, die Abwägung gegen Latenz und ereignisgesteuerte Belieferung. Es ist keine pauschale Empfehlung des exklusiven Modus selbst. ↩ ↩2 ↩3 ↩4

  2. Microsoft Learn, Low Latency Audio. Der Windows-Audiopfad, Puffer, Geräte, Effektverarbeitung und Latenz sowie die Abwägungen niedriger Latenz. ↩ ↩2 ↩3 ↩4

  3. Microsoft Learn, Rendering a Stream. Die Belieferung des Render-Puffers, die verbliebene Menge, die tatsächliche Puffergröße und die Definition eines PCM-Frames. ↩ ↩2 ↩3

  4. Microsoft Learn, CPU Analysis. Logische CPUs, die Zustände Ready und Waiting von Threads, das Verhältnis zwischen DPCs, ISRs und Thread-Ausführung sowie die CPU-Analyse in WPA. ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  5. Microsoft Learn, Results for the Streaming Media Performance Assessment. Lange und häufige DPCs und ISRs, eine unzureichende Datenlieferung und Audiostörungen. Die Warnschwellen der Bewertung werden nicht zu einem Sicherheitsmaßstab für jedes Gerät verallgemeinert. ↩ ↩2 ↩3

  6. Microsoft Learn, Introduction to DPCs. Der Mechanismus, die Interruptbehandlung kurz zu halten und die restliche Arbeit auf einen DPC aufzuschieben. ↩

  7. Microsoft Support, Fix distorted or crackling audio in Windows. Die Prüfung von Soundverbesserungen, Format, Treibern und mehr. ↩ ↩2

  8. Microsoft Learn, Windows Performance Recorder. ETW-Aufzeichnung und Analyse mit WPA sowie die Nutzung des Windows Performance Toolkit. ↩

  9. Microsoft Learn, Built-in Recording Profiles. „More Options“ in WPR und eingebaute Profile wie „Audio glitches“ und „CPU usage“. ↩ ↩2

  10. Microsoft Learn, WPR How-to Topics. Eine Aufzeichnung starten und mit „Save“ speichern, Konflikte mit einer bestehenden Sitzung sowie Hinweise zu personenbezogenen Daten und verlorenen Ereignissen. ↩ ↩2

  11. Microsoft Learn, Multimedia Class Scheduler Service. Die Zuteilung von CPU-Ressourcen an zeitgebundene Multimedia-Verarbeitung. ↩

  12. Microsoft Learn, Scheduling Priorities. Prozess- und Threadprioritäten sowie Hinweise zur Echtzeitpriorität. ↩

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Warum setzt der Ton aus, wenn die CPU-Auslastung nur bei etwa 10 % liegt?
Audio hat eine Frist: Die nächsten Daten müssen nachgefüllt sein, bevor die gerade wiedergegebenen aufgebraucht sind. Selbst bei insgesamt niedriger CPU-Auslastung kann das Nachfüllen diese Frist verfehlen, wenn die Audioverarbeitung in diesem Augenblick nicht laufen konnte oder auf die benötigten Daten wartete. Nicht jeder Aussetzer hat diese Ursache, deshalb brauchen Sie auch Vergleiche, die Ausgabegerät und Anwendung wechseln.
Behebt ein größerer Audiopuffer die Aussetzer?
Ist das Nachfüllen vorübergehend verspätet, kann ein größerer Puffer das auffangen. Aber auch die Wartezeit, bis das vorgehaltene Audio wiedergegeben wird, wächst. Es ist keine Einstellung, die einen dauerhaften Mangel an Verarbeitungskapazität oder ein sich trennendes Gerät löst. Notieren Sie in Anwendungen und Treibern, wo sich das ändern lässt, den Ausgangswert und vergleichen Sie schrittweise.
Wie viele Millisekunden Audio sind 480 Frames bei 48 kHz?
Es sind 480 geteilt durch 48000 Sekunden, also 10 Millisekunden. Ein PCM-Frame ist die Einheit, die die Abtastwerte aller Kanäle zum selben Zeitpunkt zusammenfasst. Dieser Wert ist die Länge des Audios, die diese Frame-Anzahl darstellt, nicht die Gesamtlatenz einschließlich Gerät und Anwendung.
Ist ein Treiber mit langen DPC- oder ISR-Ausführungszeiten der Schuldige hinter einem Aussetzer?
Er ist ein Kandidat, aber eine Rangfolge allein nach Ausführungszeit entscheidet das nicht. Gleichen Sie den Zeitraum des Aussetzers mit den Wartezeiten des Audiothreads und mit der DPC-/ISR-Ausführung auf derselben CPU ab. Schließen Sie nicht allein aus einem Modulnamen, dass ein bestimmtes Gerät oder ein Treiber defekt ist, und prüfen Sie auch die Ergebnisse geänderter Reproduktionsbedingungen.
Verbessert es die Lage, den Player auf Echtzeitpriorität zu setzen?
Nicht als pauschale Empfehlung. Die Priorität eines gewöhnlichen Threads anzuheben kann gewöhnliche DPCs und ISRs auf derselben CPU nicht überholen, und es beseitigt keine Wartezeiten auf Daten oder Sperren. Entwickler sollten Mechanismen wie MMCSS zusammen mit einem Entwurf einsetzen, der keine Wartezeiten in den Audiopfad bringt, während Anwender zuerst Reproduktionsbedingungen und Ausgabepfade vergleichen sollten.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.

Kontakt
Zurück zum Blog