Combinare API personalizzate e Windows

Gli oggetti di elaborazione audio (APO) offrono un'elaborazione di segnali digitali personalizzabili basata su software per i flussi audio Windows. È possibile combinare le API fornite da Microsoft, con il codice sviluppato dal partner, il wrapping e la personalizzazione delle funzionalità esistenti.

Per informazioni generali sulle API, vedere questi argomenti.

• Architettura degli oggetti elaborazione audio
• Implementazione di oggetti di elaborazione audio
• Implementazione di effetti APO offloaded hardware

Le API sono state introdotte per la prima volta in Windows Vista e potrebbero essere visualizzati riferimenti alle API di sistema precedenti- sAPOs. Per altre informazioni, vedere il white paper Effetti audio personalizzati in Windows Vista . Questo white paper può fare riferimento a argomenti di sviluppodi interfaccia utente e COM meno recenti.

Come combinare API personalizzate e Windows

Questa sezione contiene linee guida per l'implementazione di API per effetti del sistema audio personalizzati, creando un wrapper sottile intorno all'APO corrispondente. Personalizzato APO si riferisce all'implementazione dell'IHV dell'APO.

Esistono due tipi di API, SFX (Stream) e MFX (mode). In Windows 8.1, SFX è stato definito LFX (locale) e MFX è stato fatto riferimento alle API GFX (globali).

Gli IHD possono implementare API personalizzate per gli effetti del sistema audio per sostituire o entrambe le API per gli effetti del sistema audio personalizzati di Windows SFX e MFX. In generale, gli IHD o gli OEM hanno due strategie di base per combinare API di effetti del sistema audio personalizzati con le API fornite da Windows. Queste strategie offrono agli IHV flessibilità su come integrano gli effetti personalizzati con quelli di Windows.

Replace

Sviluppare una comprensione dettagliata dell'apo di Windows che si vuole sostituire e le relative funzionalità. Usare questa comprensione per implementare un'apo personalizzata che chiama l'APO di Windows in modo che abbia più senso per l'IHV dal punto di vista dell'esperienza utente di destinazione. Questa strategia è più adatta agli IHD o agli OEM che vogliono:

• Integrare facilmente gli effetti personalizzati con gli effetti di Windows.
• Implementare la propria interfaccia utente per controllare gli effetti e gli effetti implementati dalle API di Windows.

Per altre informazioni sulla scrittura di un apo, vedere Oggetti di elaborazione audio di Windows.

Wrapper sottile

Scrivere l'APO personalizzato come wrapper sottile intorno all'APO di Windows. Questa strategia è più adatta agli IHD o agli OEM che vogliono:

• Aggiungere gli effetti personalizzati nel modo più semplice possibile.
• Fare in modo che l'interfaccia utente di Windows continui a controllare gli effetti.

IHV o OEM che scelgono Strategia l'opzione thin wrapper, devono comunque esaminare gli oggetti elaborazione audio di Windows per ottenere una conoscenza approfondita degli effetti del sistema audio personalizzato di Windows.

Nota: con la strategia thin wrapper IHV non può aggiungere l'interfaccia utente per controllare gli effetti del sistema audio personalizzato aggiunti alla scheda Miglioramenti di Windows. È presente una sola scheda Miglioramenti e deve rimanere associata alla pagina delle proprietà per le API di Windows. L'interfaccia utente di IHV deve essere implementata in altro modo, ad esempio un'applicazione di Pannello di controllo separata.

Informazioni di programmazione

Questa sezione illustra i problemi di programmazione generali che devono essere risolti implementano un'API personalizzata.

Le API per gli effetti del sistema audio personalizzato SFX(Stream) e MFX(Mode) hanno le caratteristiche generali seguenti:

• Devono essere registrati come oggetti server in-process COM di cui è possibile creare un'istanza tramite CoCreateInstance.
• I CLSID sono CLSID_CWMAudioLFXAPO e CLSID_CWMAudioGFXAPOrispettivamente per le API SFX e MFX. I CLSID vengono dichiarati in wmcodecdsp.h e definiti in wmcodecdspuuid.lib.
• Devono supportare l'aggregazione COM. Tuttavia, non è previsto che l'aggregazione venga usata in uno scenario di effetti del sistema audio personalizzato, quindi non dovrebbe rappresentare alcun problema significativo.

Inizializzazione

Un apo personalizzato deve inizializzare l'APO window chiamando il metodo IAudioSystemEffects::Initialize . Questa operazione viene in genere eseguita dal metodo Initialize dell'APO personalizzato. Tutti gli argomenti passati al metodo Initialize dell'APO personalizzato devono essere passati direttamente all'inizializzazione di Windows APO. Ciò consente all'APO di recuperare le impostazioni dagli archivi delle proprietà endpoint e Fx nella struttura APOInitSystemEffects. È possibile che l'APO personalizzato recuperi le impostazioni e le passi in modo selettivo all'APO, ma che è essenzialmente strategia A.

Se l'APO personalizzato sostituisce una funzionalità, in genere è consigliabile disattivare la funzionalità corrispondente nell'apo. Tuttavia, la disattivazione della funzionalità potrebbe non essere strettamente necessaria, a seconda del funzionamento della funzionalità. Per disattivare una funzionalità, eseguire una query sull'apo per l'interfaccia IPropertyStore e chiamare IPropertyStore::SetValue. Le proprietà supportate dall'archivio delle proprietà di APO sono descritte in "Proprietà IPropertyStore supportate". Più avanti in questo argomento.

Per esempi di come comunicare con l'archivio delle proprietà APO degli effetti del sistema audio personalizzato di Windows, vedere gli esempi in GitHub all'indirizzo: https://github.com/Microsoft/Windows-driver-samples/tree/main/audio/sysvad/APO

Eseguire query sullo stato della funzionalità apo

Se un apo personalizzato sostituisce semplicemente una funzionalità effetti audio di Windows e non ha un proprio archivio di impostazioni o interfaccia utente di configurazione, potrebbe dover determinare quali funzionalità sono abilitate nell'APO corrispondente.

Esistono almeno due modi per ottenere queste informazioni:

• Opzione A: eseguendo direttamente una query sull'archivio delle proprietà Fx.

• Opzione B: indirettamente, creando un'istanza di APO e usando l'interfaccia IPropertyStore per eseguire query nell'archivio delle proprietà.

Opzione A

Questa opzione offre il vantaggio che può essere eseguita senza creare un'istanza di un apo. Inoltre, se un apo personalizzato vuole monitorare l'archivio delle proprietà Fx, l'opzione A è l'unico modo per ricevere notifiche di modifica delle proprietà on-the-fly. Per un esempio di Opzione A, vedere l'esempio di "compressione".

Con l'opzione A, l'apo personalizzato esegue una query sull'archivio delle proprietà dell'endpoint principale, non fx, per PKEY_AudioEngine_DeviceFormat. Usa quindi la maschera di canale da tale formato come PID per la chiave della proprietà usata per eseguire query nell'archivio delle proprietà Fx. Il GUID (fmtid) per la chiave di proprietà usata per eseguire query sull'archivio delle proprietà Fx è uno dei valori XXX_XXX_KEY_GUID da wmcodecdsp.h. I nomi KEY_GUID corrispondono in modo ovvio ai nomi MFPKEY descritti in precedenza in questo argomento.

Opzione B

Questa opzione ha il vantaggio che può gestire correttamente la possibilità che l'apo di Windows potrebbe eventualmente avere alcune delle sue funzionalità abilitate per impostazione predefinita se la proprietà corrispondente nell'archivio delle proprietà Fx non esiste.

Con l'opzione B, l'APO personalizzato esegue semplicemente una query sull'APO per l'interfaccia IPropertyStore e chiama IPropertyStore::GetValue usando una delle chiavi MFPKEY_XXX illustrate in precedenza in questo argomento.

Negoziazione del formato

Quando si implementa un file APO SFX personalizzato che esegue il wrapping di SFX APO, non specificare APO_FLAG_FRAMESPERSECOND_MUST_MATCH nelle proprietà di registrazione di APO personalizzate. Questa regola deve essere seguita indipendentemente dal fatto che l'APO personalizzato possa modificare il formato del canale. Se l'APO SFX personalizzato dovesse specificare questo flag, impedirebbe all'SFX corrispondente di riempire altoparlanti, virtualizzazione delle cuffie o circondare virtuale.

Un'implementazione SFX APO personalizzata deve implementare o eseguire l'override di IAudioProcessingObject::IsInputFormatSupported. È improbabile che l'implementazione della classe di base IsInputFormatSupported rifletta in modo accurato il set di possibili conversioni di canale implementate dall'APO SFX personalizzato e dall'APO SFX.

Il metodo IsInputFormatSupported personalizzato di SFX APO deve chiamare il metodo IsInputFormatSupported corrispondente. In questo modo, SFX APO gestisce tutte le conversioni di canale non gestite dall'APO SFX personalizzato. Si noti che SFX APO potrebbe essere aggiornato per supportare più conversioni nelle versioni future di Windows. La chiamata al metodo IsInputFormatSupported di APO è un modo per garantire che il set di conversioni di canale supportate dall'APO personalizzato contenga completamente il set di conversioni di canale supportate dall'APO SFX.

Ciò che l'APO personalizzato deve eseguire con il valore restituito dal metodo IsInputFormatSupported di SFX APO dipende dalle conversioni di canale supportate, se presenti, dall'apo SFX personalizzato.

Se l'APO SFX personalizzato non supporta alcuna conversione di canale, il metodo IsInputFormatSupported può restituire il valore restituito dal metodo IsInputFormatSupported di SFX APO direttamente al chiamante. Per un esempio, vedere gli esempi di "swap" e "compress".

Se l'apo SFX personalizzato supporta le proprie conversioni di canale, un valore restituito negativo, incluso S_FALSE, dal metodo IsInputFormatSupported di SFX APO non si traduce necessariamente in un valore restituito negativo al chiamante. L'APO SFX personalizzato potrebbe, ad esempio, supportare le conversioni di canale che non sono supportate dall'APO corrispondente. In tal caso, l'APO SFX personalizzato deve combinare il valore restituito dal metodo IsInputFormatSupported di SFX APO con la propria logica per determinare gli input supportati. Si noti che il significato ottimale di "combine" dipende dal tipo di conversione del canale che deve avere la precedenza. L'approccio migliore dipende dalla progettazione esatta dell'implementazione personalizzata.

Il metodo IsOutputFormatSupported in un apo SFX non è interessante perché il formato di output di SFX APO è il formato di combinazione del dispositivo. Questo formato è basato su considerazioni esterne e non può essere influenzato da un apo SFX o dal relativo formato di input. Per questo motivo, gli esempi non tentano di implementare la logica corretta per IsOutputFormatSupported.

Le considerazioni precedenti non si applicano alle API MFX perché MFX APO non implementa funzionalità che richiedono o implicano la modifica del formato del canale. Per questo motivo, l'esempio MFX non esegue alcuna operazione speciale per IsInputFormatSupported o IsOutputFormatSupported. La logica di negoziazione del formato di un'apo di MFX personalizzata non è influenzata dal fatto che esegue il wrapping dell'APO di MFX.

LockForProcess/UnlockForProcess

Il metodo IAudioProcessingObjectConfiguration::LockForProcessconfiguration personalizzato di APO deve chiamare il metodo corrispondente nell'APO. LockForProcess() è un buon posto per prendere decisioni relative all'ordine in cui devono essere eseguite le varie fasi di elaborazione. Ad esempio, può decidere se applicare prima l'elaborazione APO personalizzata o l'elaborazione dell'APO. Tutti e tre gli esempi forniscono esempi di tale logica decisionale e i commenti negli esempi forniscono informazioni di base. Tuttavia, è impossibile fornire indicazioni completamente generali su tale argomento in questo documento perché richiederebbe la conoscenza delle funzionalità specifiche dell'APO personalizzato e del modo in cui potrebbero interagire con le funzionalità delle API.

GetLatency

L'implementazione di IAudioProcessingObject::GetLatency personalizzata deve chiamare GetLatency nell'APO in cui viene eseguito il wrapping. Se l'elaborazione APO personalizzata comporta la latenza, deve aggiungerla al risultato restituito dall'APO prima di restituire il valore al chiamante.

APOProcess

Il metodo IAudioProcessingObjectRT::APOProcess personalizzato deve chiamare il metodo APOProcess prima, dopo o anche durante l'elaborazione. La decisione su quando chiamare APOProcess deve essere effettuata in LockForProcess, in modo che qualsiasi buffer intermedio necessario possa essere allocato. Le API supportano l'elaborazione sul posto ogni volta che i formati di input e output sono identici. In tal caso, l'APO personalizzato può passare la stessa APO_CONNECTION_PROPERTY sia della proprietà di connessione di input che di output per l'APO di Windows. L'APO personalizzato non deve tuttavia usare la proprietà di connessione di input dell'APO personalizzata come proprietà di connessione di output per l'APO. In generale, le API non devono modificare il buffer di input.

Gestione degli errori DELL'APO

Se un APO restituisce un errore all'APO personalizzato corrispondente, l'APO personalizzato deve agire da quel punto su come se non vi sia alcuna APO. Gli esempi considerano tutti gli errori APO equivalenti a CoCreateInstance che non riescono a creare l'APO. Facoltativamente, l'APO personalizzato può limitare l'effetto degli errori dal metodo LockForProcess dell'APO alla sessione corrente. In altre parole, l'APO personalizzato non usa l'APO durante le chiamate successive al metodo APOProcess. Tuttavia, l'APO personalizzato potrebbe provare di nuovo a usare l'APO se è presente un'altra chiamata LockForProcess in un secondo momento, con formati diversi.

Compilazione e collegamento

Per usare le definizioni delle chiavi DI APO CLSID e delle proprietà, includere wmcodecdsp.h e collegamento con wmcodecdspuuid.lib. Per altre informazioni, vedere intestazione wmcodecdsp.h.

Esempi di APO

Sono disponibili quattro esempi di effetti del sistema audio di esempio. Gli esempi di APO sono disponibili in GitHub all'indirizzo: https://github.com/Microsoft/Windows-driver-samples/tree/main/audio/sysvad/APO

Linee guida generali per gli effetti del sistema audio personalizzato

Di seguito sono riportate alcune linee guida da seguire per l'implementazione di API di sistema audio personalizzate.

• Tutti gli effetti del sistema audio devono fornire opzioni on/off. Gli utenti non devono essere costretti a usare un effetto del sistema audio.
• Le interazioni tra le funzionalità nell'APO SFX e MFX devono essere mediate dalle API e dall'interfaccia utente correlata.
• Le funzionalità specificate come SFX o MFX possono essere spostate tra SFX e MFX nelle implementazioni personalizzate. Tuttavia, questa operazione deve essere eseguita con la comprensione che le opzioni on/off devono esistere e che l'accessibilità e l'appropriatezza delle opzioni non devono essere compromesse.
• Gli implementatori devono ricordare che SFX può avere maschere di canale di input e di output diverse. L'APO di MFX deve avere le stesse maschere del canale di input e di output.

API fornite da Windows

Per informazioni sulle altre API fornite da Windows, vedere questi argomenti.

Basso Boost

Gestione bassi

Audio avanzato per computer portatili

DSP di equalizzazione di alta velocità

Protezione a bassa frequenza

Correzione della stanza

Riempimento altoparlante

Altoparlante fantasma

Circondato virtuale

Suono surround virtualizzato sulle cuffie

Informazioni specifiche sulla personalizzazione di APO

Equalizzazione dell'alta velocità (SFX APO)

L'equalizzazione della voce è un'elaborazione compressa (dinamica) basata su una metrica di fortezza percettiva. Correzione della stanza (APO MFX)

La correzione della stanza usa un profilo generato dalla Procedura guidata di calibrazione della stanza. Questo profilo viene archiviato come BLOB binario. Il formato del BLOB non è attualmente pubblicato.

Conversione del canale (APO SFX)

L'APO della conversione del canale gestisce diverse attività.

Virtualizzazione cuffie

Questo effetto è abilitato se il formato del canale del contenuto riprodotto (N.x) è 2.0 o maggiore, dove x può essere 0 o 1. La maschera di output deve essere stereo (0x3). La maschera di input è limitata a alcune combinazioni supportate, elencate nella tabella seguente

Maschere del canale di virtualizzazione cuffie

Circondato virtuale

Questo effetto viene anche definito a sinistra /destra (LTRT) a discesa o a sinistra/destra. Viene usato se il formato del canale del contenuto riprodotto (N.x) è 2.0 o maggiore, dove x può essere 0 o 1. Il ripiegato LTRT è normalmente da 4,0 a 2,0. Qualsiasi altro formato di input viene in genere gestito applicando prima N.x a 4.0 generica piegamento. Tuttavia, nell'implementazione, il ripiegatura LTRT è nativo da 5.1 a 2.0. Qualsiasi altro input viene gestito applicando prima N.x a 5.1 generico.

La maschera del canale di output deve essere 0x3 (stereo) e il numero di canali di input, inclusi quelli presenti, devono essere non più di otto.

Riempimento altoparlante

Questo effetto viene usato quando il numero di canali di input (N) è minore del numero di canali di output (M). L'effetto riempie il canale N.x ai canali M.x, dove x può essere 0 o 1.

Le maschere di canale nella tabella 4, ignorando il canale LFE, sono supportate per il riempimento dell'altoparlante. Il riempimento altoparlante supporta qualsiasi combinazione di presenza del canale di input o output del canale, quindi i numeri a sinistra sono solo esempi. Le configurazioni effettive potrebbero o non avere un mdf.

Maschere del canale di riempimento altoparlanti

Il riempimento dell'altoparlante non è supportato se uno dei seguenti è true:

• La maschera di input equivale alla maschera di output.
• L'unica differenza tra input e output è che uno ha canali lato sinistro/destro; l'altro ha canali a sinistra/destra.
• L'input ha più canali principali rispetto all'output.
• La maschera di output include gli altoparlanti a sinistra/destra, ma la maschera di input non è.
• Il set di canali nell'output, ma non nell'input non include almeno uno di: centro anteriore, indietro a sinistra/destra o lato sinistro/destro.

Esiste un'eccezione al secondo elemento nell'elenco. Se l'unica differenza tra input e output è che uno ha canali lato sinistro/destro e l'altro ha canali indietro sinistro/destro, il riempimento dell'altoparlante è supportato se un formato contiene canali che rientrano tra sideLR e backLR nell'ordine di bit della maschera del canale. Esistono tre canali di questo tipo:

• SPEAKER_FRONT_LEFT_OF_CENTER
• SPEAKER_FRONT_RIGHT_OF_CENTER
• SPEAKER_BACK_CENTER

Se la maschera di input o output contiene uno di questi tre canali, il riempimento dell'altoparlante potrebbe essere supportato anche se non soddisfa la seconda condizione nell'elenco, ma solo se le altre condizioni sono soddisfatte. Ad esempio, il riempimento dell'altoparlante da MASK_7_FRONT_BACK a o da MASK_7_FRONT_SIDE è supportato dal riempimento dell'altoparlante per questo motivo.

La tabella seguente contiene l'elenco completo dei valori del canale.

I ritardi vengono usati per i canali nelle configurazioni di output "all'esterno" dell'intervallo front-back nella configurazione di input. Al contrario, se un altoparlante nella configurazione di output è "tra" alcuni altoparlanti nella configurazione di input nel senso indietro front-end, l'output per tale altoparlante viene generato combinando alcuni dei canali di input su entrambi i lati del canale di output.

Run-Time Considerazioni per la riutilizzo delle API di Windows

Questa sezione contiene alcune informazioni aggiuntive che possono risultare utili per l'implementazione degli effetti del sistema audio personalizzati.

Implementazione dell'APO personalizzata:

• Usa CoCreateInstance per creare un'istanza di una o più istanze delle API degli effetti del sistema audio personalizzato di Windows.
• Configura ogni istanza per abilitare il set desiderato di funzionalità.
• Inserisce ogni istanza in una posizione appropriata all'interno della pipeline interna dell'APO personalizzata.

Perché una o più istanze?

Per evitare interazioni indesiderate, la maggior parte delle funzionalità richiede un determinato ordinamento relativo. Poiché le API Di Windows implementano più funzionalità all'interno di un'unica APO, è possibile che siano necessarie più istanze di tale APO per garantire l'ordinamento corretto. Si supponga, ad esempio, che tre funzionalità abilitate, ovvero A, B e C, debbano essere ordinate ABC. L'implementazione personalizzata gestisce B ma delega A e C all'APO di Windows. A e C devono quindi essere in istanze separate dell'APO Microsoft in modo che l'implementazione personalizzata di B possa verificarsi tra di essi.

Windows implementa la correzione della stanza nell'APO di MFX, che significa che è un oggetto COM separato dall'APO di SFX. Un'implementazione personalizzata potrebbe scegliere di delegare la correzione della sala all'implementazione di Windows, ma inserirla in un'apo SFX personalizzata. L'implementazione di SFX personalizzata potrebbe quindi dover delegare alcune elaborazioni all'implementazione apo di Windows SFX e ad altre elaborazioni all'implementazione dell'apo di Windows MFX.

Gestione delle limitazioni di una combinazione di formato di input-output diversa

Molte funzionalità, in particolare la gestione dei bassi, non funzionano in alcuni casi. Ad esempio, la gestione dei bassi in avanti è indefinita se la proprietà di configurazione dell'altoparlante basso è "AllSmall" o "AllLarge" e il formato di output non include un canale mdf o il flag NoSub è impostato. Non è sempre possibile rilevare l'errore durante la chiamata IPropertyStore::SetValue . Il metodo tenta di abilitare la funzionalità, ma i formati di input e output non sono noti in quel momento perché LockForProcess deve verificarsi dopo tutte le manipolazioni delle proprietà. Ciò significa che è possibile abilitare una funzionalità, vedere che ha esito positivo, ma non avere l'elaborazione corrispondente.

Due strategie sono disponibili per gestire tali situazioni:

• Esaminare attentamente le sezioni specifiche della funzionalità di questo documento per poter prevedere esattamente quando una determinata funzionalità avrà esito positivo o non avrà esito positivo.
• Chiamare IPropertyStore::GetValue dopo che LockForProcess viene chiamato per controllare lo stato delle proprietà importanti.

Quando LockForProcess determina che non è possibile abilitare una determinata funzionalità, a causa dei formati di input e output o del valore di un'altra proprietà, LockForProcess aggiorna il valore della proprietà corrispondente nell'archivio delle proprietà.

Interazione tra riempimento altoparlante e gestione bassi

Quando il riempimento dell'altoparlante è acceso e un mdf è connesso, la gestione dei bassi in avanti deve verificarsi prima del riempimento dell'altoparlante per evitare il filtro del segnale a bassa frequenza dal ritardo del riempimento del altoparlante.

Quando il riempimento dell'altoparlante è abilitato e non è connesso alcun file di gestione dei bassi, sono possibili due tipi di gestione dei bassi:

• Se gli altoparlanti front-sinistro/destro sono grandi, la gestione dei bassi in avanti instrada la parte a bassa frequenza dei canali circondati e centrale negli altoparlanti frontali a sinistra/destra. La gestione dei bassi in avanti deve venire dopo il riempimento dell'altoparlante in questo caso.
• Se tutti gli altoparlanti sono piccoli, la gestione dei bassi in avanti diventa protezione a bassa frequenza per tutti gli altoparlanti principali.

Ciò può verificarsi prima o dopo il riempimento dell'altoparlante. Tuttavia, per motivi di prestazioni, è meglio avere la gestione dei bassi in avanti prima del riempimento dell'altoparlante.

L'APO di Windows implementa alcune configurazioni comuni di riempimento dell'altoparlante, ad esempio 2.0 => 5.1, con codice ottimizzato speciale che gestisce la gestione dei bassi inversa nello stesso passaggio del riempimento dell'altoparlante.

Interazione tra la piegatura e la gestione dei bassi

La virtualizzazione delle cuffie supporta solo la gestione dei bassi inversa:

• La gestione dei bassi in avanti non ha senso con la virtualizzazione delle cuffie.
• Per semplicità di implementazione, la protezione a bassa frequenza e il basso boost non sono supportati.

Quando una delle funzionalità di virtualizzazione delle cuffie, la codifica surround virtuale o gli effetti di riempimento dell'altoparlante si trovano su, la gestione dei bassi inversa viene gestita durante quel passaggio. La gestione dei bassi inversa è ancora controllata tramite la proprietà di gestione dei bassi inversa delle API come se fosse una funzionalità separata. In questi casi, la gestione dei bassi inversa controlla semplicemente i coefficienti di piegatura per il canale di input .1. Un problema aperto è che la gestione dei bassi inversa non può essere disabilitata quando LTRT è attivo. In tal caso, la gestione dei bassi inversa usa un guadagno del canale di mdf non convenzionale.

Le API degli effetti del sistema audio Di Windows applicano alcune operazioni di elaborazione secondaria, ottenere e ritardare, anche quando non sono abilitate funzionalità. L'obiettivo di tale elaborazione è garantire che i parametri di guadagno e ritardo non cambino quando una funzionalità è abilitata al volo. Il motivo è che il ritardo è intrinseco nell'implementazione di alcune funzionalità e un guadagno <1 viene applicato da alcune funzionalità per evitare un output eccessivamente elevato in determinate situazioni. Il set di funzionalità disponibili dipende dai formati di input-output e da alcune proprietà e quindi dal guadagno e ritardo cumulativo della normalizzazione.

Se le funzionalità non verranno attivate o disattivate a comparsa, il guadagno di normalizzazione può essere disabilitato impostando la MFPKEY_CORR_NORMALIZATION_GAIN proprietà su FALSE chiamando IPropertyStore::SetValue. La proprietà potrebbe essere TRUE per impostazione predefinita.

Non esiste alcun meccanismo per disabilitare il ritardo di normalizzazione perché si presuppone che sia meno probabile che sia discutibile rispetto al guadagno di normalizzazione. Se il ritardo di normalizzazione è discutibile, ignorare semplicemente l'APO in questione.

Vedi anche

• Architettura dell'oggetto elaborazione audio
• Implementazione di oggetti di elaborazione audio