Warum bricht der Ton ab, obwohl die CPU-Auslastung niedrig ist? — Eine Betrachtung über Puffer und Fristen

Sie hören Musik, und ab und zu bricht der Ton mit einem kurzen Knacken ab. Der Task-Manager zeigt eine CPU-Auslastung um die 10 %, und trotzdem ist nur der Ton instabil. Warum setzt der Ton in so einem Fall aus, obwohl die CPU noch Reserven hat?

Auch bei niedriger CPU-Auslastung kann der Ton aussetzen, wenn das Nachfüllen der nächsten Audiodaten seine Frist verpasst. Denn die nächsten Daten müssen übergeben werden, während das im Puffer verbliebene Audio noch abgespielt wird. Dass sich das Nachfüllen durch Warten auf Daten oder Sperren, durch DPCs/ISRs auf der benötigten logischen CPU oder Ähnliches verzögert, kann geschehen, ohne dass die CPU insgesamt ausgelastet ist. Exclusive-Mode Streams, CPU Analysis

Allerdings lässt sich allein aus dem gehörten Knacken nicht auf einen Unterlauf schließen. Ähnliche Symptome können auch von der Audioquelle, der App, Audioeffekten, dem Ausgabegerät und Ähnlichem herrühren. Vergleichen Sie zunächst mit derselben Audioquelle, indem Sie die Bedingungen einzeln ändern und wieder zurücksetzen; lässt sich die Ursache damit noch nicht eingrenzen, zeichnen Sie den Zeitraum vor und nach dem Aussetzer auf. Fix distorted or crackling audio in Windows

Dieser Artikel behandelt diese Frage und die daran anschließenden: „Sollte ich einfach den Puffer vergrößern?“ und „Was muss ich vergleichen und was aufzeichnen, um die Ursache einzugrenzen?“ Er stellt nicht allein anhand der CPU-Auslastung oder des gehörten Tons die Ursache einer einzelnen Störung fest.

Im Mittelpunkt steht die Audioausgabe unter Windows 11. Verglichen werden interne, kabelgebundene, USB-, Bluetooth- und andere Ausgaben; bei Musikproduktionssoftware (DAW) werden auch Vergleiche behandelt, sofern die App oder der Treiber eine Puffereinstellung anbietet. Der Entwurf von Aufnahmesystemen als Ganzes und die Diagnose der Funkverbindung einzelner Geräte werden nicht umfassend abgedeckt.

Die Erklärung verwendet den freigegebenen Modus als Grundbeispiel. Tatsächlicher Pfad, Puffergröße und Verarbeitungsintervall unterscheiden sich je nach App, API, Treiber und Gerät, und es gibt auch keinen Bildschirm für Puffereinstellungen, der allen Apps gemeinsam wäre. Low Latency Audio

Die hier genannte CPU-Auslastung, die verbleibenden 10 Millisekunden, die Nachfüllzeitpunkte und Ähnliches sind Annahmen zur Erklärung. Sie sind kein Bericht über eine an einem bestimmten PC gemessene Reproduktion oder Verbesserung. Die Schritte in der zweiten Hälfte sind Prüfverfahren, die Sie in Ihrer eigenen Umgebung durchführen.

Den Mechanismus können Sie der Reihe nach lesen, beginnend mit dem nächsten Abschnitt „Audiowiedergabepuffer“. Die Schritte zur Untersuchung von Aussetzern finden Sie unter „Reproduktionsbedingungen vergleichen“ und „Aussetzer mit WPR aufzeichnen“.

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

Audiowiedergabepuffer

Eine Musikdatei nur gespeichert zu haben, bringt die Lautsprecher noch nicht zum Klingen. Eine App bereitet die Audiodaten vor und liefert sie über Windows und den Treiber an das Ausgabegerät. Der Audiowiedergabepuffer ist ein Bereich, der die als Nächstes wiederzugebenden Daten vorübergehend aufnimmt. Während das Gerät die aktuellen Daten wiedergibt, bereitet die liefernde Seite die nächsten Daten vor und füllt sie nach. Rendering a Stream

flowchart TB
    accTitle: Audio ein wenig im Voraus puffern und dann wiedergeben
    accDescr: Der Ablauf, bei dem vorbereitete Audiodaten in den Puffer nachgefüllt und die nächsten Daten vorbereitet werden, während die Wiedergabe auf der Geräteseite fortschreitet.
    A["Nächstes Audio vorbereiten"] --> B["In den Puffer nachfüllen"]
    B --> C["Gepuffertes Audio abspielen"]
    C -.->|"bevor es aufgebraucht ist"| A

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

Abbildung 1 ist eine Konzeptskizze, die nur das Verhältnis von Nachfüllen und Verbrauch zeigt. Sie behandelt die mehreren Puffer im tatsächlichen Audiopfad nicht als einen einzigen physischen Bereich. Low Latency Audio

Die Aufgabe des Puffers ist es, kurze zeitliche Abweichungen zwischen der Seite, die das Audio vorbereitet, und der Seite, die es verbraucht, aufzufangen und so eine durchgehende Wiedergabe zu ermöglichen. Die Kapazität des Puffers und die Menge der noch nicht wiedergegebenen Daten, die gerade darin liegen, sind jedoch zweierlei. „Er hat eine Kapazität von 10 Millisekunden“ bedeutet nicht, dass immer 10 Millisekunden übrig sind. Rendering a Stream

Die zeitliche Bedingung, die nächsten benötigten Daten zu liefern, bevor die gerade wiedergegebenen aufgebraucht sind, nennen wir hier die Nachfüllfrist. Bei der Audioverarbeitung kommt es darauf an, „bis zum Zeitpunkt des Erklingens bereit gewesen“ zu sein. „Am Ende war es berechnet“ reicht nicht. Der Zustand, in dem die Lieferung nicht rechtzeitig kommt und die wiederzugebenden Daten ausgehen, ist ein Unterlauf, und er führt zu Aussetzern und Klickgeräuschen. Selbst wenn die Daten verspätet eintreffen, lässt sich eine bereits hörbare Lücke nachträglich nicht mehr füllen. Exclusive-Mode Streams

Der Weg der Audiodaten

Im gewöhnlichen freigegebenen Modus empfängt die Audio-Engine von Windows die von der Wiedergabe-App vorbereiteten Daten, mischt mehrere Klänge oder wendet Effekte an und übergibt sie dann an den Treiber und das Ausgabegerät. Die Wiedergabe-App ist sowohl am Einlesen der Audioquelle als auch an der Lieferung an das Ausgabeziel beteiligt, während Treiber und Ausgabegerät die Daten zur Geräteseite bringen und wiedergeben. Low Latency Audio

flowchart TB
    accTitle: Der Weg der Audiodaten im freigegebenen Modus
    accDescr: Die Audio-Engine mischt die von der Wiedergabe-App vorbereiteten Daten, wendet Effekte an und übergibt sie an den Treiber, und das Ausgabegerät gibt sie wieder.
    A["Wiedergabe-App: bereitet Daten vor"] --> E["Audio-Engine: Mischen, Effekte"]
    E --> D["Treiber: bringt sie zum Gerät"]
    D --> O["Ausgabegerät: Wiedergabe"]

Abbildung 2: Ein Beispiel für den freigegebenen Modus. Die Verarbeitung und die Puffer dazwischen hängen von API und Gerät ab.

Auch auf der Geräteseite kann es Verarbeitung und Puffer geben, sodass der Puffer auf der App-Seite allein nicht die Gesamtlatenz bestimmt. Diese Erklärung setzt den Pfad des freigegebenen Modus voraus und bedeutet nicht, dass jede API dieselbe Verarbeitung durchläuft. Low Latency Audio

Nachfüllen bei 10 Millisekunden Rest

Angenommen, im Puffer liegen gerade noch 10 Millisekunden an nicht wiedergegebenen Daten. Kommt das nächste Nachfüllen nach 8 Millisekunden, geht die Wiedergabe nahtlos weiter, solange noch etwas übrig ist; kann erst nach 12 Millisekunden nachgefüllt werden, sind die Daten in diesem vereinfachten Beispiel bei 10 Millisekunden aufgebraucht.

flowchart TB
    accTitle: Gleiche 10 Millisekunden Rest, anderes Ergebnis je nach Nachfüllzeitpunkt
    accDescr: Als Annahme zur Erklärung zeigt das Bild, dass bei 10 Millisekunden verbleibenden Wiedergabedaten ein Nachfüllen nach 8 Millisekunden rechtzeitig kommt, eines nach 12 Millisekunden aber erst, nachdem alles aufgebraucht ist.
    A["10 ms übrig"] --> B{"Nächstes Nachfüllen"}
    B -->|"nach 8 ms"| C["Läuft weiter"]
    B -->|"nach 12 ms"| D["Bei 10 ms leer"]

Abbildung 3: Ein Beispiel mit vereinfachter Zeitachse. Es kommt nicht nur darauf an, ob nachgefüllt wurde, sondern auch wann.

CPU-Auslastung und verspätetes Nachfüllen

Die CPU-Auslastung zeigt, wie beschäftigt die CPU über einen bestimmten Zeitraum war. Ob die Audioverarbeitung in dem Moment ausgeführt werden konnte, in dem sie es musste, ist etwas anderes. Selbst wenn die CPU während des größten Teils einer Sekunde Reserven hat, kann ein einziger Abschnitt von 12 Millisekunden, in dem nicht nachgefüllt werden kann, durch diese eine Verzögerung einen Aussetzer verursachen. Mit danach übrig gebliebener Rechenkapazität lässt sich ein bereits verstrichener Wiedergabezeitpunkt nicht zurückholen. CPU Analysis

flowchart TB
    accTitle: Durchschnittliche Reserve und eine einzige Nachfüllverspätung
    accDescr: Selbst wenn die CPU während des größten Teils einer Sekunde Reserven hat, kann ein einziger Abschnitt von 12 Millisekunden ohne Nachfüllen den Ton durch diese eine Verzögerung aussetzen lassen.
    A["CPU fast die ganze Sekunde frei"] --> B["Einmal 12 ms ohne Nachfüllen"]
    B --> C["Ton setzt dieses eine Mal aus"]

Abbildung 4: Auch mit Reserve im Durchschnitt lässt sich ein verstrichener Wiedergabezeitpunkt nicht zurückholen.

Was die Frist aufzehrt, ist nicht nur die Rechenzeit. Dazu gehören auch das Warten, bis die Verarbeitung beginnt, und das Warten, bis die benötigten Daten eintreffen. Deshalb ändert sich auch die Frage der Untersuchung: nicht nur „Wie viel Prozent hatte die CPU?“, sondern „Worauf wartete das nächste Audio in dem Moment, als der Ton abbrach?“

Warten auf Daten und Sperren

Angenommen, die Verarbeitung, die die Audiodaten vorbereitet, wartet auf den Abschluss eines Dateilesevorgangs. Dasselbe gilt, wenn sie auf eine Sperre wartet, die eine andere Verarbeitung in der App hält. Die wartende Verarbeitung selbst nutzt kaum CPU, doch auf der Geräteseite läuft die Wiedergabe weiter, und das verbleibende Audio schrumpft. Results for the Streaming Media Performance Assessment, CPU Analysis

flowchart TB
    accTitle: Auch während Wartezeiten ohne CPU-Nutzung läuft die Wiedergabe weiter
    accDescr: Während die Audioverarbeitung auf Daten oder eine Sperre wartet, nutzt sie keine CPU, doch die Wiedergabe läuft weiter und der Rest nimmt ab, und wenn sich das Nachfüllen verspätet, kann der Puffer leerlaufen.
    A["Audioverarbeitung wartet auf Daten"] --> B["Diese Verarbeitung nutzt keine CPU"]
    B --> C["Wiedergabe läuft derweil weiter"]
    C --> D["Spätes Nachfüllen: Puffer leer"]

Abbildung 5: Keine CPU zu nutzen ist nicht dasselbe, wie die nötige Arbeit erledigt zu haben.

DPCs, ISRs und der Audiothread

Eine ISR ist die Verarbeitung, die auf einen Interrupt eines Geräts reagiert. Ein DPC ist ein Mechanismus, der die restliche Arbeit auf später verschiebt, um die Interruptbehandlung kurz zu halten. Gewöhnliche DPCs werden vor gewöhnlichen Threads auf derselben logischen CPU ausgeführt, und solange gewöhnliche DPCs oder ISRs laufen, kann diese logische CPU keine gewöhnlichen Threads ausführen. Introduction to DPCs, CPU Analysis

Selbst wenn die CPU insgesamt Reserven hat, kann sich die Lieferung verzögern, wenn diese auf der CPU, die die Audioverarbeitung braucht, lange dauern oder gehäuft auftreten. Microsofts Material zur Leistungsanalyse von Audio und Video nennt auch lange DPCs/ISRs von Netzwerk-, Speicher-, Grafik- und anderen Treibern als mögliche Ursachen für Aussetzer. Es reicht nicht unbedingt, nur das Gerät zu untersuchen, das den Ton ausgibt. Results for the Streaming Media Performance Assessment

flowchart TB
    accTitle: Wenn die Reaktion auf Geräte die Audioausführung verzögert
    accDescr: Dauern gewöhnliche DPCs oder ISRs auf der CPU, die die Audioverarbeitung braucht, lange, verzögert sich die Ausführung des Threads, was die Nachfüllfrist beeinträchtigen kann.
    A["DPC/ISR auf derselben CPU"] -->|"wenn sie lange dauern"| B["Audioausführung muss warten"]
    B --> C["Nächstes Nachfüllen verspätet"]
    C --> D["Aussetzer, wenn der Rest ausgeht"]

Abbildung 6: Auch die Verarbeitung für andere Geräte als das tonausgebende kann das Nachfüllen des Audios indirekt beeinflussen.

Eine allgemeine Grenze der Art „Bleibt ein DPC unter so und so vielen Mikrosekunden, gibt es auf keinem PC Aussetzer“ lässt sich nicht ziehen. Die Warnwerte im Material zur Leistungsbewertung gelten für die dortigen Bewertungsbedingungen und werden hier nicht losgelöst von der tatsächlichen Nachfüllfrist und der Pufferreserve zum Sicherheitsmaßstab gemacht. Results for the Streaming Media Performance Assessment

Puffergröße und Wiedergabelatenz

Wer unter gleichen Bedingungen mehr Audio im Voraus puffert, kann vorübergehende Nachfüllverspätungen leichter auffangen, doch neu erzeugtes Audio wartet dann hinter dem bereits gepufferten. Eine Wartezeit, die beim bloßen Musikhören tragbar ist, fällt beim Spielen auf einem Keyboard oder beim Mithören der eigenen, bearbeiteten Mikrofonstimme als störender Versatz zwischen Aktion und Ton auf. Exclusive-Mode Streams, Low Latency Audio

flowchart TB
    accTitle: Pufferreserve und verzögerte Reaktion
    accDescr: Mehr Audio im Voraus zu puffern erleichtert das Auffangen vorübergehender Nachfüllverspätungen, erhöht aber auch die Wartezeit, bis neues Audio wiedergegeben wird.
    A["Mehr Audio vorab puffern"] --> B["Verspätungen leichter auffangen"]
    B -->|"im Gegenzug"| C["Neues Audio wartet dahinter"]
    C --> D["Aktion bis Ton dauert länger"]

Abbildung 7: Den Puffer zu vergrößern ist eine Abstimmung, die Reserve auf Kosten der Reaktionsschnelligkeit schafft.

Weder „je kleiner, desto leistungsfähiger“ noch „je größer, desto richtiger“ trifft zu. Behalten Sie die nötige Reaktionsschnelligkeit bei und sichern Sie zugleich genug Reserve gegen Aussetzer.

Den Puffer zu vergrößern schafft Reserve gegen vorübergehende Lieferverzögerungen. Kann die durchschnittliche Lieferung selbst nicht mit dem Verbrauch Schritt halten, verlängert ein größerer, aber endlicher Puffer nur die Zeit, bis er leer ist, und auch eine Trennung des Geräts wird damit nicht behoben. Ebenso wenig ist das eine Empfehlung, dass der exklusive Modus alles löst. Exclusive-Mode Streams

480 Frames Audio bei 48 kHz

Ein PCM-Frame ist die Einheit, die die Abtastwerte aller Kanäle zusammenfasst, die zum selben Zeitpunkt wiedergegeben werden. Dass es Stereo ist, heißt nicht, dass man die Frame-Anzahl verdoppelt, um die Zeit zu berechnen. Die Länge des Audios, die eine Frame-Anzahl darstellt, ergibt sich aus „Frame-Anzahl ÷ Abtastrate“, 480 Frames bei 48 kHz sind also 480 ÷ 48000 Sekunden, das heißt 10 Millisekunden. Erhöht man die Frame-Anzahl bei gleichbleibenden 48 kHz, wird auch die Zeit des Audios länger, das sich puffern lässt. Rendering a Stream

Diese Zeit ist nicht dasselbe wie die Gesamtlatenz vom Tastenanschlag bis zum hörbaren Ton, denn App, Treiber, Gerät sowie weitere Puffer und Verarbeitungsschritte benötigen ebenfalls Zeit. Lesen Sie auch die Einstellwerte einer DAW erst, nachdem Sie die Einheit und den betroffenen Puffer geprüft haben. Low Latency Audio

flowchart TB
    accTitle: Aus der Frame-Anzahl berechnete Zeit und Gesamtlatenz
    accDescr: Die 10 Millisekunden aus 480 Frames geteilt durch 48000 sind die Zeit, die der Puffer darstellt, und erst mit der Verarbeitung in App, Treiber, Gerät und anderswo ergibt sich die Gesamtlatenz von der Taste bis zum Ton.
    A["480 ÷ 48000"] --> B["10 ms, die der Puffer darstellt"]
    B -->|"weitere Verarbeitung kommt hinzu"| C["Gesamtlatenz von Taste bis Ton"]

Abbildung 8: Die aus der Frame-Anzahl berechnete Zeit ist nur ein Teil der Gesamtlatenz.

Reproduktionsbedingungen vergleichen

Grenzen Sie zuerst die Kombination ein, bei der das Problem auftritt, und gehen Sie nur bei Bedarf zur detaillierten Aufzeichnung über. Das Folgende ist ein Vorgehen, um die Ursache zu bestätigen, und keine Liste von Gegenmaßnahmen, bei der alle Einstellungsänderungen auf einmal durchgeführt werden.

Speichern Sie Ihre Arbeit, bringen Sie Live-Besprechungen und -Aufnahmen zu Ende und testen Sie dann bei einer Lautstärke, die Ihre Ohren nicht belastet. Notieren Sie das ursprüngliche Ausgabegerät, die Audioverbesserungen, Pufferwerte und Ähnliches, damit Sie alles wiederherstellen können. Überspringen Sie Punkte, für die keine Einstellung angeboten wird, und ändern Sie nicht die Registrierung oder Ähnliches, um eine Einstellung sichtbar zu machen.

1. Legen Sie eine kurze Audioquelle und eine Beobachtungsdauer fest, die Sie durchgehend beibehalten, und bestätigen Sie, dass das Problem unter den ursprünglichen Bedingungen auftritt.

   Notieren Sie die Windows-Version, Name und Version der App, das Ausgabegerät, die Verbindungsart und die Treiberversion. Halten Sie auch Uhrzeit, Bedienschritt und Anzahl der Aussetzer fest. Tritt das Problem unter den ursprünglichen Bedingungen nicht auf, werten Sie das nicht als Verbesserung, sondern ermitteln Sie zunächst wieder die Bedingungen, unter denen es auftritt.

2. Wählen Sie einen Vergleich aus der folgenden Tabelle und spielen Sie ab, wobei Sie nur diese Bedingung ändern.

   Zu vergleichende Bedingung	Was zu prüfen ist
   Lokal gespeicherte Audioquelle gegenüber Wiedergabe über das Netzwerk	Ob es nur über das Netzwerk auftritt. Unterscheiden sich bei gleichem Inhalt Format oder Verarbeitungspfad, auch das festhalten.
   Dieselbe Audioquelle in einer anderen App	Ob es sich auf eine bestimmte App konzentriert.
   Bluetooth- oder ähnliche Ausgabe gegenüber interner oder kabelgebundener Ausgabe	Ob es sich auf einen bestimmten Ausgabepfad konzentriert.
   Audioverbesserungen ein oder aus	Ob es sich in Kombination mit der Effektverarbeitung ändert.
   Aktueller Puffer in einer DAW o. Ä. gegenüber einer Stufe größer	Ob sich mit mehr im Voraus gepufferter Reserve etwas ändert. Ob auch die Verzögerung von der Aktion bis zum Ton noch akzeptabel ist.

3. Wenn Sie die Audioverbesserungen vergleichen, schalten Sie die Einstellung für die betreffende Ausgabe vorübergehend aus.

   Wählen Sie unter Windows in „Einstellungen“ → „System“ → „Sound“ die betreffende Ausgabe aus und schalten Sie, sofern verfügbar, die „Audioverbesserungen“ aus. Weichen die Anzeige oder die vorhandenen Optionen ab, prüfen Sie die Hinweise für die jeweilige Version und das jeweilige Gerät. Fix distorted or crackling audio in Windows

4. Setzen Sie die geänderte Einstellung zurück und testen Sie erneut mit derselben Audioquelle und derselben Beobachtungsdauer.

   Stellen Sie die Ergebnisse für „ursprüngliche Bedingung“, „eine Bedingung geändert“ und „zurückgesetzt“ nebeneinander. Setzen Sie wirkungslose Änderungen auf den ursprünglichen Zustand zurück, bevor Sie zum nächsten Vergleich übergehen. Wer die Kombination von Einstellungen immer weiter ändert, weiß am Ende nicht mehr, was gewirkt hat.

5. Wenn Sie einen Treiberwechsel ausprobieren, prüfen Sie vorher die offizielle Bezugsquelle und den Weg zur Wiederherstellung.

   Nutzen Sie Windows Update oder die offizielle Bereitstellung des Geräteherstellers und notieren Sie Version und Einstellungen vor und nach der Änderung. Prüfen Sie vorab, ob Sie zum alten Stand zurückkehren können, und sprechen Sie sich auf verwalteten PCs mit dem Administrator ab. Werten Sie es nicht als gelöst, nur weil die Wiedergabe direkt nach dem Update einmal funktioniert hat, sondern prüfen Sie unter denselben Reproduktionsbedingungen. Fix distorted or crackling audio in Windows

Das angestrebte Ergebnis ist ein Protokoll, das Symptom und Bedingungen einander zuordnet, etwa „tritt in dieser App bei Verwendung dieser Ausgabe auf“. Auch wenn Sie eine Einstellung finden, die eine Verbesserung bringt, trennen Sie das von der Feststellung der Ursache.

flowchart TB
    accTitle: Vergleich durch Ändern und Zurücksetzen einer Bedingung
    accDescr: Mit derselben Audioquelle wird die Reproduktion bestätigt, eine Bedingung wie App oder Ausgabe geändert und auch das Ergebnis nach dem Zurücksetzen festgehalten.
    A["Ursprüngliche Kombination abspielen"] --> B["Mit einer Änderung abspielen"]
    B --> C["Zurückgesetzt abspielen"]
    C --> D["Bedingung und Zeit der Aussetzer notieren"]

Abbildung 9: Wichtiger als eine einmalige Besserung ist die Bestätigung, dass Bedingung und Symptom wiederholt zusammenpassen.

Reproduzierbarkeit vor und nach einer Änderung

„Das Symptom wurde unterdrückt“, „die Bedingungen wurden eingegrenzt“ und „die Grundursache wurde ermittelt“ sind unterschiedliche Etappen. Halten Sie Ihr Fazit passend zu dem Umfang fest, den Sie beobachten konnten.

flowchart TB
    accTitle: Drei Ergebnisse, die auf einen Zusammenhang mit einer Bedingung hindeuten
    accDescr: Tritt das Problem unter den ursprünglichen Bedingungen auf, bessert sich nach Änderung einer Bedingung und tritt nach dem Zurücksetzen wieder auf, ist das ein Hinweis auf einen Zusammenhang mit dieser Bedingung, der aber von der Feststellung der Ursache getrennt wird.
    A["Tritt wie ursprünglich auf"] --> B["Besser mit einer Änderung"]
    B --> C["Tritt nach Zurücksetzen auf"]
    C --> D["Hinweis auf Zusammenhang"]

Abbildung 10: Selbst wenn alle drei zutreffen, reicht die Erkenntnis nur bis zu einem Hinweis auf einen Zusammenhang.

Eine niedrige CPU-Auslastung ist kein Beleg dafür, dass die Audiofrist eingehalten wurde. Zugleich lässt sich allein daraus, dass ein Aussetzer auftrat, nicht schließen, dass ein verspätetes Nachfüllen die Grundursache war. Vergleichen Sie Audioquelle, App-Verarbeitung, Effekte, Ausgabepfad und Ähnliches, und urteilen Sie im Rahmen dessen, was Sie beobachtet haben. Fix distorted or crackling audio in Windows

Wenn Sie eine vorläufige Umgehungslösung übernehmen, halten Sie die ursprünglichen Einstellungen, die Änderung, die Beobachtungsdauer, ob das Problem erneut auftrat, und die tolerierbare Latenz fest. Ist die Grundursache nicht geklärt, vermerken Sie auch das.

Aussetzer mit WPR aufzeichnen

Dieser Schritt ist angezeigt, wenn sich das Problem durch den Vergleich von Bedingungen allein nicht eingrenzen lässt oder wenn Sie die Verarbeitung auf Treiberseite untersuchen. WPR ist das Werkzeug zum Aufzeichnen, WPA das Werkzeug zur Analyse der gespeicherten Zeitachse. Halten Sie das Windows Performance Toolkit, die für die Aufzeichnung nötigen Berechtigungen und einen Speicherort für die ETL-Datei bereit. Wenn auf einem verwalteten PC die Werkzeuge installiert und Aufzeichnungen erstellt werden sollen, wenden Sie sich an den Administrator. Prüfen Sie Anzeigenamen und verfügbare Profile in der installierten Version. Windows Performance Recorder

ETL-Dateien können Prozessnamen, Dateipfade und Ähnliches enthalten. Prüfen Sie vor der Aufzeichnung die internen Regeln Ihres Unternehmens und mit wem die Datei geteilt wird, und hängen Sie sie nicht unverändert an öffentlichen Orten an. Läuft bereits eine andere Aufzeichnungssitzung, beenden Sie sie nicht eigenmächtig, sondern fragen Sie bei der zuständigen Person nach. WPR How-to Topics

1. Öffnen Sie in WPR „More Options“ und wählen Sie ein Aufzeichnungsprofil, das zu Ihrem Zweck passt.

   Zu den integrierten Profilen gehören „Audio glitches“ und „CPU usage“. Wählen Sie Einstellungen, mit denen sich Unterbrechungen im Audio und die CPU-Aktivität untersuchen lassen. Prüfen Sie verfügbare Profile, Anzeigenamen und erfasste Inhalte in der installierten Version, und richten Sie keine Aufzeichnung aller Arten über lange Zeit ein. Built-in Recording Profiles

2. Starten Sie die Aufzeichnung, bevor Sie den Aussetzer reproduzieren.

   Erscheint eine Rückfrage, ob eine bestehende Aufzeichnung beendet werden soll, fahren Sie nicht fort, sondern brechen Sie den Start ab und fragen Sie bei der zuständigen Person nach. Halten Sie die Bedingungen gleich wie ohne Aufzeichnung, und rechnen Sie mit der Möglichkeit, dass die Last der Aufzeichnung selbst das Symptom verändert. WPR How-to Topics

3. Spielen Sie unter den im Vergleich gefundenen Bedingungen ab und notieren Sie Uhrzeit und Bedienschritt des Aussetzers.

   Nehmen Sie vor und nach dem Symptom auch etwas problemfreie Zeit mit auf. Vermerken Sie bei einer Aufzeichnung, in der das Problem nicht auftrat, diese Tatsache deutlich, und behandeln Sie sie nicht als Aufzeichnung, die die Ursache erfasst hat.

4. Beenden Sie die Aufzeichnung nach der Reproduktion mit „Save“ und speichern Sie die ETL-Datei.

   Mit „Cancel“ wird nichts gespeichert. Notieren Sie Speicherort, Reproduktionsbedingungen, ob aufgezeichnet wurde und ob eine Warnung über verlorene Ereignisse erschien. Werten Sie in einer Aufzeichnung mit verlorenen Ereignissen die nicht sichtbaren Abschnitte nicht als normal. WPR How-to Topics

Liegen die ETL-Datei und Notizen zu Uhrzeit, Bedienschritt und Bedingungen des Aussetzers vor, sind Sie bereit für den Abgleich in WPA. Dass eine Aufzeichnung gespeichert wurde, heißt allein noch nicht, dass die nötigen Ereignisse erfasst wurden. Prüfen Sie den Inhalt im nächsten Abschnitt, „Ausführung und Warten rund um einen Aussetzer“.

flowchart TB
    accTitle: Eine kurze Aufzeichnung mit einem Aussetzer erstellen
    accDescr: In WPR die Aufzeichnung starten, das Symptom reproduzieren und die Uhrzeit notieren, dann beenden und speichern und die Aufzeichnung in WPA untersuchen.
    A["Aufzeichnung in WPR starten"] --> B["Unter gleichen Bedingungen reproduzieren"]
    B --> C["Zeit und Aktion notieren, speichern"]
    C --> D["Umfeld in WPA vergrößern"]

Abbildung 11: Die CPU-Auslastung erst nach dem Ende des Symptoms anzusehen reicht nicht, Sie brauchen eine Aufzeichnung des Abschnitts, in dem das Symptom auftrat.

Ausführung und Warten rund um einen Aussetzer

Halten Sie die gespeicherte ETL-Datei und die Notizen zum Reproduktionszeitpunkt bereit. Das Folgende ist ein Ausgangspunkt für die Untersuchung in WPA. Wird eine detaillierte Analyse mit Stacks und Symbolen nötig, gehen Sie sorgsam mit der Aufzeichnung um und wenden Sie sich an Administratoren oder Entwickler.

1. Öffnen Sie die ETL-Datei in WPA und vergrößern Sie anhand der erfassten Audioereignisse und des Reproduktionszeitpunkts den Bereich vor und nach dem Aussetzer.

   Behalten Sie zum Vergleich auch einen Abschnitt ohne Symptom. Schauen Sie nicht nur auf Ranglisten der Höchstwerte, sondern vergleichen Sie über denselben Zeitbereich.

2. Prüfen Sie im selben Bereich „DPC/ISR“ und „CPU Usage (Precise)“.

   Fehlen die nötigen Daten, prüfen Sie, ob das Profil sie erfassen kann, und kehren Sie zur Aufzeichnung mit WPR zurück. Dass nichts aufgezeichnet ist, ist nicht dasselbe, wie dass kein Problem vorlag. CPU Analysis, Built-in Recording Profiles

3. Unterscheiden Sie, ob der audiobezogene Thread zwar ausführbar war, aber darauf wartete, an die Reihe zu kommen, oder ob er auf Daten oder Ähnliches wartete.

   Im ersten Fall gleichen Sie ab, ob auf der betreffenden logischen CPU DPCs/ISRs oder Ähnliches lange liefen. Im zweiten Fall verfolgen Sie anhand der erfassten Ereignisse und Stacks, was das Warten beendet hat. Da ein laufender Thread auch durch einen Interrupt unterbrochen werden kann, beschränken Sie sich nicht auf die Ready-Zeit, sondern legen Sie auch die DPC-/ISR-Abschnitte darüber. CPU Analysis

4. Halten Sie die zeitliche Zuordnung zum Aussetzer, die betroffene CPU und die Ergebnisse geänderter Bedingungen gemeinsam fest.

   Legen Sie sich nicht allein anhand des Modulnamens eines langen DPC/ISR auf ein bestimmtes Gerät oder einen bestimmten Treiber als Ursache fest. Möglicherweise sehen Sie einen großen Wert zu einem anderen Zeitpunkt oder eine gemeinsame Komponente, die mehrere Geräte durchlaufen.

flowchart TB
    accTitle: Untersuchen, wie im Bereich des Aussetzers gewartet wurde
    accDescr: Den Bereich um den Aussetzer vergrößern und den Zustand des Audiothreads ansehen. Wartete er ausführbar darauf, an die Reihe zu kommen, mit DPCs und ISRs auf derselben CPU abgleichen, wartete er auf Daten oder Ähnliches, die Verarbeitung verfolgen, die das Warten beendet hat.
    A["Bereich um Aussetzer vergrößern"] --> B{"Thread-Zustand"}
    B -->|"wartet, bis er dran ist"| C["DPC/ISR"]
    B -->|"wartet auf Daten"| D["Was das Warten beendete"]

Abbildung 12: Greifen Sie nicht nur die Höchstwerte heraus, sondern lesen Sie sie überlagert mit dem Abschnitt, in dem die Audioverarbeitung gebraucht wurde.

Lässt sich die Ursache nicht ermitteln, übergeben Sie die Untersuchung als ungeklärt. Fügen Sie die Versionen von Betriebssystem, App, Gerät und Treiber bei, außerdem die Reproduktionsschritte, die Ergebnisse vor und nach Änderungen, den Zeitpunkt des Auftretens, das Erfassungsprofil und die Angabe, ob eine Warnung über verlorene Ereignisse erschien. Teilen Sie die ETL-Datei gemäß den internen Regeln nur mit den Personen, die die Untersuchung übernehmen.

Vorauslesen in Audioanwendungen

Wenn Sie selbst eine Audioanwendung entwickeln, entwerfen Sie sie so, dass die Verarbeitung, die den nächsten Puffer füllt, jedes Mal ihre Frist einhält. WASAPI bietet eine Möglichkeit, den Zeitpunkt, zu dem ein Puffer verarbeitet werden kann, als Ereignis zu empfangen. Exclusive-Mode Streams

MMCSS ist ein Mechanismus, der Threads zeitkritischer Multimediaverarbeitung CPU-Ressourcen zuteilt. Funktionen, um Daten vorab von der Festplatte bereitzustellen oder Wartezeiten auf Sperren zu beseitigen, hat er nicht. Auch wenn Sie die Zuteilung durch MMCSS nutzen, brauchen Sie zusätzlich einen Entwurf, der die Datenbereitstellung regelt und Wartezeiten verringert. Multimedia Class Scheduler Service

flowchart TB
    accTitle: Wofür MMCSS zuständig ist
    accDescr: MMCSS teilt den Threads zeitkritischer Verarbeitung CPU-Ressourcen zu, die Datenbereitstellung und die Verringerung von Wartezeiten auf Sperren erfolgen aber durch einen separaten Entwurf.
    M["MMCSS: teilt CPU-Ressourcen zu"] -.->|"zusätzlich nötig"| D["Daten bereitstellen, Warten verringern"]

Abbildung 13: CPU-Ressourcen zuzuteilen und dafür zu sorgen, dass die Daten rechtzeitig bereitstehen, sind verschiedene Aufgaben.

Der Leitgedanke des Entwurfs ist, die Verarbeitung, die aus Dateien oder dem Netzwerk liest, von der Verarbeitung zu trennen, die Audio übergibt. Vorbereitungen, deren Dauer schwer abzuschätzen ist, erledigen Sie im Voraus, und für die Übergabe verwenden Sie vorab reservierte Puffer. Gestalten Sie die Audioseite so, dass sie nicht auf Antworten der Benutzeroberfläche, lange Sperren oder synchrones Schreiben von Protokollen warten muss.

flowchart TB
    accTitle: Schwer abschätzbare Vorbereitung und Audiolieferung trennen
    accDescr: Ein Entwurf, der Lesevorgänge und Ähnliches in einer vorgelagerten Verarbeitung erledigt und die vorbereiteten Daten über einen Puffer an die Audioverarbeitung übergibt, um lange Wartezeiten kurz vor der Frist zu verringern.
    A["Daten vorab vorbereiten"] --> B["Vorab reservierter Übergabebereich"]
    B --> C["Audioverarbeitung übergibt Nötiges"]
    C --> D["Lieferung an die Audioausgabe"]

Abbildung 14: Zeitaufwendige Arbeit wird aus dem Moment unmittelbar vor der Audioübergabe herausgenommen.

Steht die vorbereitende Seite lange still, geht der Vorrat auch bei dieser Trennung aus. Erfassen Sie nicht nur die durchschnittliche Verarbeitungszeit, sondern auch die Fälle, in denen lange Verarbeitung oder Wartezeiten auftraten, und wie oft nicht geliefert werden konnte, und zwar mit einer Methode, die die Audioverarbeitung nicht stört. 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 die angegebenen Werte unverändert übernommen wurden. Rendering a Stream, Low Latency Audio

Sowohl die Zahlenbeispiele als auch die Entwurfsbeispiele dienen der Erklärung. Sie sind weder empfohlene Einstellwerte für bestimmte Geräte noch eine Garantie dafür, dass in beliebigen Umgebungen keine Aussetzer auftreten.

Auswirkung der Echtzeitpriorität

Dass Anwender den gesamten Player auf die Priorität „Echtzeit“ setzen, empfehlen wir nicht pauschal. Das birgt die Gefahr, andere wichtige Verarbeitung zu behindern, und eine höhere Priorität gewöhnlicher Threads beseitigt weder DPCs/ISRs noch Wartezeiten auf Daten und Sperren. In der Entwicklung nutzen Sie Mechanismen wie MMCSS und einen Entwurf, der keine langen Wartezeiten in die Audiolieferung hineinträgt. Scheduling Priorities, CPU Analysis

flowchart TB
    accTitle: Wartezeiten, die auch mit Echtzeitpriorität bleiben
    accDescr: Auch wenn der Player auf Echtzeitpriorität gesetzt wird, können gewöhnliche Threads DPCs und ISRs auf derselben CPU nicht überholen, Wartezeiten auf Daten und Sperren bleiben bestehen, und es besteht zudem die Gefahr, andere wichtige Verarbeitung zu behindern.
    A["Player auf Echtzeitpriorität"] --> B["DPC/ISR nicht überholbar"]
    B --> C["Daten- und Sperrwartezeiten bleiben"]
    C --> D["Gefahr für andere Verarbeitung"]

Abbildung 15: Auch mit höherer Priorität bleiben die Wartezeiten bestehen, die das Nachfüllen des Audios verzögern.

Verwandte Artikel

• Die Windows-Einstellung „Prozessorzeitplanung“ und Hintergrunddienste
• Einen Windows-Datenträger bei 100 % sicher eingrenzen
• Warum ist RDP über eine schnelle Verbindung träge?

Quellen

• Microsoft Learn, Rendering a Stream. Belieferung des Wiedergabepuffers, Restmenge, tatsächliche Puffergröße und Definition eines PCM-Frames.
• Microsoft Learn, Exclusive-Mode Streams. Zeitpunkt der Pufferbelieferung und Audiostörungen, Abwägung gegen die Latenz und ereignisgesteuerte Belieferung. Dies ist keine pauschale Empfehlung des exklusiven Modus selbst.
• Microsoft Learn, Low Latency Audio. Der Audiopfad von Windows, Puffer, Geräte und Effektverarbeitung im Verhältnis zur Latenz sowie die Zielkonflikte niedriger Latenz.
• Microsoft Learn, CPU Analysis. Logische CPUs, die Thread-Zustände Ready/Waiting, das Verhältnis von DPC/ISR und Thread-Ausführung sowie die CPU-Analyse in WPA.
• Microsoft Learn, Introduction to DPCs. Der Mechanismus, der die Interruptbehandlung kurz hält und die restliche Arbeit an einen DPC abgibt.
• Microsoft Learn, Results for the Streaming Media Performance Assessment. Lange und häufige DPCs/ISRs, unzureichende Datenlieferung und Audiostörungen. Die Warnwerte der Bewertung werden nicht zu einem Sicherheitsmaßstab für alle Geräte verallgemeinert.
• Microsoft Support, Fix distorted or crackling audio in Windows. Prüfung von Audioverbesserungen, Formaten, Treibern und Ähnlichem.
• Microsoft Learn, Windows Performance Recorder. ETW-Aufzeichnung, Analyse mit WPA und Verwendung des Windows Performance Toolkit.
• Microsoft Learn, Built-in Recording Profiles. More Options in WPR und integrierte Profile wie Audio glitches und CPU usage.
• Microsoft Learn, WPR How-to Topics. Starten einer Aufzeichnung und Speichern mit Save, Konflikte mit bestehenden Sitzungen sowie Hinweise zu personenbezogenen Daten und verlorenen Ereignissen.
• Microsoft Learn, Multimedia Class Scheduler Service. Zuteilung von CPU-Ressourcen an zeitkritische Multimediaverarbeitung.
• Microsoft Learn, Scheduling Priorities. Prozess- und Thread-Prioritäten sowie Hinweise zur Echtzeitpriorität.

Verwandte Artikel

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

Verwandte Themen

Dies sind Themenseiten, die zu diesem Thema passen. Ausgehend vom Artikel gelangen Sie zu verwandten Leistungen und weiteren Artikeln.

Leistungen zu diesem Thema

Dieser Artikel führt zu den folgenden Leistungsseiten. Beginnen Sie gern mit einem Einstieg, der Ihrem Anliegen nahekommt.

Häufige Fragen

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

Warum setzt der Ton aus, obwohl die CPU-Auslastung nur bei etwa 10 % liegt?

Bei Audio gilt eine Frist, bis zu der die nächsten Daten nachgefüllt sein müssen, nämlich bevor die gerade wiedergegebenen aufgebraucht sind. Selbst bei insgesamt niedriger CPU-Auslastung kann das Nachfüllen zu spät kommen, wenn die Audioverarbeitung in diesem Moment nicht ausgeführt werden konnte oder auf benötigte Daten wartete. Nicht jeder Aussetzer hat diese Ursache, deshalb sind auch Vergleiche mit einem anderen Ausgabegerät oder einer anderen App nötig.

Behebt ein größerer Audiopuffer die Aussetzer?

Wenn sich das Nachfüllen vorübergehend verspätet, kann ein größerer Puffer das mitunter auffangen. Allerdings wächst auch die Wartezeit, bis das gepufferte Audio wiedergegeben wird. Einen dauerhaften Mangel an Verarbeitungskapazität oder eine Trennung des Geräts behebt diese Einstellung nicht. Notieren Sie bei Apps und Treibern, in denen sich der Wert ändern lässt, den ursprünglichen Wert und vergleichen Sie Stufe für Stufe.

Wie viele Millisekunden Audio sind 480 Frames bei 48 kHz?

Es sind 480 ÷ 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 App.

Ist ein Treiber mit langen DPC- oder ISR-Ausführungszeiten der Schuldige an den Aussetzern?

Er kommt als Kandidat infrage, aber allein anhand einer Rangfolge der Ausführungszeiten lässt sich das nicht feststellen. Gleichen Sie den Zeitraum, in dem der Aussetzer auftrat, mit den Wartezeiten des Audiothreads und der DPC-/ISR-Ausführung auf derselben CPU ab. Schließen Sie nicht allein aus dem Modulnamen auf einen Defekt eines bestimmten Geräts oder Treibers, und prüfen Sie auch die Ergebnisse geänderter Reproduktionsbedingungen.

Hilft es, den Player auf Echtzeitpriorität zu setzen?

Das empfehlen wir nicht pauschal. Auch wenn die Priorität eines gewöhnlichen Threads angehoben wird, kann er gewöhnliche DPCs und ISRs auf derselben CPU nicht überholen, und Wartezeiten auf Daten oder Sperren verschwinden ebenfalls nicht. Entwickler nutzen Mechanismen wie MMCSS und einen Entwurf, der keine Wartezeiten einschleppt, und Anwender vergleichen zuerst die Reproduktionsbedingungen und die Ausgabepfade.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Vertretungsberechtigter von KomuraSoft LLC

Schwerpunkte sind Windows-Softwareentwicklung, technische Beratung und Fehleruntersuchung. Besondere Stärken liegen bei Projekten mit bestehenden Assets und bei der Untersuchung von Störungen, deren Ursache schwer erkennbar ist.