Opracowywanie sterownika WaveRT Miniport

W tym temacie przedstawiono kwestie związane z oprogramowaniem i sprzętem, które należy wziąć pod uwagę podczas opracowywania własnego sterownika miniportu WaveRT.

Firma Microsoft opracowała zestaw wytycznych dotyczących projektowania sprzętu dla architektury uniwersalnej audio (UAA), a wytyczne obejmują funkcje, które zalecamy dla urządzenia audio WaveRT. Wytyczne dotyczące UAA są ściśle oparte na specyfikacji dźwięku o wysokiej rozdzielczości (HD) opracowanej przez firmę Intel.

Systemy operacyjne Windows Vista i nowsze systemy operacyjne Windows udostępniają sterownik audio HD dla urządzeń audio zgodnych ze standardem UAA. Jeśli więc urządzenie audio jest zgodne ze standardem UAA, nie musisz opracowywać własnego sterownika miniportu WaveRT. Jednak w przypadku urządzeń audio, które mają zastrzeżone funkcje sprzętowe inne niż UAA, należy opracować własny sterownik miniportu WaveRT, aby obsługiwać zastrzeżone funkcje.

Aby ułatwić opracowanie własnego sterownika miniportu WaveRT, zalecamy najpierw przejrzenie przykładowego sterownika adaptera, a następnie przejrzenie funkcji UAA przystosowanych do WaveRT.

Przykładowy sterownik adaptera

Aby uzyskać informacje na temat przykładowego sterownika, zobacz Przykładowe sterowniki audio.

Funkcje przyjazne dla platformy WaveRT

Po przejrzeniu przykładowego sterownika adaptera i rozpoczęciu projektowania sterownika miniportu WaveRT należy sprawdzić, czy obsługuje on następujące funkcje oprogramowania i sprzętu. W rezultacie sterownik miniportu, który tworzysz, staje się zgodny z dostarczonym przez system sterownikiem portu WaveRT i trybem działania aparatu audio systemu Windows Vista.

• Małe opóźnienie sprzętu. Sterownik miniportu WaveRT musi zapewnić w pełni działającą implementację metody IMiniportWaveRTStream::GetHWLatency . Ta metoda jest niezbędna do obsługi właściwości KSPROPERTY_RTAUDIO_HWLATENCY .

• Przerwania FIFO. Sterownik miniportu WaveRT musi automatycznie generować przerwania, gdy występują przekroczenia i niedopełnienia FIFO. Ta funkcja umożliwia wykrywanie błędów w strumieniu audio podczas uruchamiania testów na urządzeniu audio i oprogramowaniu sterowników. Bez obsługi sprzętu (innymi słowy, przerwania FIFO) nie istnieje wygodna i niezawodna metoda uzyskiwania informacji o usterce.

• Scatter-Gather pętla DMA i buforów. Gdy sterownik miniportu obsługuje kontroler DMA, który ma możliwości rozproszonego zbioru, umożliwia przenoszenie danych do i z bufora cyklicznego bez konieczności interwencji przez sterownik miniportu.

  Gdy sterownik miniportu obsługuje kontroler DMA, który może wykonywać pętle buforu, kontroler DMA może automatycznie zawijać się na początku buforu, gdy operacja odczytu lub zapisu osiągnie koniec buforu. Może wykonać zawijanie bez interwencji ze strony sterownika miniportu.

  Należy pamiętać, że sterownik portu WaveRT obsługuje istniejące projekty sprzętowe, które nie mają możliwości wykonywania transferów typu scatter-gather ani automatycznych pętli buforowych.

  Jeśli urządzenie audio nie ma obsługi rozpraszania-zbierania, sterownik miniportu WaveRT musi najpierw przydzielić bufory cykliczne składające się ze stron, które są fizycznie ciągłe w pamięci. Sterownik miniportu używa następnie funkcji pomocnika w sterowniku portu WaveRT do wykonywania transferów danych i automatycznego zapętlania buforu. Wadą jest to, że ponieważ pula niestronicowanych pamięci systemu staje się coraz bardziej rozdrobniona, żądanie przydzielenia dużego bloku ciągłej pamięci fizycznej jest bardziej narażone na niepowodzenie. Urządzenie z funkcją scatter-gather nie jest narażone na wpływ fragmentacji pamięci.

  Jeśli urządzenie audio nie może automatycznie wykonywać pętli buforu, gdy kanał DMA osiągnie koniec buforu cyklicznego, sterownik miniportu WaveRT musi interweniować i skonfigurować kanał, aby rozpocząć transfer danych na początku buforu.

• Pozycje rejestrów. W przypadku nowych projektów implementatory sprzętu powinny zawierać rejestr pozycji dla każdego kanału DMA. Rejestr położenia wskazuje bieżącą pozycję buforu jako przesunięcie bajtu od początku buforu cyklicznego. Odczyt rejestru pozycji wynosi zero na początku buforu. Gdy rejestr pozycji osiągnie koniec buforu cyklicznego, automatycznie wraca na początek buforu (resetuje się do zera) i nadal zwiększa się wraz z postępem pozycji w buforze.

  Rejestry pozycji można mapować na pamięć wirtualną, aby klienci mogli bezpośrednio odczytywać rejestry.

  W idealnym przypadku rejestry położenia powinny wskazywać położenie buforu próbek, które są obecnie przenoszone przez konwertery cyfrowe i analogowo-cyfrowe (DACs i ADC) urządzenia audio.

  Jednak te informacje mogą nie być bezpośrednio dostępne z układu audio, który dzieli funkcje cyfrowe i analogowe na oddzielne układy kontrolera magistrali i kodera/dekodera (kodeka). Zazwyczaj rejestry położenia znajdują się w mikroukładie kontrolera magistrali, a każdy rejestr wskazuje położenie danych dźwiękowych, do których kontroler zapisuje dane lub odczytuje je z koderów.

  Po uzyskaniu odczytu z tego typu rejestru pozycji klient może oszacować bieżące położenie próbek przechodzących przez DAC lub ADC, dodając lub odejmując opóźnienie wprowadzane przez codek. Klient uzyskuje opóźnienie kodeka z żądania właściwości KSPROPERTY_RTAUDIO_HWLATENCY. Z tego powodu sterownik miniportu WaveRT musi dokładnie zgłosić opóźnienie kodera, gdy sterownik portu wywołuje metodę IMiniportWaveRTStream::GetHardwareLatency w odpowiedzi na tego typu żądanie właściwości.

  Należy pamiętać, że sterownik portu WaveRT obsługuje istniejące projekty sprzętu, które nie mają rejestrów pozycji. W przypadku urządzenia z tym ograniczeniem sterownik miniportu WaveRT musi zakończyć się niepowodzeniem przy wywołaniach metody IMiniportWaveRTStream::GetPositionRegister, zwracając kod błędu STATUS_NOT_SUPPORTED, co wymusza, aby sterownik portu nie realizował żądań właściwości KSPROPERTY_RTAUDIO_POSITIONREGISTER. W takim przypadku klienci muszą uzyskać bieżące położenie za pośrednictwem właściwości KSPROPERTY_AUDIO_POSITION, co wiąże się z obciążeniem związanym z przejściem między trybem użytkownika a trybem kernela dla każdego odczytu pozycji.

• Rejestr zegara. Rejestr zegarowy jest opcjonalną, ale przydatną funkcją sprzętową dla urządzenia audio zgodnego z platformą WaveRT. Programy aplikacji audio mogą używać rejestrów zegarowych do synchronizowania strumieni audio w co najmniej dwóch niezależnych urządzeniach audio, które mają oddzielne i niezsynchronizowane zegary sprzętowe. Bez rejestrów zegarowych aplikacja nie może wykryć i zrekompensować dryfu między zegarami sprzętowymi.

  Częstotliwość próbkowania, której sprzęt audio używa do synchronizacji danych audio za pośrednictwem przetworników cyfrowo-analogowych lub analogowo-cyfrowych, powinna pochodzić z wewnętrznego zegara, który odpowiada za przyrost rejestru zegara. Rejestr zegara, który zwiększa się w tempie asynchronicznym w odniesieniu do zegara próbki, nie jest używany do synchronizacji i nie powinien być uwidoczniony.

  Podobnie jak rejestry pozycji, rejestr zegarowy można mapować na pamięć wirtualną, aby klienci mogli odczytać rejestr bezpośrednio.

• Obiekty przetwarzania audio. Dobrze zaprojektowany sterownik miniportu WaveRT nigdy nie musi dotykać danych audio w cyklicznym buforze urządzenia audio. Sprzęt powinien być zaprojektowany tak, aby dane audio przepływały bezpośrednio między klientem a sprzętem audio bez interwencji oprogramowania sterownika audio.

Obiekty przetwarzania dźwięku są dostępne tylko w przypadku strumieni audio w trybie współdzielonym. W przypadku strumieni w trybie wyłączności, aplikacje wymieniają dane bezpośrednio z urządzeniami sprzętowymi WaveRT za pośrednictwem cyklicznych buforów, a żadne inne składniki nie mogą przetwarzać danych w tych buforach.

Aby uzyskać więcej informacji, zobacz Obiekty przetwarzania dźwięku systemu Windows.