Kombinieren von benutzerdefinierten und Windows-APOs

Audioverarbeitungsobjekte (APOs) bieten anpassbare softwarebasierte digitale Signalverarbeitung für Windows-Audiostreams. Es ist möglich, von Microsoft bereitgestellte APOs mit Partner-entwickeltem Code zu kombinieren sowie die vorhandene Funktionalität einzuhüllen und anzupassen.

In diesen Themen finden Sie allgemeine Informationen zu APOs.

• Architektur des Audioverarbeitungsobjekts
• Implementieren von Audioverarbeitungsobjekten
• Implementieren von Hardware-ausgelagerten APO-Effekten

APOs wurden erstmals in Windows Vista eingeführt, und Möglicherweise werden Verweise auf die früheren System-APOs – sAPOs – angezeigt. Weitere Informationen finden Sie im Whitepaper "Benutzerdefinierte Audioeffekte" in Windows Vista . Dieses Whitepaper kann auf ältere Themen zur COM- und UI-Entwicklung verweisen.

Kombinieren von benutzerdefinierten und Windows-APOs

Dieser Abschnitt enthält Richtlinien für die Implementierung benutzerdefinierter Audioverarbeitungseffekte-APOs, indem man eine dünne Hülle um das entsprechende APO erstellt. Benutzerdefiniert APO bezieht sich auf die Implementierung des APO durch den IHV.

Es gibt zwei Arten von APOs, SFX (Stream) und MFX (Mode). In Windows 8.1 wurden SFX als LFX (lokal) und MFX als GFX (global) APOs bezeichnet.

IHVs können benutzerdefinierte Audiosystemeffekte-APOs implementieren, um entweder oder beide der benutzerdefinierten Windows SFX- und MFX-Audiosystemeffekte-APOs zu ersetzen. Im Allgemeinen haben IHVs oder OEMs zwei grundlegende Strategien zum Kombinieren von benutzerdefinierten Audiosystemeffekt-APOs mit den VON Windows bereitgestellten APOs. Diese Strategien bieten den IHVs Flexibilität, wie sie ihre benutzerdefinierten Effekte mit denen von Windows integrieren.

Ersetzen

Entwickeln Sie ein detailliertes Verständnis des Windows-APO, das Sie ersetzen möchten, und deren Features. Verwenden Sie dieses Verständnis, um ein benutzerdefiniertes APO zu implementieren, das das Windows-APO auf eine Weise aufruft, die für die IHV aus der Perspektive der Zielbenutzererfahrung am sinnvollsten ist. Diese Strategie eignet sich am besten für IHVs oder OEMs, die:

• Integrieren Sie ihre benutzerdefinierten Effekte nahtlos in die Windows-Effekte.
• Implementieren Sie ihre eigene Benutzeroberfläche, um ihre Effekte und die effekte zu steuern, die von den Windows-APOs implementiert werden.

Weitere Informationen zum Schreiben eines APO finden Sie unter Windows Audio Processing Objects.

Dünner Wrapper

Schreiben Sie das benutzerdefinierte APO als dünne Hülle um das Windows-APO. Diese Strategie eignet sich am besten für IHVs oder OEMs, die:

• Fügen Sie ihre benutzerdefinierten Effekte so einfach wie möglich hinzu.
• Lassen Sie die Windows-Benutzeroberfläche die Effekte weiterhin steuern.

IHV oder OEMs, die die Option "Strategie" für die dünne Wrapperoption auswählen, sollten weiterhin Windows-Audioverarbeitungsobjekte überprüfen, um ein gründliches Verständnis der benutzerdefinierten Windows-Audiosystemeffekte zu erhalten.

Hinweis: Mit der dünnen Wrapperstrategie können IHVs keine Benutzeroberfläche hinzufügen, um ihre hinzugefügten benutzerdefinierten Audiosystemeffekte auf der Registerkarte "Windows-Verbesserungen" zu steuern. Es gibt nur eine Registerkarte "Verbesserungen", und sie muss der Eigenschaftenseite für die Windows-APOs zugeordnet bleiben. Die Benutzeroberfläche der IHV muss auf andere Weise implementiert werden, z. B. eine separate Systemsteuerungsanwendung.

Programmierinformationen

In diesem Abschnitt werden die allgemeinen Programmierprobleme dargelegt, die behandelt werden müssen, um ein benutzerdefiniertes APO zu implementieren.

Sowohl SFX(Stream) als auch MFX(Mode)-APOs für benutzerdefinierte Audiosystemeffekte weisen die folgenden allgemeinen Merkmale auf:

• Sie müssen als COM-In-Process-Serverobjekte registriert werden, die mithilfe von CoCreateInstance instanziiert werden können.
• Die CLSIDs sind CLSID_CWMAudioLFXAPO für die SFX- bzw. CLSID_CWMAudioGFXAPO für die MFX-APOs. Die CLSIDs werden in wmcodecdsp.h deklariert und in wmcodecdspuuid.lib definiert.
• Sie müssen die COM-Aggregation unterstützen. Es wird jedoch nicht erwartet, dass die Aggregation im Szenario mit benutzerdefinierten Audiosystemeffekten verwendet wird, sodass es keine signifikanten Probleme darstellen sollte.

Initialisierung

Ein benutzerdefiniertes APO muss das Window APO initialisieren, indem die IAudioSystemEffects::Initialize-Methode aufgerufen wird. Dies erfolgt in der Regel über die Initialize-Methode des benutzerdefinierten APO. Alle Argumente, die an die Initialize-Methode des benutzerdefinierten APO übergeben werden, sollten direkt an die Initialize von Windows APO übergeben werden. Auf diese Weise kann das APO seine Einstellungen vom Endpunkt und Fx-Eigenschaftsspeicher in der APOInitSystemEffects-Struktur abrufen. Es ist möglich, dass das benutzerdefinierte APO die Einstellungen abruft und sie selektiv an das APO übergibt, aber das ist im Wesentlichen Strategie A.

Wenn das benutzerdefinierte APO ein Feature ersetzt, empfiehlt es sich im Allgemeinen, das entsprechende Feature auf dem APO zu deaktivieren. Je nachdem, wie das Feature funktioniert, ist das Deaktivieren des Features möglicherweise nicht unbedingt erforderlich. Um ein Feature zu deaktivieren, fordern Sie die APO auf, ihre IPropertyStore-Schnittstelle bereitzustellen, und rufen Sie IPropertyStore::SetValue auf. Die vom APO-Eigenschaftenspeicher unterstützten Eigenschaften werden im Abschnitt "Unterstützte IPropertyStore-Eigenschaften" weiter unten in diesem Thema beschrieben.

Beispiele für die Kommunikation mit dem APO-Eigenschaftenspeicher für benutzerdefinierte Audiosystemeffekte in Windows finden Sie in den Beispielen auf GitHub unter: https://github.com/Microsoft/Windows-driver-samples/tree/main/audio/sysvad/APO

Funktionstatus der APO-Abfrage

Wenn ein benutzerdefiniertes APO lediglich ein Windows-Audioeffekte-Feature ersetzt und nicht über einen eigenen Konfigurations-UI- oder Einstellungsspeicher verfügt, muss möglicherweise ermittelt werden, welche Features auf dem entsprechenden APO aktiviert sind.

Es gibt mindestens zwei Möglichkeiten zum Abrufen dieser Informationen:

• Option A: Durch direkte Abfrage des Fx-Immobilienspeichers.

• Option B: Indirekt durch Instanziieren des APO und Verwenden der IPropertyStore-Schnittstelle zum Abfragen des Eigenschaftenspeichers.

Option A

Diese Option hat den Vorteil, dass sie ohne Instanziierung eines APO durchgeführt werden kann. Wenn ein benutzerdefiniertes APO den Fx-Eigenschaftsspeicher überwachen möchte, ist Option A die einzige Möglichkeit, Benachrichtigungen über Änderungen an Eigenschaften in Echtzeit zu empfangen. Ein Beispiel für Option A finden Sie im Beispiel "komprimieren".

Mit Option A fragt das benutzerdefinierte APO den Haupt-Endpunkt-Eigenschaftenspeicher (nicht Fx) für PKEY_AudioEngine_DeviceFormat ab. Anschließend wird die Kanalmaske aus diesem Format als PID für den Eigenschaftsschlüssel verwendet, um den Fx-Eigenschaftenspeicher abzufragen. Die GUID (fmtid) für den Eigenschaftsschlüssel, der zum Abfragen des Fx-Eigenschaftsspeichers verwendet wird, ist einer der XXX_XXX_KEY_GUID-Werte aus der Datei wmcodecdsp.h. Die KEY_GUID Namen entsprechen offensichtlich den MFPKEY-Namen , die weiter oben in diesem Thema behandelt wurden.

Option B

Diese Option hat den Vorteil, dass sie die Möglichkeit korrekt verarbeiten kann, dass das Windows APO möglicherweise in Zukunft einige seiner Funktionen standardmäßig aktiviert, wenn die entsprechende Eigenschaft im Fx-Eigenschaftenspeicher nicht vorhanden ist.

Mit Option B fragt das benutzerdefinierte APO die APO nach ihrer IPropertyStore-Schnittstelle ab und ruft IPropertyStore::GetValue mithilfe eines der MFPKEY_XXX Schlüsseln auf, die weiter oben in diesem Thema behandelt wurden.

Formatverhandlung

Wenn Sie ein benutzerdefiniertes SFX-APO implementieren, das das SFX-APO umschließt, geben Sie in den Registrierungseigenschaften des benutzerdefinierten APO APO_FLAG_FRAMESPERSECOND_MUST_MATCH nicht an. Diese Regel sollte befolgt werden, unabhängig davon, ob das benutzerdefinierte APO das Kanalformat ändern kann oder nicht. Wenn das benutzerdefinierte SFX APO dieses Flag angeben würde, würde es verhindern, dass das entsprechende SFX Lautsprecherauffüllung, Kopfhörervirtualisierung oder virtuellen Surround durchführt.

Eine benutzerdefinierte SFX APO-Implementierung muss IAudioProcessingObject::IsInputFormatSupported implementieren oder außer Kraft setzen. Es ist unwahrscheinlich, dass die Implementierung der Basisklasse IsInputFormatSupported die von dem benutzerdefinierten SFX APO und dem SFX APO umgesetzte Gruppe möglicher Kanalkonvertierungen genau widerspiegelt.

Die benutzerdefinierte Methode IsInputFormatSupported der SFX APO sollte die entsprechende Methode IsInputFormatSupported der APO aufrufen. Dadurch wird sichergestellt, dass SFX APO alle Kanalkonvertierungen verarbeitet, die nicht vom benutzerdefinierten SFX APO behandelt werden. Beachten Sie, dass das SFX APO möglicherweise aktualisiert wird, um weitere Konvertierungen in zukünftigen Windows-Versionen zu unterstützen. Das Aufrufen der ISInputFormatSupported-Methode von APO ist eine Möglichkeit, sicherzustellen, dass der Satz von Kanalkonvertierungen, die von der benutzerdefinierten APO unterstützt werden, vollständig den Satz von Kanalkonvertierungen enthält, die vom SFX APO unterstützt werden.

Was der benutzerdefinierte APO mit dem Rückgabewert aus der IsInputFormatSupported-Methode von SFX APO tun soll, hängt davon ab, welche Kanalkonvertierungen( falls vorhanden) der benutzerdefinierte SFX APO unterstützt.

Wenn die benutzerdefinierte SFX APO keine eigenen Kanalkonvertierungen unterstützt, kann die IsInputFormatSupported-Methode den Wert zurückgeben, der von der IsInputFormatSupported-Methode von SFX APO direkt an den Aufrufer zurückgegeben wurde. Ein Beispiel finden Sie in den Beispielen "Swap" und "Komprimierung".

Wenn das benutzerdefinierte SFX APO seine eigenen Kanalkonvertierungen unterstützt, wird ein negativer Rückgabewert (einschließlich S_FALSE) aus der IsInputFormatSupported-Methode von SFX APO nicht notwendigerweise in einen negativen Rückgabewert für den Aufrufer übersetzt. Das benutzerdefinierte SFX APO könnte z. B. Kanalkonvertierungen unterstützen, die vom entsprechenden APO nicht unterstützt werden. In diesem Fall muss der benutzerdefinierte SFX APO den Rückgabewert aus der IsInputFormatSupported-Methode von SFX APO mit einer eigenen Logik zum Ermitteln unterstützter Eingaben kombinieren. Beachten Sie, dass die optimale Bedeutung von "Kombinieren" davon abhängt, welche Art von Kanalkonvertierung Vorrang haben sollte. Der beste Ansatz hängt vom genauen Entwurf der benutzerdefinierten Implementierung ab.

Die IsOutputFormatSupported-Methode für ein SFX APO ist uninteressant, da das Ausgabeformat eines SFX-APO das Mixformat des Geräts ist. Dieses Format basiert auf externen Überlegungen und kann nicht von einem SFX APO oder seinem Eingabeformat beeinflusst werden. Aus diesem Grund versuchen die Beispiele nicht, die richtige Logik für IsOutputFormatSupported zu implementieren.

Die oben genannten Überlegungen gelten nicht für MFX-APOs, da das MFX APO keine Features implementiert, die das Kanalformat erfordern oder implizieren. Aus diesem Grund hat das MFX-Beispiel nichts Besonderes für IsInputFormatSupported oder IsOutputFormatSupported. Die Formatverhandlungslogik eines benutzerdefinierten MFX APOs wird nicht dadurch beeinflusst, dass es das MFX APO einhüllt.

LockForProcess/UnlockForProcess

Die IAudioProcessingObjectConfiguration::LockForProcess-Methode des benutzerdefinierten APO sollte die entsprechende Methode auf dem APO aufrufen. LockForProcess() ist ein guter Ort, um Entscheidungen in der Reihenfolge zu treffen, in der die verschiedenen Verarbeitungsphasen stattfinden sollten. Beispielsweise kann sie entscheiden, ob die benutzerdefinierte APO-Verarbeitung oder die Verarbeitung des APO zuerst angewendet werden soll. Alle drei Beispiele enthalten Beispiele für eine solche Entscheidungslogik, und die Kommentare in den Beispielen stellen einen gewissen Hintergrund bereit. Es ist jedoch unmöglich, in diesem Dokument allgemeine Richtlinien zu diesem Thema zu geben, da dazu Kenntnisse über die spezifischen Funktionen des benutzerdefinierten APO und deren mögliche Interaktionen mit den Funktionen des APO erforderlich wären.

GetLatency

Die IAudioProcessingObject::GetLatency-Implementierung des benutzerdefinierten APO sollte GetLatency für das APO aufrufen, das eingebunden wird. Wenn die benutzerdefinierte APO-Verarbeitung zu Latenzen führt, sollte sie dem Ergebnis hinzugefügt werden, das vom APO zurückgegeben wurde, bevor der Wert an den Aufrufer zurückgegeben wird.

APOProcess

Die Methode IAudioProcessingObjectRT::APOProcess des benutzerdefinierten APO sollte die APOProcess-Methode des APOs vor, nach oder sogar während der Verarbeitung aufrufen. Die Entscheidung darüber, wann APOProcess aufgerufen werden soll, sollte in LockForProcess getroffen werden, damit alle erforderlichen Zwischenpuffer zugeordnet werden können. Die APOs unterstützen die direkte Verarbeitung, wenn ihre Eingabe- und Ausgabeformate identisch sind. In diesem Fall kann das benutzerdefinierte APO die gleiche APO_CONNECTION_PROPERTY sowohl als Eingabe- als auch als Ausgabe-Verbindungseigenschaft für das Windows-APO übergeben. Das benutzerdefinierte APO sollte jedoch nicht die Eingabeverbindungseigenschaft des benutzerdefinierten APO als Ausgabeverbindungseigenschaft für das APO verwenden. Im Allgemeinen sollten APOs ihren Eingabepuffer nicht ändern.

Behandeln von APO-Fehlern

Wenn ein APO einen Fehler an das entsprechende benutzerdefinierte APO zurückgibt, sollte das benutzerdefinierte APO von diesem Punkt aus so handeln, als ob keine APO vorhanden ist. In den Beispielen werden alle APO-Fehler als gleichbedeutend damit behandelt, dass CoCreateInstance nicht in der Lage ist, das APO zu erstellen. Optional kann das benutzerdefinierte APO die Auswirkungen von Fehlern von der LockForProcess-Methode der APO auf die aktuelle Sitzung beschränken. Mit anderen Worten: Das benutzerdefinierte APO verwendet das APO nicht bei den nachfolgenden Aufrufen der APOProcess-Methode. Das benutzerdefinierte APO kann jedoch erneut versuchen, das APO zu verwenden, wenn später ein anderer LockForProcess-Aufruf mit verschiedenen Formaten erfolgt.

Kompilieren und Verknüpfen

Um die APO CLSID- und Eigenschaftsschlüsseldefinitionen zu verwenden, binden Sie wmcodecdsp.h ein und verlinken Sie mit wmcodecdspuuid.lib. Weitere Informationen finden Sie unter wmcodecdsp.h header.

APO-Proben

Es gibt vier Beispielbeispiele für Audiosystemeffekte. Die APO-Beispiele sind auf GitHub verfügbar unter: https://github.com/Microsoft/Windows-driver-samples/tree/main/audio/sysvad/APO

Allgemeine Richtlinien für benutzerdefinierte Audiosystemeffekte

Im Folgenden sind einige Richtlinien aufgeführt, die IHVs bei der Implementierung von APOs für benutzerdefinierte Audiosystemeffekte befolgen sollten.

• Alle Audiosystemeffekte sollten Optionen für ein/aus bereitstellen. Benutzer sollten nicht gezwungen werden, einen Audiosystemeffekt zu verwenden.
• Interaktionen zwischen Funktionen in den SFX- und MFX-APOs sollten durch die APOs und deren zugehörige Benutzeroberfläche vermittelt werden.
• Features, die hier als SFX oder MFX angegeben sind, können in benutzerdefinierten Implementierungen zwischen SFX und MFX verschoben werden. Dies sollte jedoch mit dem Verständnis geschehen, dass die Ein-/Aus-Optionen vorhanden sein sollten und dass die Barrierefreiheit und Angemessenheit der Optionen nicht beeinträchtigt werden sollten.
• Implementierer sollten sich daran erinnern, dass SFX unterschiedliche Eingabe- und Ausgabekanalmasken aufweisen kann. Das MFX APO muss über die gleichen Eingabe- und Ausgabekanalmasken verfügen.

Von Windows bereitgestellte APOs

Informationen zu den anderen von Windows bereitgestellten APOs finden Sie in diesen Themen.

Bassverstärkung

Bassmanagement

Erweiterter Sound für Laptopcomputer

Lautstärkegleichs-DSP

Niederfrequenzschutz

Raumkorrektur

Lautsprecherfüllung

Lautsprecher-Phantoming

Virtual Surround

Virtualisierter Surround-Sound über Kopfhörer

Spezifische INFORMATIONEN zur APO-Anpassung

Lautstärkeanpassung (SFX APO)

Lautheitsgleichung ist eine komprimierte Dynamik-Verarbeitung, die durch einen wahrgenommenen Lautstärkemaßstab gesteuert wird. Raumkorrektur (MFX APO)

Die Raumkorrektur verwendet ein Profil, das der Raumkalibrierungs-Assistent generiert hat. Dieses Profil wird als binäres Blob gespeichert. Das Format des Blobs wird zurzeit nicht veröffentlicht.

Kanalkonvertierung (SFX APO)

Der Kanalkonvertierungs-APO übernimmt mehrere Aufgaben.

Kopfhörer-Virtualisierung

Dieser Effekt ist aktiviert, wenn das Kanalformat des wiedergegebenen Inhalts (N.x) 2,0 oder größer ist, wobei x 0 oder 1 sein kann. Die Ausgabemaske muss Stereo (0x3) sein. Die Eingabemaske ist auf einige unterstützte Kombinationen beschränkt, die in der untenstehenden Tabelle aufgeführt sind.

Headphone-Virtualisierungs-Kanalmasken

Virtueller Raumklang

Dieser Effekt wird auch als Links/rechts-Faltung (LTRT) oder Links-/Rechts-Matrixkodierung bezeichnet. Es wird verwendet, wenn das Kanalformat des wiedergegebenen Inhalts (N.x) 2,0 oder größer ist, wobei x 0 oder 1 sein kann. LTRT-Foldown ist normalerweise 4,0 zu 2,0. Jedes andere Eingabeformat wird in der Regel behandelt, indem zuerst N.x auf 4.0 generische Faltung angewendet wird. In unserer Implementierung ist LTRT folddown jedoch nativ 5.1 bis 2.0. Alle anderen Eingaben werden behandelt, indem zuerst N.x auf den 5.1 generischen Folddown angewendet wird.

Die Ausgabekanalmaske muss 0x3 (Stereo) sein, und die Anzahl der Eingabekanäle, einschließlich des Subwoofers, falls vorhanden, darf nicht mehr als acht sein.

Lautsprecherfüllung

Dieser Effekt wird verwendet, wenn die Anzahl der Eingabekanäle (N) kleiner als die Anzahl der Ausgabekanäle (M) ist. Der Effekt füllt N.x-Kanal zu M.x-Kanälen, wobei x entweder 0 oder 1 sein kann.

Die Kanalmasken in Tabelle 4 , die den LFE-Kanal ignorieren, werden für die Lautsprecherfüllung unterstützt. Die Lautsprecherfüllfunktion unterstützt jede Kombination aus Eingabe- oder Ausgabe-Subwoofer-Kanalpräsenz, sodass die Zahlen auf der linken Seite nur Beispiele sind. Die tatsächlichen Konfigurationen können möglicherweise einen Subwoofer enthalten oder auch nicht.

Füllkanalmasken für Lautsprecher

Die Lautsprecherfüllung wird nicht unterstützt, wenn einer der folgenden Werte zutrifft:

• Die Eingabemaske entspricht der Ausgabemaske.
• Der einzige Unterschied zwischen Eingabe und Ausgabe besteht darin, dass die Eingabe seitliche Links/Rechts-Kanäle aufweist, während die Ausgabe hintere Links/Rechts-Kanäle hat.
• Die Eingabe verfügt über mehr Hauptkanäle als die Ausgabe.
• Die Ausgabemaske enthält die Mitte-Links/Rechts-Lautsprecher, die Eingabemaske jedoch nicht.
• Die Kanäle, die in der Ausgabe, aber nicht in der Eingabe vorhanden sind, enthalten nicht mindestens eines von: Vordermitte, hinten links/rechts oder seitlich links/rechts.

Es gibt eine Ausnahme für das zweite Element in der Liste. Wenn der einzige Unterschied zwischen Eingabe und Ausgabe darin besteht, dass die einen seitliche linke/rechte Kanäle und die anderen hintere linke/rechte Kanäle haben, wird die Lautsprecherfüllung unterstützt, wenn eines der Formate Kanäle enthält, die in der Bitreihenfolge der Kanalmaske zwischen SideLR und BackLR liegen würden. Es gibt drei solche Kanäle:

• SPEAKER_FRONT_LEFT_OF_CENTER
• SPEAKER_FRONT_RIGHT_OF_CENTER
• SPEAKER_BACK_CENTER

Wenn die Eingabe- oder Ausgabemaske einen dieser drei Kanäle enthält, wird die Lautsprecher-Unterstützung möglicherweise unterstützt, obwohl sie nicht die zweite Bedingung in der Liste erfüllt, sondern nur, wenn die anderen Bedingungen erfüllt sind. Beispielsweise wird die Lautsprecherfüllung von MASK_7_FRONT_BACK bis zu oder von MASK_7_FRONT_SIDE aus diesem Grund von der Lautsprecherfüllung unterstützt.

Die folgende Tabelle enthält die vollständige Liste der Kanalwerte.

Verzögerungen werden für Kanäle in den Ausgabekonfigurationen verwendet, die "außerhalb" des Front-Back-Bereichs in der Eingabekonfiguration liegen. Wenn hingegen ein Lautsprecher in der Ausgabekonfiguration zwischen einigen Lautsprechern in der Eingabekonfiguration in Bezug auf die Vorder- und Rückseite steht, wird die Ausgabe für diesen Lautsprecher erzeugt, indem einige der Eingabekanäle von beiden Seiten des Ausgabekanals gemischt werden.

Run-Time Überlegungen beim Erneuten Verwenden von Windows-APOs

Dieser Abschnitt enthält einige zusätzliche Informationen, die IHVs und OEMs bei der Implementierung ihrer benutzerdefinierten Audiosystemeffekte hilfreich finden können.

Eine benutzerdefinierte APO-Implementierung:

• Verwendet CoCreateInstance, um eine oder mehrere Instanzen der WINDOWS-APOs für benutzerdefinierte Audiosystemeffekte zu instanziieren.
• Konfiguriert jede Instanz, um den gewünschten Satz von Features zu aktivieren.
• Platziert jede Instanz an einer passenden Stelle innerhalb der benutzerdefinierten internen Pipeline des APO.

Warum eine oder mehrere Instanzen?

Um unerwünschte Interaktionen zu vermeiden, benötigen die meisten Features eine bestimmte relative Sortierung. Da Windows-APOs mehrere Features innerhalb eines einzelnen APO implementieren, sind möglicherweise mehrere Instanzen dieses APO erforderlich, um die richtige Reihenfolge sicherzustellen. Gehen Sie beispielsweise davon aus, dass drei aktivierte Features – A, B und C – ABC sortiert werden müssen. Die benutzerdefinierte Implementierung behandelt B, delegiert aber A und C an das Windows-APO. A und C müssen sich dann in separaten Instanzen des Microsoft APO befinden, damit die benutzerdefinierte Implementierung von B zwischen ihnen erfolgen kann.

Windows implementiert Raumkorrekturen im MFX APO, was bedeutet, dass es sich um ein separates COM-Objekt vom SFX APO handelt. Eine benutzerdefinierte Implementierung könnte die Raumkorrektur an die Windows-Implementierung delegieren, sie aber in einem benutzerdefinierten SFX APO platzieren. Die benutzerdefinierte SFX-Implementierung muss dann möglicherweise eine Verarbeitung an die Windows SFX APO-Implementierung und andere Verarbeitung an die Windows MFX APO-Implementierung delegieren.

Umgang mit den Einschränkungen verschiedener Kombinationen aus Eingabe- und Ausgabeformaten

Viele Features – insbesondere die Bassverwaltung – funktionieren in bestimmten Fällen nicht. Die Vorwärts-Bassverwaltung ist beispielsweise nicht definiert, wenn die Basslautsprecherkonfigurationseigenschaft "AllSmall" oder "AllLarge" lautet und das Ausgabeformat keinen Subwoofer-Kanal enthält oder das NoSub-Flag gesetzt ist. Es ist nicht immer möglich, den Fehler während des IPropertyStore::SetValue-Aufrufs zu erkennen. Die Methode versucht, das Feature zu aktivieren, aber die Eingabe- und Ausgabeformate sind zu diesem Zeitpunkt nicht bekannt, da LockForProcess nach allen Eigenschaftenmanipulationen erfolgen muss. Dies bedeutet, dass es möglich ist, ein Feature zu aktivieren, es scheint erfolgreich zu sein, aber nicht, dass die entsprechende Verarbeitung stattfindet.

Es stehen zwei Strategien für den Umgang mit solchen Situationen zur Verfügung:

• Untersuchen Sie sorgfältig die featurespezifischen Abschnitte dieses Dokuments, um genau vorherzusagen, wann ein bestimmtes Feature erfolgreich ist oder nicht.
• Rufen Sie "IPropertyStore::GetValue" auf, nachdem LockForProcess aufgerufen wurde, um den Status wichtiger Eigenschaften zu überprüfen.

Wenn LockForProcess feststellt, dass ein bestimmtes Feature aufgrund der Eingabe- und Ausgabeformate oder des Werts einer anderen Eigenschaft nicht aktiviert werden kann, aktualisiert LockForProcess den Wert der entsprechenden Eigenschaft im Eigenschaftenspeicher.

Interaktion zwischen Lautsprecherfüllung und Bassverwaltung

Wenn die Lautsprecherfüllung eingeschaltet ist und ein Subwoofer angeschlossen ist, muss das Bassmanagement vor der Lautsprecherfüllung erfolgen, um die Kammfilterung des Niederfrequenzsignals durch die Surround-Verzögerung der Lautsprecherfüllung zu vermeiden.

Wenn die Lautsprecherfüllung aktiviert ist und kein Subwoofer angeschlossen ist, sind zwei Arten von Bass-Management nach vorne möglich.

• Wenn die vorderen linken/rechten Lautsprecher groß sind, leitet das Forward Bass Management den niederfrequenten Teil der Surround- und Mittelkanäle in die vorderen linken/rechten Lautsprecher weiter. Die Vorwärts-Bassverwaltung muss in diesem Fall nach der Lautsprecherfüllung kommen.
• Wenn alle Lautsprecher klein sind, wird die Vorwärtsbassverwaltung zum Niederfrequenzschutz für alle Hauptlautsprecher.

Dies kann entweder vor oder nach der Lautsprecherfüllung auftreten. Aus Leistungsgründen ist es jedoch besser, ein vorgelagertes Bassmanagement vor der Lautsprecherfüllungseinstellung zu haben.

Das Windows APO implementiert bestimmte allgemeine Lautsprecherfüllkonfigurationen, z. B. 2.0 => 5.1, mit speziellem optimierten Code, der die Rückwärtsbassverwaltung im selben Schritt wie die Lautsprecherfüllung behandelt.

Interaktion zwischen Folddown und Bass Management

Die Kopfhörervirtualisierung unterstützt nur die umgekehrte Bassverwaltung.

• Forward-Bass-Management ergibt bei der Kopfhörervirtualisierung keinen Sinn.
• Zur Einfachheit der Implementierung werden der Low-Frequency-Schutz und die Bassverstärkung nicht unterstützt.

Wenn einer der Kopfhörervirtualisierungs-, Virtual-Surround-Codierungs- oder Lautsprecherauffüllungseffekte aktiviert ist, wird während dieses Schritts das Reverse-Bass-Management behandelt. Das umgekehrte Bass-Management wird weiterhin über die Eigenschaft für umgekehrtes Bass-Management der APOs gesteuert, als wäre es eine separate Funktion. In diesen Fällen steuert das umgekehrte Bass-Management einfach die Fold-down-Koeffizienten für den .1-Eingabekanal. Ein offenes Problem besteht darin, dass die Rückwärtsbassverwaltung nicht deaktiviert werden kann, wenn LTRT aktiviert ist. In diesem Fall verwendet das Reverse-Bass-Management einen unkonventionellen Subwoofer-Kanalgewinn.

Die Windows-Audiosystemeffekte-APOs wenden eine kleinere Verarbeitung an – Verstärkung und Verzögerung – auch dann, wenn keine Funktionen aktiviert sind. Das Ziel einer solchen Verarbeitung besteht darin, sicherzustellen, dass sich die Parameter "Gain" und "Delay" nicht ändern, wenn ein Feature im laufenden Betrieb aktiviert wird. Der Grund dafür ist, dass die Verzögerung bei der Implementierung einiger Features inhärent ist, und ein Gewinn <1 von einigen Features angewendet wird, um zu vermeiden, dass die Ausgabe in bestimmten Situationen übermäßig hoch ist. Der Satz der verfügbaren Features hängt von den Eingabe- und Ausgabeformaten und bestimmten Eigenschaften ab, und ebenso die kumulierten Normalisierungsgewinne und -verzögerungen.

Wenn Features nicht spontan ein- oder ausgeschaltet werden, kann die Normalisierungszunahme deaktiviert werden, indem Sie die MFPKEY_CORR_NORMALIZATION_GAIN-Eigenschaft auf FALSE setzen und IPropertyStore::SetValue aufrufen. Die Eigenschaft könnte standardmäßig WAHR sein.

Es gibt keinen Mechanismus zum Deaktivieren der Normalisierungsverzögerung, da davon ausgegangen wird, dass sie weniger wahrscheinlich einstößig ist als normalisierungsgewinn. Wenn eine Normalisierungsverzögerung einwänderbar ist, umgehen Sie einfach das betreffende APO.

Siehe auch

• Architektur des Audioverarbeitungsobjekts
• Implementieren von Audioverarbeitungsobjekten