Dlaczego dźwięk się przerywa, choć użycie CPU jest niskie? – bufor i terminy uzupełniania

Podczas słuchania muzyki dźwięk co jakiś czas urywa się z krótkim „pyk”. Menedżer zadań pokazuje użycie CPU na poziomie około 10%, a mimo to niestabilny jest tylko dźwięk. Dlaczego w takiej sytuacji dźwięk się przerywa, skoro CPU ma zapas mocy?

Nawet przy niskim użyciu CPU dźwięk może się przerwać, jeśli kolejne dane audio nie zostaną uzupełnione przed terminem. Następne dane trzeba bowiem przekazać w czasie, gdy odtwarzany jest dźwięk pozostały w buforze. Opóźnienia uzupełniania spowodowane oczekiwaniem na dane lub blokady albo DPC/ISR na potrzebnym procesorze logicznym zdarzają się nawet wtedy, gdy całe CPU nie jest w pełni wykorzystane. Exclusive-Mode Streams, CPU Analysis

Samo usłyszane „pyk” nie pozwala jednak stwierdzić, że chodzi o underrun. Podobne objawy powodują także nagranie, aplikacja, efekty dźwiękowe, urządzenie wyjściowe i inne czynniki. Najpierw na tym samym nagraniu porównuje się wyniki, zmieniając warunki pojedynczo i przywracając je, a jeśli to nie zawęzi przyczyny, rejestruje się przebieg przed przerwą w dźwięku i po niej. Fix distorted or crackling audio in Windows

Ten artykuł omawia to pytanie oraz kolejne, które z niego wynikają: „czy wystarczy zwiększyć bufor?” i „co porównać i co zarejestrować, aby zawęzić przyczynę?”. Nie ustala on przyczyny konkretnej awarii na podstawie samego użycia CPU ani usłyszanego dźwięku.

Artykuł dotyczy głównie wyjścia audio w Windows 11. Porównujemy wyjścia wbudowane, przewodowe, USB, Bluetooth i inne, a w przypadku oprogramowania do produkcji muzyki (DAW) omawiamy też porównania, gdy aplikacja lub sterownik udostępnia ustawienia bufora. Artykuł nie obejmuje w całości projektowania toru nagrywania ani diagnostyki łączności bezprzewodowej poszczególnych urządzeń.

Jako podstawowy przykład w wyjaśnieniach służy tryb współdzielony. Rzeczywista ścieżka, rozmiar bufora i okres przetwarzania zależą od aplikacji, API, sterownika i urządzenia; nie istnieje też ekran ustawień bufora wspólny dla wszystkich aplikacji. Low Latency Audio

Podane tu użycie CPU, pozostałe 10 ms, momenty uzupełnienia i podobne wartości to założenia przyjęte na potrzeby wyjaśnienia. Nie jest to raport z pomiarów odtworzenia problemu ani poprawy na konkretnym komputerze. Czynności opisane w dalszej części to procedury sprawdzające, które wykonuje się we własnym środowisku.

Mechanizm można poznawać po kolei, zaczynając od następnej sekcji „Bufor odtwarzania dźwięku”. Czynności służące diagnozowaniu przerw w dźwięku opisano w sekcjach „Porównanie warunków odtworzenia problemu” i „Rejestrowanie przerw w dźwięku w WPR”.

Na diagramie linia ciągła oznacza relację, która zachodzi zawsze, a linia przerywana relację warunkową (warunki podano przy każdej relacji na stronie szczegółów). Pełną listę relacji (łącznie 5, wraz z uzasadnieniem i pewnością) oraz definicje głównych pojęć zebrano na stronie szczegółów mapy wiedzy (w języku japońskim). Dane: JSON-LD / Turtle

Bufor odtwarzania dźwięku

Samo zapisanie pliku muzycznego nie sprawi, że głośnik zagra. Aplikacja przygotowuje dane audio i dostarcza je do urządzenia wyjściowego przez system Windows i sterownik. Bufor odtwarzania dźwięku to obszar, w którym tymczasowo gromadzi się dane przeznaczone do odtworzenia w najbliższej chwili. Gdy urządzenie odtwarza bieżące dane, strona dostarczająca przygotowuje kolejne i uzupełnia nimi bufor. Rendering a Stream

flowchart TB
    accTitle: Gromadzenie dźwięku z wyprzedzeniem przed odtworzeniem
    accDescr: Przygotowane dane audio trafiają do bufora, a w trakcie odtwarzania po stronie urządzenia przygotowywane są kolejne dane.
    A["Przygotuj kolejny dźwięk"] --> B["Uzupełnij bufor"]
    B --> C["Odtwórz zgromadzony dźwięk"]
    C -.->|"przed wyczerpaniem"| A

Rys. 1: Aby odtwarzanie trwało, uzupełnianie musi nadążać za stroną, która zużywa dźwięk.

Rys. 1 to schemat koncepcyjny, który pokazuje wyłącznie relację między uzupełnianiem a zużywaniem. Nie przedstawia wielu buforów na rzeczywistej ścieżce audio jako jednego fizycznego obszaru. Low Latency Audio

Zadaniem bufora jest zamortyzowanie krótkich przesunięć czasowych między stroną, która przygotowuje dźwięk, a stroną, która go zużywa, tak aby odtwarzanie było ciągłe. Pojemność bufora to jednak coś innego niż ilość nieodtworzonych danych, które w danej chwili się w nim znajdują. To, że bufor „ma pojemność 10 ms”, nie oznacza, że zawsze zostaje w nim 10 ms dźwięku. Rendering a Stream

Ograniczenie czasowe, zgodnie z którym potrzebne kolejne dane trzeba dostarczyć, zanim odtwarzane dane się wyczerpią, nazywamy tu terminem uzupełnienia. Przetwarzanie dźwięku wymaga, by dane „były gotowe przed chwilą odtworzenia”. Samo „w końcu udało się to obliczyć” nie wystarcza. Stan, w którym dostawa nie zdąży i zabraknie danych do odtworzenia, to underrun (niedopełnienie bufora), który prowadzi do przerw w dźwięku i trzasków. Nawet jeśli dane dotrą z opóźnieniem, przerwy, która już była słyszalna, nie da się później wypełnić. Exclusive-Mode Streams

Ścieżka danych audio

W zwykłym trybie współdzielonym dane przygotowane przez aplikację odtwarzającą odbiera silnik audio systemu Windows, który miksuje wiele dźwięków i nakłada efekty, a następnie przekazuje je do sterownika i urządzenia wyjściowego. Aplikacja odtwarzająca uczestniczy zarówno we wczytywaniu nagrania, jak i w dostarczaniu danych do miejsca docelowego, a sterownik i urządzenie wyjściowe przenoszą dane na stronę urządzenia i je odtwarzają. Low Latency Audio

flowchart TB
    accTitle: Ścieżka danych audio w trybie współdzielonym
    accDescr: Silnik audio miksuje dane przygotowane przez aplikację odtwarzającą, nakłada efekty i przekazuje je do sterownika, a urządzenie wyjściowe je odtwarza.
    A["Aplikacja: przygotowanie danych"] --> E["Silnik audio: miks i efekty"]
    E --> D["Sterownik: transport do urządzenia"]
    D --> O["Urządzenie wyjściowe: odtwarzanie"]

Rys. 2: Przykład trybu współdzielonego. Pośrednie przetwarzanie i bufory zależą od API i urządzenia.

Przetwarzanie i bufory mogą znajdować się także po stronie urządzenia, więc całkowite opóźnienie nie zależy wyłącznie od bufora po stronie aplikacji. Ten opis zakłada ścieżkę trybu współdzielonego i nie oznacza, że we wszystkich API dane przechodzą przez to samo przetwarzanie. Low Latency Audio

Uzupełnianie przy 10 ms zapasu

Załóżmy, że w buforze zostało jeszcze 10 ms nieodtworzonych danych. Jeśli kolejne uzupełnienie nastąpi po 8 ms, dźwięk będzie ciągły, bo dane jeszcze zostały; jeśli jednak bufora nie da się uzupełnić przez 12 ms, w tym uproszczonym przykładzie dane wyczerpią się po 10 ms.

flowchart TB
    accTitle: Przy tych samych 10 ms zapasu wynik zależy od chwili uzupełnienia
    accDescr: Przy przyjętym dla wyjaśnienia założeniu, że zostało 10 ms danych do odtworzenia, uzupełnienie po 8 ms zdąży na czas, a uzupełnienie po 12 ms nastąpi już po ich wyczerpaniu.
    A["Zostało 10 ms"] --> B{"Następne uzupełnienie"}
    B -->|"po 8 ms"| C["Dźwięk ciągły"]
    B -->|"po 12 ms"| D["Koniec danych po 10 ms"]

Rys. 3: Przykład z uproszczonym czasem. Ważne jest nie tylko to, czy bufor uzupełniono, lecz także kiedy.

Użycie CPU a opóźnione uzupełnianie

Użycie CPU pokazuje, jak bardzo procesor był zajęty w określonym przedziale czasu. To inna rzecz niż to, czy przetwarzanie dźwięku mogło się wykonać w chwili, gdy było potrzebne. Nawet jeśli przez większą część sekundy CPU ma zapas mocy, wystarczy jeden odcinek 12 ms bez możliwości uzupełnienia, by to jedno opóźnienie mogło przerwać dźwięk. Zapas mocy obliczeniowej, który zostaje później, nie odzyska minionej chwili odtwarzania. CPU Analysis

flowchart TB
    accTitle: Średni zapas mocy a jedno opóźnione uzupełnienie
    accDescr: Nawet jeśli przez większą część sekundy CPU ma zapas mocy, jeden odcinek 12 ms bez uzupełnienia może przerwać dźwięk.
    A["CPU wolne przez większość sekundy"] --> B["Raz brak uzupełnienia przez 12 ms"]
    B --> C["To jedno wystarcza do przerwy"]

Rys. 4: Nawet średni zapas mocy nie odzyska minionej chwili odtwarzania.

Zapas czasu do terminu zmniejsza nie tylko czas obliczeń. Liczy się także oczekiwanie na rozpoczęcie przetwarzania i oczekiwanie na dostarczenie potrzebnych danych. Dlatego pytanie w diagnostyce zmienia się z samego „ile procent wynosiło użycie CPU?” na „na co czekał kolejny fragment dźwięku w chwili, gdy dźwięk się urwał?”.

Oczekiwanie na dane i blokady

Załóżmy, że kod przygotowujący dane audio czeka na zakończenie odczytu pliku. Tak samo jest, gdy czeka na blokadę trzymaną przez inną część aplikacji. Sam oczekujący kod prawie nie używa CPU, ale po stronie urządzenia odtwarzanie trwa, a pozostałego dźwięku ubywa. Results for the Streaming Media Performance Assessment, CPU Analysis

flowchart TB
    accTitle: Odtwarzanie trwa także podczas oczekiwania bez użycia CPU
    accDescr: Gdy przetwarzanie dźwięku czeka na dane lub blokadę, nie używa CPU, ale odtwarzanie postępuje, zapas maleje, a przy opóźnionym uzupełnieniu bufor może się wyczerpać.
    A["Przetwarzanie audio czeka na dane"] --> B["Ten kod nie używa CPU"]
    B --> C["Odtwarzanie wciąż trwa"]
    C --> D["Spóźnione uzupełnienie: brak zapasu"]

Rys. 5: To, że CPU nie jest używane, i to, że potrzebna praca została wykonana, to dwie różne rzeczy.

DPC, ISR a wątek audio

ISR to procedura obsługująca przerwanie od urządzenia. DPC to mechanizm, który odkłada pozostałą pracę na później, aby obsługa przerwania była krótka. Zwykłe DPC wykonują się przed zwykłymi wątkami na tym samym procesorze logicznym, a gdy działają zwykłe DPC lub ISR, ten procesor logiczny nie może wykonywać zwykłych wątków. Introduction to DPCs, CPU Analysis

Nawet jeśli całe CPU ma zapas mocy, dostawa danych może się opóźnić, gdy na procesorze potrzebnym do przetwarzania dźwięku te procedury trwają długo lub występują często. W materiałach Microsoftu dotyczących analizy wydajności audio i wideo jako możliwe przyczyny przerw w dźwięku wymienia się także długie DPC/ISR sterowników sieciowych, pamięci masowej, grafiki i innych. Nie zawsze wystarczy sprawdzić samo urządzenie, które wydaje dźwięk. Results for the Streaming Media Performance Assessment

flowchart TB
    accTitle: Gdy obsługa urządzeń opóźnia wykonanie audio
    accDescr: Gdy zwykłe DPC lub ISR trwają długo na procesorze potrzebnym do przetwarzania dźwięku, wykonanie wątku się opóźnia, co może wpłynąć na termin uzupełnienia.
    A["DPC i ISR na tym samym CPU"] -->|"gdy trwają długo"| B["Wykonanie audio musi czekać"]
    B --> C["Uzupełnienie się opóźnia"]
    C --> D["Koniec zapasu: przerwa"]

Rys. 6: Przetwarzanie niezwiązane z urządzeniem wydającym dźwięk także może pośrednio wpływać na uzupełnianie danych audio.

Nie da się wyznaczyć wspólnej granicy w rodzaju „jeśli DPC trwa nie dłużej niż tyle a tyle mikrosekund, to na żadnym komputerze nie będzie przerw w dźwięku”. Progi ostrzegawcze w materiałach o ocenie wydajności obowiązują w warunkach tej oceny i nie należy traktować ich jako kryterium bezpieczeństwa w oderwaniu od rzeczywistego terminu uzupełnienia i zapasu w buforze. Results for the Streaming Media Performance Assessment

Rozmiar bufora a opóźnienie odtwarzania

Jeśli przy tych samych warunkach zgromadzi się z wyprzedzeniem więcej dźwięku, łatwiej zamortyzować chwilowe opóźnienia uzupełniania, ale nowo wytworzony dźwięk czeka za dźwiękiem, który już jest w buforze. Opóźnienie akceptowalne przy samym słuchaniu muzyki staje się odczuwalne jako rozjazd między czynnością a dźwiękiem, gdy gra się na klawiszach albo przetwarza głos z mikrofonu i samemu słucha się go na bieżąco. Exclusive-Mode Streams, Low Latency Audio

flowchart TB
    accTitle: Zapas w buforze a opóźnienie reakcji
    accDescr: Gromadzenie większej ilości dźwięku z wyprzedzeniem ułatwia amortyzowanie chwilowych opóźnień uzupełniania, ale wydłuża też czas oczekiwania na odtworzenie nowego dźwięku.
    A["Więcej dźwięku z wyprzedzeniem"] --> B["Łatwiej zamortyzować opóźnienia"]
    B -->|"kosztem"| C["Nowy dźwięk czeka w kolejce"]
    C --> D["Dźwięk spóźnia się za czynnością"]

Rys. 7: Zwiększenie bufora to regulacja, która daje zapas kosztem szybkości reakcji.

Nie jest tak, że „im mniejszy, tym wydajniej”, ani że „im większy, tym lepiej”. Należy zachować potrzebną szybkość reakcji, a jednocześnie zapewnić zapas, przy którym dźwięk się nie przerywa.

Zwiększenie bufora daje zapas na chwilowe opóźnienia dostaw. Jeśli sama średnia dostawa nie nadąża za zużyciem, zwiększenie skończonego bufora jedynie wydłuża czas do jego wyczerpania i nie usuwa też rozłączania się urządzenia. Nie jest to również zalecenie, że tryb wyłączny wszystko rozwiąże. Exclusive-Mode Streams

Dźwięk 48 kHz, 480 ramek

Ramka PCM to jednostka obejmująca próbki wszystkich kanałów odtwarzane w tej samej chwili. To, że dźwięk jest stereo, nie oznacza, że przy obliczaniu czasu trzeba podwoić liczbę ramek. Długość dźwięku odpowiadającą liczbie ramek oblicza się jako „liczba ramek ÷ częstotliwość próbkowania”; 480 ramek przy 48 kHz to 480 ÷ 48000 s, czyli 10 ms. Jeśli przy 48 kHz zwiększy się liczbę ramek, wydłuży się też czas dźwięku, który można zgromadzić. Rendering a Stream

Ten czas to nie to samo co całkowite opóźnienie od naciśnięcia klawisza do usłyszenia dźwięku. Dochodzi bowiem czas aplikacji, sterownika, urządzenia oraz innych buforów i etapów przetwarzania. Wartości ustawień w DAW także należy odczytywać po sprawdzeniu jednostki i tego, którego bufora dotyczą. Low Latency Audio

flowchart TB
    accTitle: Czas obliczony z liczby ramek a całkowite opóźnienie
    accDescr: 10 ms uzyskane z podzielenia 480 ramek przez 48000 to czas reprezentowany przez bufor, a całkowite opóźnienie od klawisza do dźwięku powstaje po doliczeniu przetwarzania w aplikacji, sterowniku, urządzeniu i innych miejscach.
    A["480 ÷ 48000"] --> B["10 ms reprezentowane przez bufor"]
    B -->|"dochodzi inne przetwarzanie"| C["Całe opóźnienie od klawisza do dźwięku"]

Rys. 8: Czas obliczony z liczby ramek to część całkowitego opóźnienia.

Porównanie warunków odtworzenia problemu

Najpierw zawęża się kombinację, przy której problem występuje, a do szczegółowego rejestrowania przechodzi się tylko w razie potrzeby. Poniżej opisano procedurę służącą do weryfikacji przyczyny; nie jest to lista środków zaradczych, w której wszystkie zmiany ustawień wprowadza się naraz.

Proszę zapisać pracę, zakończyć ważne spotkania i nagrania, a testy przeprowadzać przy głośności, która nie obciąża słuchu. Należy zanotować pierwotne wyjście, ulepszenia audio, wartości bufora i inne ustawienia, tak aby można było je przywrócić. Pozycje, dla których nie ma ustawień, należy pominąć; nie należy zmieniać rejestru ani innych miejsc tylko po to, by pojawiły się opcje ustawień.

1. Proszę wybrać jedno krótkie nagranie i stały czas obserwacji, a następnie sprawdzić, czy problem występuje w pierwotnych warunkach.

   Należy zapisać wersję Windows, nazwę i wersję aplikacji, urządzenie wyjściowe, sposób podłączenia i wersję sterownika. Należy też zanotować czas, czynność i liczbę wystąpień przerw w dźwięku. Jeśli w pierwotnych warunkach problem nie występuje, nie należy uznawać, że nastąpiła poprawa, tylko wrócić do ustalania warunków, w których się pojawia.

2. Proszę wybrać z poniższej tabeli jedno porównanie i odtworzyć nagranie, zmieniając tylko ten warunek.

   Porównywany warunek	Co sprawdzić
   Nagranie zapisane lokalnie a odtwarzanie przez sieć	Czy problem występuje tylko przy odtwarzaniu przez sieć. Jeśli przy tej samej treści różni się format lub ścieżka przetwarzania, to także należy zapisać.
   To samo nagranie w innej aplikacji	Czy problem dotyczy głównie konkretnej aplikacji.
   Wyjście Bluetooth itp. a wyjście wbudowane lub przewodowe	Czy problem dotyczy głównie konkretnej ścieżki wyjścia.
   Ulepszenia audio włączone i wyłączone	Czy wynik zmienia się w połączeniu z przetwarzaniem efektów.
   Obecny bufor w DAW itp. a wartość o stopień większa	Czy coś się zmienia po zwiększeniu zapasu gromadzonego z wyprzedzeniem. Czy opóźnienie od czynności do dźwięku pozostaje akceptowalne.

3. Przy porównywaniu ulepszeń audio proszę tymczasowo wyłączyć to ustawienie dla danego wyjścia.

   W systemie Windows należy w „Ustawienia” → „System” → „Dźwięk” wybrać dane wyjście i, jeśli środowisko na to pozwala, wyłączyć „Ulepszenia audio”. Jeśli wygląd ekranu lub dostępność opcji są inne, proszę sprawdzić wskazówki dla danej wersji i urządzenia. Fix distorted or crackling audio in Windows

4. Proszę przywrócić zmienione ustawienie i spróbować ponownie z tym samym nagraniem i tym samym czasem obserwacji.

   Wyniki dla „warunków pierwotnych”, „warunków z jedną zmianą” i „warunków przywróconych” należy zestawić obok siebie. Zmianę, która nic nie dała, należy cofnąć, zanim przejdzie się do kolejnego porównania. Jeśli ciągle zmienia się kombinację ustawień, nie wiadomo, co faktycznie pomogło.

5. Zmianę sterownika proszę wypróbowywać dopiero po sprawdzeniu oficjalnego źródła i sposobu przywrócenia poprzedniego stanu.

   Należy korzystać z Windows Update lub oficjalnej dystrybucji producenta urządzenia i zapisać wersje oraz ustawienia przed zmianą i po niej. Trzeba wcześniej upewnić się, że da się wrócić do poprzedniego stanu, a na komputerach zarządzanych skonsultować się z administratorem. Jednorazowe poprawne odtworzenie zaraz po aktualizacji nie oznacza rozwiązania problemu; należy to sprawdzić w tych samych warunkach odtworzenia. Fix distorted or crackling audio in Windows

Celem jest zapis, który wiąże objaw z warunkami, na przykład „problem występuje w tej aplikacji przy użyciu tego wyjścia”. Nawet jeśli znajdzie się ustawienie, które poprawia sytuację, należy to oddzielić od ustalenia przyczyny.

flowchart TB
    accTitle: Porównanie przez zmianę jednego warunku i przywrócenie go
    accDescr: Na tym samym nagraniu sprawdza się wystąpienie problemu, zmienia jeden warunek, na przykład aplikację lub wyjście, i zapisuje także wynik po przywróceniu.
    A["Odtwarzanie w pierwotnym zestawie"] --> B["Odtwarzanie po zmianie warunku"]
    B --> C["Odtwarzanie po przywróceniu"]
    C --> D["Zapis warunków i czasu przerw"]

Rys. 9: Ważniejsze od jednorazowej poprawy jest potwierdzenie, że warunki i objawy powtarzalnie sobie odpowiadają.

Powtarzalność przed zmianą i po niej

„Udało się złagodzić objawy”, „udało się zawęzić warunki” i „udało się ustalić główną przyczynę” to różne etapy. Wnioski należy zapisywać stosownie do zakresu tego, co udało się zaobserwować.

flowchart TB
    accTitle: Trzy wyniki wskazujące związek z warunkiem
    accDescr: Jeśli problem występuje w pierwotnych warunkach, zmiana jednego warunku przynosi poprawę, a po przywróceniu problem wraca, jest to wskazówka związku z tym warunkiem, którą jednak oddziela się od ustalenia przyczyny.
    A["Występuje w warunkach pierwotnych"] --> B["Po jednej zmianie poprawa"]
    B --> C["Po przywróceniu wraca"]
    C --> D["Wskazówka związku z warunkiem"]

Rys. 10: Nawet gdy wystąpią wszystkie trzy wyniki, uzyskuje się jedynie wskazówkę związku.

Niskie użycie CPU nie dowodzi, że terminy dla dźwięku zostały dotrzymane. Jednocześnie sam fakt wystąpienia przerwy nie pozwala stwierdzić, że główną przyczyną było opóźnione uzupełnianie. Należy porównać nagranie, przetwarzanie w aplikacji, efekty, ścieżkę wyjścia i inne elementy, a oceniać w granicach tego, co zaobserwowano. Fix distorted or crackling audio in Windows

Przy wdrażaniu tymczasowego obejścia należy zapisać pierwotne ustawienia, wprowadzone zmiany, czas obserwacji, to, czy problem powrócił, oraz akceptowalne opóźnienie. Jeśli główna przyczyna nie została ustalona, trzeba to również odnotować.

Rejestrowanie przerw w dźwięku w WPR

Ten krok wykonuje się, gdy samo porównywanie warunków nie zawęża przyczyny albo gdy trzeba zbadać przetwarzanie po stronie sterownika. WPR to narzędzie do rejestrowania, a WPA do analizy zapisanej osi czasu. Należy przygotować Windows Performance Toolkit, uprawnienia potrzebne do rejestrowania i miejsce zapisu pliku ETL. Jeśli na komputerze zarządzanym trzeba zainstalować narzędzia i wykonać rejestrację, proszę zwrócić się do administratora. Nazwy wyświetlane i dostępne profile należy sprawdzić w zainstalowanej wersji. Windows Performance Recorder

Plik ETL może zawierać nazwy procesów, ścieżki plików i inne dane. Przed rejestracją należy sprawdzić wewnętrzne zasady firmy i ustalić, komu plik zostanie udostępniony; proszę nie załączać go bez zmian w miejscach publicznych. Jeśli działa inna sesja rejestrowania, nie należy jej samowolnie zatrzymywać, tylko skontaktować się z osobą odpowiedzialną. WPR How-to Topics

1. Proszę otworzyć w WPR „More Options” i wybrać profil rejestrowania odpowiedni do celu.

   Wśród profili standardowych są „Audio glitches” i „CPU usage”. Należy wybrać ustawienia, które pozwalają badać nieciągłości dźwięku i pracę CPU. Dostępne profile, nazwy wyświetlane i zakres zbieranych danych należy sprawdzić w zainstalowanej wersji; nie należy ustawiać długotrwałego rejestrowania wszystkich rodzajów danych. Built-in Recording Profiles

2. Proszę rozpocząć rejestrowanie, zanim odtworzy się przerwę w dźwięku.

   Jeśli pojawi się pytanie o zatrzymanie istniejącego rejestrowania, nie należy kontynuować, tylko zrezygnować z uruchamiania i skontaktować się z osobą odpowiedzialną. Warunki należy ujednolicić z przebiegiem bez rejestrowania, a także odnotować możliwość, że samo obciążenie rejestrowaniem zmieni objawy. WPR How-to Topics

3. Proszę odtworzyć nagranie w warunkach znalezionych podczas porównań i zanotować czas przerwy oraz wykonaną czynność.

   Przed objawem i po nim należy objąć zapisem także krótkie odcinki bez problemu. Przy zapisie, w którym problem nie wystąpił, trzeba to wyraźnie zaznaczyć i nie traktować go jako zapisu, który uchwycił przyczynę.

4. Po odtworzeniu problemu proszę zakończyć rejestrowanie przyciskiem „Save” i zapisać plik ETL.

   „Cancel” nie zapisuje danych. Należy zanotować miejsce zapisu, warunki odtworzenia problemu, to, czy zapis został wykonany, oraz to, czy pojawiło się ostrzeżenie o utracie zdarzeń. W zapisie z utraconymi zdarzeniami nie należy uznawać niewidocznych odcinków za prawidłowe. WPR How-to Topics

Gdy są już plik ETL i notatki z czasem, czynnościami i warunkami przerw, można przystąpić do zestawiania danych w WPA. Samo zapisanie śladu nie gwarantuje, że zarejestrowano potrzebne zdarzenia. Zawartość sprawdza się w następnej sekcji „Wykonanie i oczekiwanie wokół przerwy”.

flowchart TB
    accTitle: Krótki zapis obejmujący przerwę w dźwięku
    accDescr: Rejestrowanie rozpoczyna się w WPR, odtwarza się objaw i notuje czas, a zatrzymany i zapisany ślad bada się w WPA.
    A["Start rejestrowania w WPR"] --> B["Odtworzenie przerwy w tych warunkach"]
    B --> C["Notatka czasu i czynności, zapis"]
    C --> D["Powiększenie okolic przerwy w WPA"]

Rys. 11: Użycie CPU sprawdzone po ustąpieniu objawu nie wystarcza; potrzebny jest zapis odcinka, w którym objaw wystąpił.

Wykonanie i oczekiwanie wokół przerwy

Należy przygotować zapisany plik ETL i notatki z czasem wystąpienia problemu. Poniżej opisano punkt wyjścia do analizy w WPA. Jeśli potrzebna okaże się szczegółowa analiza obejmująca stosy i symbole, należy ją zlecić administratorowi lub programistom, zachowując ostrożność w obchodzeniu się z zapisem.

1. Proszę otworzyć plik ETL w WPA i na podstawie zarejestrowanych zdarzeń audio oraz czasu wystąpienia problemu powiększyć okolice przerwy.

   Odcinki bez objawów należy zachować do porównania. Nie należy patrzeć wyłącznie na ranking wartości maksymalnych, tylko porównywać dane w tym samym zakresie czasu.

2. Proszę sprawdzić w tym samym zakresie „DPC/ISR” i „CPU Usage (Precise)”.

   Jeśli brakuje potrzebnych danych, należy sprawdzić, czy profil pozwala je zebrać, i wrócić do rejestrowania w WPR. Brak zapisu to co innego niż brak problemu. CPU Analysis, Built-in Recording Profiles

3. Proszę rozróżnić, czy wątek związany z dźwiękiem był gotowy do wykonania, ale czekał w kolejce, czy też czekał na przykład na dane.

   W pierwszym przypadku należy sprawdzić, czy na danym procesorze logicznym nie działały długo DPC/ISR lub inne procedury. W drugim należy prześledzić na podstawie zarejestrowanych zdarzeń i stosów, co zakończyło oczekiwanie. Ponieważ wykonujący się wątek może też zostać wstrzymany przez przerwanie, nie należy ograniczać się do czasu w stanie Ready, tylko nałożyć na niego również odcinki DPC/ISR. CPU Analysis

4. Proszę zapisać razem zbieżność czasową z przerwą, procesor, którego to dotyczy, i wyniki po zmianie warunków.

   Sama nazwa modułu z długim DPC/ISR nie przesądza, że przyczyną jest konkretne urządzenie lub sterownik. Możliwe, że patrzy się na dużą wartość z innego momentu albo na wspólny element, przez który przechodzi wiele urządzeń.

flowchart TB
    accTitle: Badanie rodzaju oczekiwania w odcinku przerwy
    accDescr: Powiększa się okolice przerwy i sprawdza stan wątku audio. Jeśli był gotowy i czekał w kolejce, zestawia się go z DPC i ISR na tym samym CPU; jeśli czekał na przykład na dane, śledzi się to, co zakończyło oczekiwanie.
    A["Powiększ okolice przerwy"] --> B{"Stan wątku"}
    B -->|"w kolejce"| C["DPC i ISR"]
    B -->|"czeka na dane"| D["Co zakończyło oczekiwanie"]

Rys. 12: Zamiast wyłuskiwać same maksima, odczytuje się dane nałożone na odcinek, w którym potrzebne było przetwarzanie dźwięku.

Jeśli przyczyny nie uda się ustalić, dochodzenie przekazuje się dalej jako nierozstrzygnięte. Należy dołączyć wersje systemu operacyjnego, aplikacji, urządzenia i sterownika, kroki odtworzenia problemu, wyniki przed zmianą i po niej, czas wystąpienia, profil zbierania danych oraz informację, czy pojawiło się ostrzeżenie o utracie zdarzeń. Plik ETL udostępnia się zgodnie z wewnętrznymi zasadami firmy wyłącznie osobom prowadzącym dochodzenie.

Wczesne wczytywanie w aplikacjach audio

Tworząc własną aplikację audio, należy zaprojektować ją tak, aby wypełnianie kolejnego bufora za każdym razem mieściło się w terminie. WASAPI udostępnia sposób, by otrzymywać zdarzenie w chwili, gdy bufor można przetworzyć. Exclusive-Mode Streams

MMCSS to mechanizm przydzielający zasoby CPU wątkom przetwarzania multimedialnego z ograniczeniami czasowymi. Nie ma funkcji wcześniejszego przygotowania danych z dysku ani usuwania oczekiwania na blokady. Nawet przy korzystaniu z przydziału przez MMCSS potrzebny jest osobny projekt obejmujący przygotowanie danych i ograniczanie oczekiwania. Multimedia Class Scheduler Service

flowchart TB
    accTitle: Za co odpowiada MMCSS
    accDescr: MMCSS przydziela zasoby CPU wątkom przetwarzania z ograniczeniami czasowymi, ale przygotowanie danych i ograniczanie oczekiwania na blokady realizuje osobny projekt.
    M["MMCSS: przydział zasobów CPU"] -.->|"potrzebne osobno"| D["Przygotowanie danych, mniej oczekiwania"]

Rys. 13: Przydział zasobów CPU i projekt, który dostarcza dane na czas, to dwa różne zadania.

Zasadą projektową jest oddzielenie kodu odczytującego z plików lub sieci od kodu przekazującego dźwięk. Przygotowania o trudnym do przewidzenia czasie wykonuje się z wyprzedzeniem, a do przekazywania danych używa się wcześniej zaalokowanego bufora. Po stronie audio kod powinien być zbudowany tak, aby nie musiał czekać na odpowiedź UI, długie blokady ani synchroniczny zapis logów.

flowchart TB
    accTitle: Oddzielenie nieprzewidywalnych przygotowań od dostarczania dźwięku
    accDescr: Projekt, w którym wczytywanie i podobne zadania wykonuje się z wyprzedzeniem, a przygotowane dane przekazuje do przetwarzania audio przez bufor, aby ograniczyć długie oczekiwanie tuż przed terminem.
    A["Wcześniejsze przygotowanie danych"] --> B["Wcześniej zaalokowany obszar wymiany"]
    B --> C["Audio przekazuje potrzebną część"]
    C --> D["Dostawa do wyjścia audio"]

Rys. 14: Czasochłonną pracę usuwa się z momentu tuż przed przekazaniem dźwięku.

Jeśli strona przygotowująca zatrzyma się na dłużej, zapas wyczerpie się mimo tego podziału. Należy rejestrować, w sposób, który nie przeszkadza przetwarzaniu dźwięku, nie tylko średni czas przetwarzania, lecz także przypadki długiego przetwarzania lub oczekiwania oraz liczbę nieudanych dostaw. Faktycznie wybrany rozmiar bufora i okres należy odczytać z API lub sterownika, nie zakładając, że zadana wartość została przyjęta bez zmian. Rendering a Stream, Low Latency Audio

Zarówno przykłady liczbowe, jak i przykłady projektowe służą wyjaśnieniu; nie są zalecanymi wartościami ustawień dla konkretnego urządzenia ani gwarancją, że w dowolnym środowisku nie wystąpią przerwy w dźwięku.

Wpływ priorytetu czasu rzeczywistego

Nie zalecamy jako ogólnej zasady, aby użytkownicy zmieniali priorytet całego odtwarzacza na „Czas rzeczywisty”. Grozi to zakłóceniem innych ważnych procesów, a podniesienie priorytetu zwykłego wątku nie usuwa oczekiwania spowodowanego przez DPC/ISR ani oczekiwania na dane i blokady. Przy tworzeniu oprogramowania korzysta się z mechanizmów takich jak MMCSS oraz z projektu, który nie wprowadza długiego oczekiwania do dostarczania dźwięku. Scheduling Priorities, CPU Analysis

flowchart TB
    accTitle: Oczekiwanie, które zostaje mimo priorytetu czasu rzeczywistego
    accDescr: Nawet po ustawieniu odtwarzacza na priorytet czasu rzeczywistego zwykłe wątki nie wyprzedzą DPC ani ISR na tym samym CPU, oczekiwanie na dane i blokady pozostaje, a do tego istnieje ryzyko zakłócenia innych ważnych procesów.
    A["Odtwarzacz z priorytetem czasu rzeczywistego"] --> B["Nie wyprzedzi DPC ani ISR"]
    B --> C["Oczekiwanie na dane i blokady zostaje"]
    C --> D["Ryzyko zakłócenia innych procesów"]

Rys. 15: Nawet po podniesieniu priorytetu zostaje oczekiwanie, które opóźnia uzupełnianie danych audio.

Powiązane artykuły

• „Planowanie procesora” w Windows i ustawienie usług w tle
• Bezpieczna diagnoza 100% użycia dysku w Windows
• Dlaczego RDP działa wolno, choć łącze jest szybkie?

Źródła

• Microsoft Learn, Rendering a Stream. Dostarczanie danych do bufora odtwarzania, ilość pozostałych danych, rzeczywisty rozmiar bufora, definicja ramki PCM.
• Microsoft Learn, Exclusive-Mode Streams. Moment dostarczenia danych do bufora a zakłócenia dźwięku, kompromis z opóźnieniem, dostarczanie sterowane zdarzeniami. Nie jest to ogólne zalecenie stosowania samego trybu wyłącznego.
• Microsoft Learn, Low Latency Audio. Ścieżka audio w Windows, bufory, urządzenia i przetwarzanie efektów a opóźnienie, kompromisy związane z niskim opóźnieniem.
• Microsoft Learn, CPU Analysis. Procesory logiczne, stany wątków Ready/Waiting, relacja między DPC/ISR a wykonywaniem wątków, analiza CPU w WPA.
• Microsoft Learn, Introduction to DPCs. Mechanizm skracania obsługi przerwań przez przekazywanie pozostałej pracy do DPC.
• Microsoft Learn, Results for the Streaming Media Performance Assessment. Długie i częste DPC/ISR, niedobór dostarczanych danych i zakłócenia dźwięku. Progów ostrzegawczych z oceny nie uogólniamy jako kryterium bezpieczeństwa dla wszystkich urządzeń.
• Microsoft Support, Fix distorted or crackling audio in Windows. Sprawdzanie ulepszeń audio, formatu, sterowników i innych elementów.
• Microsoft Learn, Windows Performance Recorder. Rejestrowanie ETW i analiza w WPA, korzystanie z Windows Performance Toolkit.
• Microsoft Learn, Built-in Recording Profiles. More Options w WPR oraz profile standardowe, takie jak Audio glitches i CPU usage.
• Microsoft Learn, WPR How-to Topics. Rozpoczynanie rejestrowania i zapis przez Save, konflikty z istniejącymi sesjami, uwagi dotyczące danych osobowych i utraty zdarzeń.
• Microsoft Learn, Multimedia Class Scheduler Service. Przydział zasobów CPU dla przetwarzania multimedialnego z ograniczeniami czasowymi.
• Microsoft Learn, Scheduling Priorities. Priorytety procesów i wątków oraz uwagi dotyczące priorytetu czasu rzeczywistego.

Powiązane artykuły

Najnowsze artykuły oznaczone tymi samymi tagami. Pozwalają pogłębić wiedzę na pokrewne tematy.

Powiązane tematy

Strony tematyczne zbliżone do tego zagadnienia. Od artykułu mogą Państwo przejść do powiązanych usług i innych artykułów.

Usługi powiązane z tym tematem

Ten artykuł prowadzi do poniższych stron usług. Prosimy wybrać najbliższy punkt wyjścia.

Najczęściej zadawane pytania

Pytania, które najczęściej padają podczas konsultacji na temat tego artykułu.

Dlaczego dźwięk się przerywa, skoro użycie CPU wynosi tylko około 10%?

Dźwięk ma swój termin: kolejne dane trzeba dostarczyć, zanim zostaną zużyte dane, które są właśnie odtwarzane. Nawet przy niskim użyciu całego CPU przetwarzanie dźwięku może nie zdążyć, jeśli w danej chwili nie może się wykonać albo czeka na potrzebne dane. Nie każda przerwa w dźwięku ma tę przyczynę, dlatego potrzebne są też porównania po zmianie urządzenia wyjściowego lub aplikacji.

Czy zwiększenie bufora audio usunie przerwy w dźwięku?

Jeśli uzupełnianie opóźnia się chwilowo, większy bufor może to zamortyzować. Wydłuża się jednak także czas oczekiwania, zanim zgromadzony dźwięk zostanie odtworzony. To ustawienie nie usuwa ani stałego niedoboru mocy obliczeniowej, ani rozłączania się urządzenia. W aplikacjach i sterownikach, które pozwalają na taką zmianę, należy zanotować pierwotną wartość i porównywać, zmieniając ją kolejno o jeden stopień.

Ile milisekund dźwięku to 480 ramek przy 48 kHz?

To 480 ÷ 48000 s, czyli 10 ms. Jedna ramka PCM to jednostka obejmująca próbki wszystkich kanałów z tej samej chwili. Ta wartość to długość dźwięku odpowiadająca tej liczbie ramek, a nie całkowite opóźnienie z uwzględnieniem urządzeń i aplikacji.

Czy sterownik z długim czasem wykonania DPC lub ISR jest winowajcą przerw w dźwięku?

Może być kandydatem, ale sam ranking czasów wykonania nie pozwala tego przesądzić. Należy zestawić odcinek, w którym wystąpiła przerwa, z oczekiwaniem wątku audio i wykonywaniem DPC/ISR na tym samym CPU. Nie należy na podstawie samej nazwy modułu przesądzać o usterce konkretnego urządzenia lub sterownika; trzeba też sprawdzić wyniki po zmianie warunków, w których problem występuje.

Czy ustawienie odtwarzacza na priorytet czasu rzeczywistego poprawi sytuację?

Nie zalecamy tego jako ogólnej zasady. Podniesienie priorytetu zwykłego wątku nie pozwala mu wyprzedzić zwykłych DPC i ISR na tym samym CPU ani nie usuwa oczekiwania na dane lub blokady. Programiści korzystają z mechanizmów takich jak MMCSS i z projektu, który nie wprowadza oczekiwania, a użytkownicy najpierw porównują warunki, w których problem występuje, oraz ścieżkę wyjścia.

Profil autora

Strona z profilem autora artykułu.

Go Komura

Przedstawiciel KomuraSoft LLC

Zajmuje się głównie tworzeniem oprogramowania dla systemu Windows, konsultacjami technicznymi i diagnostyką błędów. Szczególnie dobrze sprawdza się w projektach z istniejącymi zasobami oraz w analizie awarii o trudnych do wskazania przyczynach.