a) Was ist eine Schichtenstruktur und wozu wird sie benötigt ?[1]

Werden Daten einer Anwendung in peripherer Hardware weiterverarbeitet, stellt sich das Problem, dass eine Vielzahl von Geräten angeschlossen sein kann, welche alle unterschiedlich angesprochen werden müssen. Hier bietet sich an, das Programm durch eine allgemeine Schnittstelle unabhängig von der angeschlossenen Hardware zu machen und damit gleichzeitig die Programmentwicklung zu vereinfachen.

Dies kann durch die Einführung mehrerer Abstraktionsebenen erreicht werden. Jede Ebene bietet hierbei einen höheren Abstraktionsgrad im Vergleich zu den darunterliegenden. D.h. die Funktionen auf höherer Ebene sind allgemeiner und unabhängiger von der untersten Ebene.

Betriebssysteme bieten daher häufig eine einheitliche Schnittstelle zu den Gerätetreibern einer bestimmten Geräteart (z.B. Sound oder Grafik oder Netzwerk etc.). Wo diese Abstraktionsebene im System integriert ist, hängt vom System ab. Unter UNIX werden alle Hardware-Einheiten wie Dateien angesprochen und verwaltet. Diese abstrakte Sichtweise hat den Nachteil, dass kaum gerätespezifische Funktionen vom System bereitgestellt werden. Mithin werden alle speziellen Gerätefunktionen UNIX durch den Aufruf „Fcntrl“ angesprochen.

In modernen Multimedia-Betriebssystemen wie Windows mit DirectX oder MacOS mit Quicktime stellt das Betriebssystem dagegen eine breite Hardware-Schnittstelle zur Verfügung. Über diese Schnittstellen wird ein großes, kaum lösbares Problem durch Schnittstellen in viele kleine, einfach zerlegt und kann damit gelöst werden. Der Programmierer muß sich nur noch um die speziellen Eigenschaften seines Programmes kümmern und nicht mehr die allgemeinen Implementierungsprobleme auf unterster Ebene lösen.

 

Folgende Grafik zeigt ein allgemeines Konzept der Abstrahierung in Betriebssystemen.

Quelle: Steinmetz, http://www.et-online.fernuni-hagen.de/lehre/k02415.ws/kap16/1601.htm

 

 

b) Foundation Layer und Media Layer

Seit der DirectX Version 5 sind die DirectX-Komponenten in zwei Schichten unterteilt:[2]

           

                                                DirectX Media

 

                                          DirectX Foundation

           

                            Hardware

 

Die Einteilung der Komponenten in die beiden Schichten erfolgte dabei nach Zugehörigkeit zur Software bzw. zur Hardware. D.h. die Komponenten des Foundation-Layers arbeiten enger mit der Hardware zusammen, während die des Media-Layers überwiegend spezielle software-mäßig implementierte Funktionen enthalten. Teilweise greifen die Komponenten des Media-Layers auch auf die unter ihm liegenden des Foundation-Layers zurück.

 

(1) DirectX-Foundation

Die DirectX-Foundation stellt auf Basis von Low-Level-Funktionen den Hardware Abstraction Layer (HAL) zur Verfügung, der die Anwendungen mit der Hardware verbindet. Microsoft bezeichnet diese Schicht auch als „System-Layer“. Die Foundation enthält die folgenden Komponenten: DirectDraw, Direct3D, DirectInput, DirectSound, DirectMusic, DirectPlay, DirectSound3D.

 

Grafik: DirectX Low-Level System-Layer

(Quelle: http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/dnardxgen/html/msdn_dx5media.asp)

 

(2) DirectX-Media

DirectX-Media ist die obere Schicht. Sie bietet Anwendungen “höhere Dienste”, wie Animation, Mediastreaming und Interaktivität an und bedient sich dabei ggf. des DirectX-Foundation Layers. Microsoft nennt diese Schicht den „Application-Layer“. Sie besteht aus den folgenden Komponenten: DirectModel, DirectShow, Direct3D Retain Mode,VRML und DirectPlay.

 

Grafik: DirectX High-Level Application Layer

Quelle: http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/dnardxgen/html/msdn_directx5.asp

 

c) Abstrahierung von der Hardware in DirectX

Insbesondere Grafik-, Video- und Soundkarten enthalten zunehmend Prozessoren, die spezielle beschleunigte low-level-Funktionen anbieten und damit die CPU des PCs entlasten können.

Dabei stellt sich folgendes Problem: jeder Hardwarehersteller bietet diese Funktionen für seine verschiedenen Modelle in unterschiedlichem Umfang an. Wie kann nun der Entwickler garantieren, dass sein Programm unter Windows möglichst mit jeder Hardware-Kombination funktioniert ? D.h. wie können durch hardware-unabhängige Programmierung hardware-abhängige Features möglichst optimal angesteuert werden.

Dies löst DirectX durch die Einführung von zwei Schichten: dem Hardware Abstraction Layers (HAL) und dem Hardware Emulation Layers (HEL).

Die Funktionen, die DirectX zur Verfügung stellt, stehen auf einer hardwareunabhängigen Schicht. Der Programmierer ist also von der speziellen Hardware und ihren Eigenschaften isoliert. Das heißt: die DirectX-Elemente sind von der Hardware abstrahiert. Unter dieser Ebene bilden die Gerätetreiber der Hersteller die Schnittstelle zwischen HAL und der Hardware.

Folgende Grafik zeigt, wie auf die Hardware über drei verschiedene Pfade zugegriffen werden kann. Es ist ein Zugriff über die Standard-Windows Wave-API möglich. Außerdem kann über die Hardware Emulation (HEL) oder den DirectSound HAL zugegriffen werden.

Grafik: aus MS DirectSound Windows DDK

 

(1) Der HAL

Der HAL in DirectX bietet neben einem einheitlichen Zugriff auf die Hardware, zusätzlich einen sehr direkten und damit sehr schnellen Zugriff. Das Prinzip des HALs gibt es nicht nur in DirectX. Auch in Windows 2000/XP gibt es einen ähnlichen HAL. Er dient allerdings fast ausschließlich der Vereinheitlichung des Zugriffs auf die Hardware, also der Hardware-Unabhängigkeit und nicht der Leistungssteigerung. Die folgende Grafik zeigt, wieviele Schichten innerhalb des HAL in Windows 2000 durchlaufen werden, bis auf die Hardware zugegriffen werden kann.

 

 

Grafik: Der HAL in Windows 2000

Quelle: Tanenbaum, Modern Operating Systems

 

(2) Der HEL

Der HEL emuliert softwaremäßig eine Reihe von Hardware-Funktionen. Diese Funktionen können vom Programmierer für die Entwicklung, das Debugging, einen Leistungstest und die Emulation zur Laufzeit verwendet werden. Es ist damit sichergestellt, dass die Anwendung auf jedem PC unabhängig von der installierten Hardware die gleichen Fähigkeiten hat. Möglicherweise geht diese Kompatibilität aber zu Lasten der Performance, da jetzt die CPU die Arbeit von spezialisierter Beschleunigungs-Hardware übernehmen muß.

Im Soundbereich sind alle Funktionen über die HEL in voller Qualität – nur abhängig von der CPU-Leistung - verwendbar. Im Grafikbereich sind aufgrund der deutlich aufwendigeren Berechnungen hingegen nur Teile als Emulation verfügbar, da die CPU-Leistung sonst zu stark einbrechen würde.

Da DirectSound während der Programmlaufzeit bei der Hardware nachfragen kann, welche Features sie beschleunigend unterstützt, ist es für Hochleistungssoftware möglich ihren Leistungsumfang entsprechend der vorhandenen Hardware zu skalieren, um auf einem System höchste Leistung und einem anderen eine abgeschwächte Leistung, aber in jedem Fall einen reibungslosen Betrieb zu gewährleisten.[3] So könnte z.B. eine Echtzeit-Tonstudio-Software nicht 16 Spuren, sondern nur 8 Spuren bei ansonsten gleichem Leistungsumfang zur Verfügung stellen.

 

Die folgende Grafik zeigt einen Ausschnitt aus den DirectX-Eigenschaften, die zur Laufzeit abgefragt werden können – hier mit dem DirectX-Programm DXCapsViewer.exe.

 

 

Die HEL hat einen weiteren großen Vorteil bei der Anwendungsentwicklung. Weit bevor Hardware rauskommt, die bestimmte Funktionen umsetzt, kann im HEL schon eine Softwarelösung eingebaut werden. D.h. die Anwendungsentwickler können schon für eine Hardware entwickeln und testen, welche vielleicht erst mit der Veröffentlichung der Anwendung oder noch später auf den Markt kommt. So hatte beispielsweise DirectX bereits vor Erscheinen der MMX-Prozessoren einen MMX-Software-Emulator.

 

(3) Zusammenarbeit zwischen HAL, HEL und Standard-Audio-Gerätetreiber

Beim Start des DirectX-Programms werden alle angeschlossen DirectX-tauglichen Geräte über Callback-Funktionen aufgezählt und ausgewählt. DirectX kann nun erkennen, ob die Features seiner Komponenten von einem Gerät hardwaremäßig implementiert sind oder nicht. Sind diese implementiert, werden sie von DirectX direkt angesteuert. Ist ein DirectSound-Gerätetreiber nicht vorhanden, kommuniziert DirectSound mit der Audio-Hardware über den Standard-WaveOut-Gerätetreiber. Alle DirectSound-Features sind dann per Software-Emulation verfügbar.[4]

 

Im DirectX-Setup kann die Emulation explizit eingestellt werden:

Name der Einstellung	Inhalt
Full	Volle Hardwarebeschleunigung
Standard	Hardwarebeschleunigung nur beim Secondary Buffer Mixing
Basic	Verwendet HEL + DirectSound-API
Emulation	Verwendet HEL + WaveOut-API

 

(4) Gerätetreiber

Zusätzlich zu den von Microsoft gelieferten DirectX-Modulen müssen die Hardwarehersteller die Gerätetreiber liefern, die direkt die Schnittstelle zwischen DirectX und der Hardware bilden. Während früher die Softwareentwickler unter MS-DOS auch auf dieser Ebene programmieren mußten (siehe oben), ist dieser Aufgabenbereich also jetzt wieder bei den Leuten, die sich am besten damit auskennen sollten: den Herstellern der Hardware selbst.

Der Gerätetreiber auf Seite der Soundkartenhersteller hat im Rahmen von DirectX folgende Aufgaben:

-         die Fähigkeiten des Gerätes an DirectSound melden

-         Anfordern und Freigeben der Steuerung über die Audio-Hardware

-         DirectSound-Anfragen an dieses Gerät weiterleiten

(5) Installation von DirectX

Kommt eine neue DirectX-Version heraus, ist ein Update zu empfehlen, da die neue Version möglicherweise besser auf die vorhandene Hardware abgestimmt ist. Beispielsweise wurde DirectX durch die Unterstützung von MMX deutlich schneller. Dies allerdings nur, wenn man damals ein entsprechendes Update installiert hat.

Es ist nicht notwendig, DirectX oder eine Anwendung, die DirectX nutzt, neu zu installieren, wenn ein neue Hardware eingebaut wurde. DirectX prüft erst zur Laufzeit die vorhandenen Fähigkeiten.

Damit unterscheidet es sich vom Unix-Betriebssystem, wo alle Treiber mit dem Booten des Betriebssystems geladen werden. Dort handelt es sich zwar um optimierte Treiber, eine Skalierung an die vorhandene Hardware ist aber nicht möglich.

(6) Löst DirectX mit der HEL alle Performance-Probleme ?

Durch DirectX steht ein breites Spektrum an Multimedia-Funktionen auf (fast) jedem Windows-PC unter zwei Bedingungen zur Verfügung:

1)      die aktuelle DirectX-Version muß auf dem System installiert sein

2)      je weniger Features die Hardware implementiert hat, desto langsamer läuft das System.

Der erste Punkt ist insofern kein Problem, als DirectX zum kostenlosen Download im Internet zur Verfügung steht oder bei der Installation der Anwendung automatisch mitinstalliert werden kann. Allerdings kann es möglicherweise Konflikte mit dem Gerätetreiber geben, wenn dieser zur neuen DirectX-Version nicht kompatibel sein sollte.

Der zweite Punkt widerspricht dem ursprünglichen Gedanken von DirectX, die Leistung des Systems steigern zu wollen. Mit der Leistungsfähigkeit der Prozessoren sind aber auch die Ansprüche im Bereich der Multimedia-Anwendungen stark gestiegen. Der HEL bietet zwar die Möglichkeit viele Multimedia-Funktionen ohne spezielle Hardware nutzen zu können, dies aber zu Lasten der CPU-Leistung. Zudem erfordert das Durchlaufen von mindestens zwei Schichten (eine DirectX-Komponente und HAL oder HEL) immer noch mehr Zeit als ein direktes Beschreiben der Hardware wie es unter DOS möglich war.

Ist die Hardware nun veraltet, geht die Leistung und/oder die Qualität bei skalierbaren Funktionen letztlich auf Grund des großen Funktionsumfangs von DirectX verloren. Will man in den Genuß aktueller 3D-Grafik und sämtlicher Audio-Möglichkeiten gelangen, kommt man nicht um neue Hardware mit beschleunigenden, intelligenten Spezial-Prozessoren.

Ein Beispiel für die Leistungsfähigkeit dieser Spezial-Prozessoren liefert Microsoft im DirectX7-SDK. Ein absolut optimiertes Demoprogramm unter Windows emuliert einige moderne 3D-Grafikfunktionen, die in der Grafikhardware noch nicht implementiert sind. Der damals im Test verwendete Pentium III-500 MHz brachte es dabei auf gerade mal 0,5 fps[5]. Ein normales Computerspiel, welches um den Faktor 50 komplexer als dieses Demoprogramm ist und mindestens 40fps bringen soll, benötigt also einen Prozessor, der die zweitausendfache Geschwindigkeit (=1000 GHz) liefern müßte. Dem gegenüber sind einige 100 von der PC-CPU vorbereitende Befehle zu vernachlässigen.[6]

 

d) Ring-Struktur von Intel[7]

(1) Aufbau der Ring-Struktur

Intel-Prozessoren ab dem 80386er verwenden für ihre Prozessverwaltung eine Ringstruktur mit den Ringen 0 bis 3. Diese Ringe dienen dazu, Privilegien für die auf den Ringen laufenden Prozesse abgestuft vergeben zu können.

Ring 0 ist dabei der höchst privilegierte Ring, auf welchem alle Instruktionen und direkter Hardwarezugriff möglich sind. Die Komponenten auf diesem Ring sind besonders geschützt. Auf Ring 3 laufen die am wenigsten privilegierten Prozesse.

Nachteil dieses Konzepts ist, dass ein Funktionsaufruf in einem anderen Ring bis zu 10x so lange braucht wie im gleichen Ring.

(2) Ring-Struktur unter Windows

Windows verwendet nur zwei Ringe:

-         Ring 3 (User-Mode)

-         Ring 0 (Kernel-Mode)

Da es jetzt nur noch einen Ringübergang gibt, wird erheblich Zeit gespart.

Grafik: Ring-Modell ab dem 80386er unter Windows

(Quelle: MS Windows 2000 –DDK)

(3) Bedeutung für DirectX

Mit der Einführung von Windows 2000 bietet Windows zwei Treibermodelle an:

-         das Standard Windows Treiber-Modell

-         das Win32-Driver-Model (WDM)

Letzteres bietet die Möglichkeit einen einheitlichen Treiber für Windows 98, ME, 2000 und XP zu schreiben. Je nach Verwendung des einen oder anderen Modells, ist DirectSound auch unterschiedlich im System integriert.

(a) DirectSound im Standard Windows-Treiber-Modell

Das Standard Windows-Treiber-Modell verwendet den virtuellen Gerätetreiber dsound.vxd im Kernel-Mode (Ring 0) ohne weitere Ring-3-Komponenten für das Abmischen des Sounds. Diese VxD-Datei enthält in der Regel auch den Standard Windows 95-Wave Gerätetreiber.

Dieses Modell bietet einen schnellen und direkten Hardwarezugriff. Die Abtastfrequenz des Primärpuffers kann dabei manuell eingestellt werden.

DirectSound und Standard-WaveOut können hier nur alternativ angesteuert werden. Es sei denn, es sind mehrere Soundkarten installiert.

(b) DirectSound im WDM

Im WDM ist der kmixer für die Soundwiedergabe verantwortlich.  Der Hardwarezugriff erfolgt hier nicht so direkt und daher langsamer. Die Abtastfrequenz wird zudem selbständig vom kmixer eingestellt. Alle Windows-Audio-Daten (und nicht nur die DirectSound-Daten) werden hier abgemischt. Gegenüber dem dsound.vxd bieter der kmixer zudem ein Multichannel und High-Resolution-Mixing an.

Die folgende Grafik zeigt die Einbettung von DirectSound in die WDM-Struktur.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

(Quelle: MS Windows 2000 DDK)

Man sieht deutlich die gestiegene Anzahl der Komponenten, die von der Anwendung bis zur Wiedergabe des Sounds durchlaufen werden muß (dsound.dll -> sysaudio.sys -> kmixer.sys ->portcls.sys bzw. stream.sys bzw. dmusic.sys). Ganz oben ist der Übergang vom User- in den Kernel-Mode zu erkennen. Der dmusic.sys ist der Synthesizer, der die MIDI bzw. DLS2-Sounds generiert. Nachteilig ist also bei diesem Modell die zusätzliche Zeit, die durch den Kmixers benötigt wird. Wie lang diese Zeit dauert, ist der Literatur nicht eindeutig zu entnehmen.[8]

Vorteil dieses Modells neben der Einheitlichkeit ist, dass gleichzeitig die Standard-WaveOut-API und die DirectSound-API verwendet werden können. Anders als beim Win32-Modell schließen sich die Pfade nicht gegenseitig aus.

Wegen der einfacheren Entwicklung und der größeren Flexibilität geht die Tendenz daher hin zu WDM-Treibern.[9]

 

e) DirectSound / DirectMusic-Architektur

Folgende Grafik zeigt unabhängig vom WDM-System grob die Zusammenarbeit zwischen DirectMusic und DirectSound:

Quelle: MS DirectXAudio 8.0 SDK

 

DirectMusic dient der Klangerzeugung, während DirectSound danach das Abmischen, die 3D-Positionierung und das Hinzufügen von Spezialeffekten steuert.

Der genauere Ablauf wird unten im Bereich der Interaktionsmodelle noch genauer erläutert.

 

f) DirectSound-Puffer

(1) Allgemein

Die DirectSound-Puffer (engl. Buffer) befinden sich ganz am unteren Ende der DirectXAudio-Schichten. Sie führen den finalen Tonmix aus und fügen gegebenenfalls Spezialeffekte hinzu. Es gibt drei verschiedene Puffer, welche alle PCM-Daten verarbeiten:

 

Sink-in Buffers (=secondary sound buffer)	Konvertieren das Datenformat und stellen u.a. die Lautstärke, die Position L/R bzw. im 3D-Raum ein
Mix-in Buffers (=secondary sound buffer)	Wenden Spezialeffekte (Hall, Echo) an
Primary Buffer	Führt den finalen Soundmix aus und gibt die Daten an die Ausgabe der Soundkarte weiter. Sind alle Sounds im gleichen Wave-Format, wird der Mix am schnellsten ausgeführt.

 

Die sekundären Puffer führen alle auf einen primären Puffer, wie die folgende Grafik zeigt:

 

Quelle: http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/dnarsound/html/msdn_optaudi1.asp

 

Ein Sound geht nicht zwingend nur durch einen Puffer. Er kann auch durch eine ganze Reihe von Puffern, die jeweils spezielle Effekte anwenden, laufen („Buffer Chains“). Verschiedene Sounds können auch gemeinsam durch einen Puffer laufen. Solche „Shared Buffers“ sind insbesondere, wenn sie im 3D-Modus arbeiten, sehr viel effizienter als parallel geschaltete Puffer.

Die Anzahl der DirectSound Puffer ist nur begrenzt durch die CPU-Leistung und die Leistung der Soundkarte.

Mehrere Applikationen können jeweils in sekundäre Soundpuffer schreiben, welche dann gemeinsam im primären Soundpuffer gemixt werden (siehe dazu auch Kooperationsebenen).

 

(2) Soundpuffer-Typen

Zu unterscheiden ist zwischen Static und Streaming Buffers. Ein Static Buffer enthält einen oder mehrere kompletten Sounds. Er ist insbesondere sinnvoll, wenn ein kurzer Sound häufiger verwendet werden soll (z.B. ein Gewehrschuß).

Ein Streaming Buffer ist eine Ringspeicherstruktur, in die der Sound Stück für Stück an der aktuellen Schreibposition hereingeschrieben wird, während an der Abspielposition im Ring die Wiedergabe läuft. Diese Positionen werden als Byte-Offset relativ zum Beginn des Ringpuffers gespeichert.

Im Ringpuffer ist es möglich bestimmte Stellen zu definieren, an denen Benachrichtigungen verschickt werden, z.B. weil sich das Ende des Sounds nähert.

Grafik: Ringspeicherstruktur (Quelle MS DirectX 8.0 SDK)

(3) Das Mischen über DirectSound-Puffer

Warum ist das Zusammenmischen von Sounds so ein kritischer Punkt ?

Multimediaanwendungen allgemein und insbesondere Spiele oder Musiksoftware mischen häufig 10 oder noch mehr Spuren gleichzeitig ab (Hintergrundmusik, Sounds von Explosionen, Monstern, Gewehrschüssen, Warnungen, etc. oder das Abspielen einer 16-spurigen Bandaufnahme). Auf einem 90MHz-Pentium bedarf das Mischen von 8-Audiospuren bereits etwa 50% der CPU-Leistung. Wegen dieses hohen Leistungsbedarf muß der Vorgang des Mischens genau geplant sein. Am besten wird auch hier eine Hardwarebeschleunigung verwendet.

 

In DirectX gestaltet sich das Mischen nun folgendermaßen. Der erste von DirectX angelegte Puffer ist ein Primärer Soundpuffer. Ein weiterer sekundärer Puffer muß aber in jedem Fall angelegt werden. Ein Puffer kann entweder in Hardware oder Software implementiert sein. Hardware-Puffer werden von der Soundkarte gemixt, Software-Puffer von der CPU des Rechners. Softwarepuffer liegen im Arbeitsspeicher des Rechners, Hardwarepuffer können im On-card-Speicher der Soundkarte (so meist bei ISA-Karten) oder im Arbeitsspeicher des Rechners (so meist bei PCI-Karten, die direkt über PCI auf den ASP zugreifen können) liegen.

Vorteil des Hardware-Mischens ist, dass die CPU entlastet wird. Nachteilig ist allerdings, dass die Busse erheblich belastet werden. Während dies beim PCI-Bus kein Problem ist, eignet sich der ISA-Bus nur sehr schlecht für das Mischen von vielen Streaming Audiospuren gleichzeitig. Zwar reduziert der Direct Memory Access (DMA) den CPU Overhead. Bei der Menge an Daten kann die CPU dennoch schnell mit dem Datentransfer überlastet werden.

Um den Bus nicht unnötig zu belasten, haben ISA-Soundkarten daher häufig einen eigenen RAM-Speicher auf der Karte, der für Static Soundbuffer genutzt werden kann. Zwischen diesen kann auch auf ISA-Karten ein Hardware-Mix durchgeführt werden.

 

 

g) Gleichzeitige Hardwarezugriffe auf ein Gerät und Kooperationsebenen

Ein Multitasking-System bietet die Möglichkeit, dass mehrere Prozesse gleichzeitig auf ein Gerät zugreifen. Fraglich ist nun, wie sich in dem Fall die Soundausgabe verhalten soll. Dies wird durch den Programmierer über das Setzen von Kooperationsebenen („cooperative levels“) bestimmt.

Jedes DirectSound Programm hat dabei eine Kooperationsebene. Die Kooperationsebene für DirectXAudio hat 3 Level:

1)      Normal Level

2)      Priority Level

3)      Write-primary Level

 

(1) Priority Level

Verwendet ein Anwendung ein Sounddevice im Priority Level, darf sie Änderungen an den Einstellungen des Geräts vornehmen. Folgende Änderungen sind möglich:

-         Setzen des Ausgabeformates (KHz)

-         Umschalten zwischen Mono- und Stereosound

-         Setzen der Sample-Rate

Anwendungen im Priority Level können außerdem Sound auch dann ausgeben, wenn andere Anwendungen gleichzeitig Sound abspielen. Der Sound wird hier in den sekundären Soundpuffer geschrieben und von dort aus über DirectX automatisch in den primären Soundpuffer zur Ausgabe gepackt.

Für die meisten Anwendungen wird der Priority Level die richtige Einstellung sein.

(2) Normal Level

Eine Anwendung im Normal Level kann am primären Soundpuffer, also dem Puffer, der für die Soundausgabe verantwortlich ist, im Gegensatz zum Priority Level keine Änderungen vornehmen. Es kann also nur direkt in den sekundären Soundpuffer geschrieben werden. Außerdem wird immer das Ausgabeformat 22 KHz bei 8-Bit-Samples verwendet.

Das Normal Level ermöglicht ein konfliktfreies Umschalten zwischen mehreren Anwendungen.

(3) Write-Primary Level

Im Write-Primary Level dürfen die Anwendungen, die den Eingabefokus haben, direkt in den primären Soundpuffer schreiben. Alle anderen Anwendungen, die nur in den sekundären Soundpuffer schreiben, können während dieser Zeit keinen Sound ausgeben und verlieren gegebenenfalls sogar Daten, die sie bereits in den sekundären Soundpuffer geschrieben haben. Generell müssen also Anwendungen in diesem Fall damit rechnen, dass durch andere Anwendungen ihre Sounddaten nicht sofort ausgegeben oder sogar gelöscht werden.

Wird die Anwendung im Write-Primary Level in den Hintergrund gesetzt, verliert sie den primären Soundpuffer, und muß ihn wieder aufbauen, wenn sie wieder in den Vordergrund gelangt.

(4) Sticky / Non-Sticky

Weiter kann man einstellen, ob eine Anwendung auch noch Audio ausgeben können soll, wenn sie den Fokus verliert. Soll dies nicht der Fall sein, ist der Soundpuffer auf „sticky“ (klebrig) einzustellen. D.h. die Soundausgabe „klebt“ am Anwendungs-Fokus.