Problemy z wydajnością sterownika WavePci Miniport

Wpływ sterownika audio na wydajność systemu można znacznie zmniejszyć, postępując zgodnie z następującymi ogólnymi zasadami:

• Zminimalizuj kod uruchamiany podczas normalnego działania.

• Uruchom kod tylko wtedy, gdy jest to konieczne.

• Rozważ całkowite użycie zasobów systemowych (nie tylko ładowanie procesora CPU).

• Zoptymalizuj kod pod kątem szybkości i rozmiaru.

Ponadto sterowniki miniportu WavePci muszą rozwiązać kilka problemów z wydajnością specyficznych dla urządzeń audio. Poniższa dyskusja dotyczy głównie problemów z renderowaniem audio, chociaż niektóre sugerowane techniki mają zastosowanie również do przechwytywania dźwięku.

Mechanizmy obsługi strumienia

Przed omówieniem optymalizacji wydajności konieczne jest zapoznanie się z mechanizmami WavePci na potrzeby obsługi strumieni.

Podczas przetwarzania strumienia renderowania lub przechwytywania dźwięku urządzenie audio wymaga regularnej konserwacji przez sterownik miniportu. Gdy nowe mapowania są dostępne dla strumienia, sterownik dodaje te mapowania do kolejki DMA strumienia. Sterownik usuwa również z kolejki wszystkie mapowania, które zostały już przetworzone. Aby uzyskać informacje o mapowaniach, zobacz Opóźnienie WavePci.

Aby wykonać obsługę, sterownik miniportu zapewnia odroczone wywołanie procedury (DPC) lub procedurę usługi przerwania (ISR), w zależności od tego, czy interwał jest ustawiony przez czasomierz systemowy, czy przez przerwania sterowane przez DMA. W tym drugim przypadku sprzęt DMA zwykle wyzwala przerwanie za każdym razem, gdy zakończy przesyłanie pewnej ilości danych strumieniowych.

Za każdym razem, gdy DPC lub ISR jest wykonywany, określa, które strumienie wymagają obsługi. Usługa DPC lub ISR obsługuje strumień, wywołując metodę IPortWavePci::Notify . Ta metoda przyjmuje jako parametr wywołania grupę usług strumienia, która jest obiektem typu IServiceGroup. Metoda Notify wywołuje metodę RequestService grupy usług (zobacz IServiceSink::RequestService).

Obiekt grupy usług zawiera grupę ujściów usługi, które są obiektami typu IServiceSink. IServiceGroup pochodzi z interfejsu IServiceSink, a oba interfejsy mają metody RequestService . Gdy metoda Notify wywołuje metodę RequestService grupy usług, grupa usług odpowiada przez wywołanie metody RequestService dla każdego ujścia usługi w grupie.

Grupa usług strumienia zawiera co najmniej jeden odbiornik usług, który sterownik portu dodaje do grupy usług bezpośrednio po utworzeniu strumienia. Sterownik portu wywołuje metodę IMiniportWavePci::NewStream sterownika miniportu, aby uzyskać wskaźnik na grupę usług. Metoda RequestService ujścia usługi jest procedurą usługi specyficznej dla strumienia sterownika portu. Ta rutyna wykonuje następujące czynności:

• Wywołuje metodę IMiniportWavePciStream::Service sterownika miniportu .

• Wyzwala wszystkie nowo oczekujące zdarzenia pozycjonowania lub zegara w strumieniu danych od ostatniego wykonania procedury usługi.

Zgodnie z opisem w temacie Zdarzenia KS klienci mogą rejestrować się, aby otrzymywać powiadomienia, gdy strumień osiągnie określoną pozycję lub gdy zegar osiągnie określony znacznik czasu. Metoda NewStream ma możliwość nie dostarczania grupy usług, w tym przypadku sterownik portu konfiguruje własny czasomierz, aby oznaczyć interwały między wywołaniami jego procedury obsługi.

Podobnie jak metoda NewStream, metoda IMiniportWavePci::Init sterownika miniportu również zwraca wskaźnik do grupy usług. Po wywołaniu Init sterownik portu dodaje odbiornik usługi do grupy usług. Ten konkretny moduł usługowy zawiera procedurę serwisową dla filtru jako całości. (W poprzednim akapicie opisano ujście usługi dla strumienia skojarzonego z pinem na filtrze). Ta procedura usługi wywołuje metodę sterownika miniportu IMiniportWavePci::Service. Rutynowa usługa jest wykonywana za każdym razem, gdy DPC lub ISR wywołuje funkcję Notify z grupą usług dla filtru. Metoda Init ma możliwość nie podawania grupy usług, w tym przypadku sterownik portu nigdy nie wywołuje procedury usługi filtrowania.

Przerwania sprzętowe

Niektóre sterowniki miniportu generują zbyt wiele lub za mało przerwań sprzętowych. W niektórych urządzeniach renderowania WavePci z przyspieszaniem sprzętowym DirectSound przerwanie sprzętowe występuje tylko wtedy, gdy podaż mapowań jest prawie wyczerpana, a aparat renderowania jest zagrożony głodem. W innych urządzeniach ze sprzętowym przyspieszeniem WavePci przerwanie sprzętowe występuje przy każdym zakończeniu mapowania lub w innym stosunkowo małym interwale. W tym przypadku ISR często nie ma wiele do zrobienia, ale każde przerwanie nadal zużywa zasoby systemowe przez zamiany rejestrów i ponowne ładowanie pamięci podręcznej. Pierwszym krokiem poprawy wydajności sterownika jest zmniejszenie liczby przerwań w jak największym stopniu bez ryzyka zagłodzenia. Po wyeliminowaniu niepotrzebnych przerwań można osiągnąć dodatkowe wzrosty wydajności, projektując isr w celu wydajniejszego wykonywania.

W niektórych sterownikach, ISR tracą czas, wywołując metodę Notify strumienia za każdym razem, gdy wystąpi przerwanie sprzętowe — niezależnie od tego, czy strumień faktycznie działa. Jeśli żadne strumienie nie są w stanie URUCHOM, usługa DMA jest nieaktywna i każdy czas spędzony na próbie uzyskania mapowań, zwolnieniu mapowań lub sprawdzeniu nowych zdarzeń w jakichkolwiek strumieniach jest zmarnowany. W wydajnym sterowniku ISR sprawdza, czy strumień jest uruchomiony przed wywołaniem metody Notify strumienia.

Jednak sterownik z takim typem ISR musi upewnić się, że wszystkie oczekujące zdarzenia w strumieniu są wyzwalane, gdy strumień opuszcza stan RUN. W przeciwnym razie zdarzenia mogą być opóźnione lub utracone. Ten problem występuje tylko podczas przechodzenia RUN-to-PAUSE w systemach operacyjnych starszych niż Microsoft Windows XP. W systemie Windows XP i nowszym sterownik portu automatycznie sygnalizuje wszystkie zaległe zdarzenia pozycji natychmiast po zmianie stanu strumienia z RUN na PAUSE. Jednak w starszych systemach operacyjnych sterownik miniportu jest odpowiedzialny za wyzwalanie wszelkich zaległych zdarzeń przez wykonanie ostatniego wywołania powiadomienia natychmiast po wstrzymaniu strumienia. Aby uzyskać więcej informacji, zobacz PAUZA/POZYSKIWANIE Optymalizacji poniżej.

Typowy sterownik miniportu WavePci zarządza pojedynczym strumieniem odtwarzania ze sterownika systemu KMixer. Bieżąca implementacja KMixer używa co najmniej trzech mapowań IRP do buforowania strumienia odtwarzania. Każdy protokół IRP zawiera wystarczającą ilość pamięci buforu dla około 10 milisekund dźwięku. Jeśli sterownik miniportu wyzwala przerwanie sprzętowe za każdym razem, gdy kontroler DMA zakończy ostateczne mapowanie w IRP, przerwania powinny występować w dość regularnych 10-milisekundowych odstępach, co jest wystarczająco częste, aby zapobiec zapotrzebowaniu w kolejce DMA.

Kontrolery DPC czasomierza

Jeśli sterownik zarządza dowolnymi strumieniami DirectSound przyspieszanymi sprzętowo, powinien używać czasomierza DPC (zobacz Timer Objects and DPCs) zamiast przerwań sprzętowych sterowanych DMA. Podobnie urządzenie WavePci na karcie PCI z czasomierzem wbudowanym może używać przerwania sprzętowego sterowanego czasomierzem zamiast DPC.

W przypadku buforu DirectSound cały bufor może być dołączony do pojedynczego IRP. Jeśli bufor jest duży, a sterownik miniportu generuje przerwanie sprzętowe tylko wtedy, gdy osiągnie koniec buforu, kolejne przerwania mogą występować w takich odstępach czasu, że kolejka DMA głoduje. Ponadto jeśli sterownik zarządza dużą liczbą strumieni directSound przyspieszanych sprzętowo, a każdy strumień generuje własne przerwania, skumulowany wpływ wszystkich przerwań może obniżyć wydajność systemu. W takich okolicznościach sterownik miniportu powinien unikać używania przerwań sprzętowych do planowania obsługi poszczególnych strumieni. Zamiast tego należy obsługiwać wszystkie strumienie w jednym DPC, który ma być uruchamiany w regularnych interwałach generowanych przez czasomierz.

Ustawiając interwał czasomierza na 10 milisekund, interwał między kolejnymi wykonaniami DPC jest podobny do opisanego wcześniej dla przerwania sprzętowego w przypadku pojedynczego strumienia odtwarzania KMixer. W związku z tym DPC może obsługiwać strumień odtwarzania KMixer oprócz strumieni DirectSound przyspieszanych sprzętowo.

Gdy ostatni strumień kończy stan RUN, sterownik miniportu powinien wyłączyć czasomierz DPC, aby uniknąć marnowania cykli procesora CPU systemu. Natychmiast po wyłączeniu DPC sterownik powinien upewnić się, że wszystkie zdarzenia zegara lub położenia oczekujące na wcześniej uruchomionych strumieniach są usuwane. W systemach Windows 98/Me i Windows 2000 sterownik powinien wywołać funkcję Notify , aby wyzwolić wszelkie oczekujące zdarzenia w strumieniach, które są wstrzymane. W systemie Windows XP i nowszym system operacyjny wyzwala wszystkie oczekujące zdarzenia automatycznie, gdy strumień kończy stan RUN, bez konieczności interwencji przez sterownik miniportu.

OPTYMALIZACJE PAUSE/ACQUIRE

W systemach Windows 98/Me i Windows 2000, routyna serwisowa strumienia sterownika portu WavePci (metoda RequestService) zawsze generuje wywołanie metody sterownika miniportu IMiniportWavePciStream::Service, niezależnie od tego, czy strumień jest w stanie RUN. W tych systemach operacyjnych metoda Service powinna sprawdzić, czy strumień jest uruchomiony, zanim poświęci czas na rzeczywistą pracę. (Jeśli jednak kontroler DPC lub ISR sterownika miniportu został już zoptymalizowany pod kątem wywołania funkcji Notify tylko dla uruchomionych strumieni, dodanie tej kontroli do metody usługi może być nadmiarowe).

W systemie Windows XP i nowszych ta optymalizacja jest niepotrzebna, ponieważ metoda Notify wywołuje metodę Service tylko w strumieniach, które są uruchomione.

Korzystanie z interfejsu IPreFetchOffset

Użytkownicy directSound znają podwójne pojęcia kursora odtwarzania i kursora zapisu. Kursor odtwarzania wskazuje położenie w strumieniu danych emitowanych z urządzenia (najlepsze oszacowanie sterownika co do próbki aktualnie przetwarzanej przez przetwornik cyfrowo-analogowy). Pozycja zapisu to pozycja w strumieniu oznaczająca następne bezpieczne miejsce dla klienta do zapisania dodatkowych danych. W przypadku elementu WavePci domyślne założenie polega na tym, że kursor zapisu jest umieszczony na końcu ostatniego żądanego mapowania. Jeśli sterownik miniportu uzyskał dużą liczbę wybitnych mapowań, przesunięcie między kursorem odtwarzania i kursorem zapisu może być bardzo duże — wystarczająco duże, aby zakończyć się niepowodzeniem niektórych testów położenia dźwięku WHQL. W systemie Windows XP i nowszych interfejs IPreFetchOffset rozwiązuje te problemy.

Sterownik miniportu używa IPreFetchOffset do określenia właściwości prefetch sprzętu magistrali-master, które są w dużej mierze określane przez rozmiar FIFO tego sprzętu. Podsystem audio używa tych danych do ustawiania stałego przesunięcia między kursorem odtwarzania a kursorem zapisu. Stałe przesunięcie, które może być znacznie mniejsze niż domyślne przesunięcie, wykorzystuje fakt, że dane mogą być zapisywane w mapowaniu nawet po jego przekazaniu do sprzętu, pod warunkiem, że kursor odtwarzania znajduje się wystarczająco daleko od miejsca, w którym dane są zapisywane. (W tej instrukcji założono, że sterownik nie kopiuje ani w inny sposób nie manipuluje danymi w mapowaniach). Typowe przesunięcie może wynosić 64 próbki, w zależności od projektu silnika. Przy tak małym przesunięciu, sterownik WavePci może być w pełni responsywny i funkcjonalny, jednocześnie żądając dużej liczby mapowań.

Należy pamiętać, że DirectSound obecnie dopełnia kursor zapisu sprzętowo przyspieszanego pina o 10 milisekund.

Aby uzyskać więcej informacji, zobacz Przesunięcia Prefetch.

Przetwarzanie danych w mapowaniach

Jeśli to możliwe, należy unikać dotykania danych w mapowaniach przez sterownik sprzętu. Wszelkie oprogramowanie przetwarzania danych zawartych w mapowaniach należy podzielić na filtr oprogramowania oddzielony od sterownika sprzętu. Sprawienie, by sterownik sprzętowy wykonywał takie przetwarzanie, zmniejsza jego wydajność i powoduje problemy z opóźnieniami.

Sterownik sprzętowy powinien dążyć do przejrzystości w zakresie rzeczywistych możliwości sprzętowych. Sterownik nigdy nie powinien ubiegać się o zapewnienie obsługi sprzętowej transformacji danych, która jest faktycznie wykonywana w oprogramowaniu.

Prymitywy synchronizacyjne

Sterownik ma teraz i w przyszłości mniejsze prawdopodobieństwo wystąpienia problemów z zakleszczeniem lub wydajnością, jeśli jego kod został zaprojektowany tak, aby unikać blokowania, gdy tylko jest to możliwe. W szczególności wątek wykonywania sterownika powinien dążyć do ukończenia bez ryzyka wstrzymania podczas oczekiwania na inny wątek lub zasób. Na przykład wątki sterowników mogą używać funkcji Interlocked Xxx (na przykład zobacz InterlockedIncrement), aby zsynchronizować dostęp do niektórych wspólnych zasobów bez ryzyka blokady.

Mimo że są to zaawansowane techniki, możesz nie być w stanie bezpiecznie usunąć wszystkich spinlocków, muteksów i innych blokujących prymitywów synchronizacji ze ścieżki wykonywania. Używaj funkcjiInterlocked Xxx w sposób rozsądny z wiedzą, że oczekiwanie na czas nieokreślony może spowodować głodu danych.

Przede wszystkim nie twórz niestandardowych prymitywów synchronizacyjnych. Wbudowane elementy pierwotne systemu Windows, takie jak muteksy, blokady wirujące itp., mogą być modyfikowane w miarę potrzeby, aby obsługiwać nowe funkcje harmonogramu w przyszłości. Natomiast sterownik korzystający z niestandardowych konstrukcji ma prawie pewność, że nie będzie działać w przyszłości.

Interfejs IPinCount

W systemie Windows XP i nowszych interfejs IPinCount umożliwia sterownikowi miniportu dokładniejsze uwzględnienie zasobów sprzętowych, które są używane przez przydzielanie pinu. Wywołując metodę IPinCount::P inCount sterownika miniportu, sterownik portu wykonuje następujące czynności:

• Udostępnia bieżące liczniki pinów filtru (utrzymywane przez sterownik portu) do sterownika miniportu.

• Daje sterownikowi miniportu możliwość zmiany liczby numerów pin w celu dynamicznego odzwierciedlenia bieżącej dostępności zasobów sprzętowych.

W przypadku niektórych urządzeń audio, strumienie audio z różnymi atrybutami (3-D, stereo/mono itd.) mogą również mieć różne "wagi" ze względu na liczbę zużywanych zasobów sprzętowych. Podczas otwierania lub zamykania strumienia "lekkiego" sterownik zwiększa lub zmniejsza liczbę dostępnych pinów o jeden. Jednak podczas otwierania strumienia "wagi ciężkiej" sterownik miniportu może wymagać dekrementacji dostępnej liczby wyprowadzeń o dwie zamiast o jedną, aby dokładniej wskazać liczbę wyprowadzeń, które można utworzyć z pozostałymi zasobami.

Proces jest odwracany po zamknięciu strumienia wagi ciężkiej. Liczba dostępnych pinów może wzrosnąć o więcej niż jeden, aby odzwierciedlić fakt, że można utworzyć dwa lub więcej lekkich strumieni na podstawie nowo uwolnionych zasobów.