Algoritmo di Audio Endpoint Builder
In Windows Vista e versioni successive di Windows, AudioEndpointBuilder è un servizio di sistema che enumera, inizializza e attiva gli endpoint audio in un sistema. In questo argomento viene fornita una panoramica dell'algoritmo usato dal servizio AudioEndpointBuilder.
Il servizio AudioEndpointBuilder usa un algoritmo per individuare ed enumerare gli endpoint. L'algoritmo è stato progettato per semplificare l'accesso al sistema ai dispositivi di acquisizione multixed (MUXed) e per facilitare l'uso delle topologie che coinvolgono più pin host e più pin bridge o entrambi.
In Windows XP il modello audio ha usato il termine dispositivo audio per fare riferimento a un dispositivo concettuale nell'albero Plug and Play (PnP). In Windows Vista e versioni successive di Windows, il concetto di un dispositivo audio è stato riprogettata per rappresentare meglio il dispositivo con cui l'utente interagisce fisicamente.
Con due nuove API in Windows Vista, API MMDevice e WASAPI, è possibile accedere e modificare questi nuovi dispositivi audio. L'API MMDevice fa riferimento ai nuovi dispositivi audio come endpoint.
Il servizio AudioEndpointBuilder monitora la classe KSCATEGORY_AUDIO per gli arrivi e le rimozione dell'interfaccia del dispositivo. Quando un driver di dispositivo audio registra una nuova istanza della classe di interfaccia del dispositivo KSCATEGORY_AUDIO, il servizio AudioEndpointBuilder rileva la notifica dell'interfaccia del dispositivo e usa un algoritmo per esaminare la topologia dei dispositivi audio nel sistema e intraprendere un'azione appropriata.
L'elenco seguente riepiloga il funzionamento dell'algoritmo usato da AudioEndpointBuilder:
Cerca i pin del bridge non connessi.
Crea un endpoint per tutti i pin del bridge non connessi. Ad esempio, quando audioEndpointBuilder trova un pin del bridge non connesso con un GUID di categoria pin di KSNODETYPE_SPEAKER, crea un endpoint altoparlante per questo pin bridge. Per altre informazioni su KSNODETYPE_SPEAKER e altri GUIDS di categoria pin, vedere Ksmedia.h in WinDDK\<build number>\inc\api.
Imposta le proprietà predefinite per l'endpoint. Ad esempio, AudioEndpointBuilder imposta il nome, l'icona e il fattore di forma.
Determina se è presente un percorso dall'endpoint a un pin host che supporta la modulazione del codice pulse (PCM), codec audio-3 (AC3) o video multimediale Windows (WMV). Un pin host è una struttura KSPIN con il relativo membro di comunicazione impostato su KSPIN_COMMUNICATION_SINK o KSPIN_COMMUNICATION_BOTH. Per altre informazioni sulla struttura KSPIN, vedere KSPIN.
Popola l'endpoint PropertyStore con informazioni sulle proprietà dalle chiavi del Registro di sistema dell'interfaccia del dispositivo audio.
Imposta lo stato dell'endpoint. Lo stato dell'endpoint può essere uno dei tre valori seguenti:
Attivo. Ciò indica che esiste un percorso come descritto nel passaggio 4.
Scollegato. Se il dispositivo audio supporta il rilevamento jack, questo stato indica che esiste un percorso per l'endpoint e il jack viene scollegato dal connettore fisico sulla scheda audio.
Non presente. Questo stato indica che un percorso non è stato trovato nel passaggio 4 e il rilevamento jack non è supportato da questo endpoint.
Imposta questo endpoint come endpoint predefinito, se specificato nel file INF associato.
Dopo l'enumerazione degli endpoint, i client del sistema audio possono modificarli direttamente usando le nuove API di Windows Vista (come indicato in precedenza) o indirettamente usando le API più familiari, ad esempio Wave, DirectShow o DirectSound. Sono stati forniti nuovi metodi API in modo che i client audio possano iniziare con l'ID MMDevice di un endpoint e accedere all'ID Wave o DirectSound per lo stesso endpoint.
Quando si usano gli endpoint, è possibile sfruttare i vantaggi seguenti:
Lo stesso ID univoco globale (GUID) è disponibile indipendentemente dalla frequenza con cui si riavvia il computer. La presenza di questo GUID persistente è più affidabile rispetto al salvataggio di un ID waveOut o di un nome descrittivo per l'endpoint.
Lo stesso PropertyStore è disponibile indipendentemente dalla frequenza di riavvio del computer. I metadati relativi al dispositivo audio vengono salvati nell'endpoint PropertyStore.
I pin multixed (MUX) e de-multiplexed (DEMUX) vengono gestiti automaticamente ed enumerati dal servizio AudioEndpointBuilder.
Se si sviluppa il proprio driver di dispositivo audio e il file INF per lavorare con il dispositivo audio e sviluppare un'applicazione audio o entrambi, è consigliabile essere consapevoli dei problemi e delle procedure consigliate seguenti. Quando si sviluppano driver e applicazioni con queste raccomandazioni, si producono driver, file INF e client audio che funzionano in modo più efficace con AudioEndpointBuilder.
Convenzione di denominazione. La convenzione di denominazione usata per gli endpoint è basata sui nomi descrittivi dei pin del bridge. Tuttavia, nel caso degli endpoint altoparlanti, il nome è stato hardcoded in "Altoparlanti" e non può essere modificato dal driver o da un'applicazione di terze parti.
Topologie non ottimali. Alcune topologie vengono considerate non ottimali a causa dell'algoritmo usato dall'AudioEndpointBuilder per enumerare gli endpoint. Ad esempio, quando si crea una di queste topologie non ottimali, si creano pin host che hanno endpoint nascosti e non possono essere visualizzati da AudioEndpointBuilder o splitters (endpoint di divisione) che audioEndpointBuilder non possono collegare ai pin host associati.
Endpoint nascosti
Nel diagramma seguente viene visualizzato il filtro KS con due pin host connessi a un singolo pin bridge (Altoparlante).
Quando AudioEndpointBuilder individua il pin del bridge, traccia un percorso fino a uno solo dei pin host, imposta i valori predefiniti per il pin del bridge, crea e attiva un endpoint altoparlante e continua a individuare altri pin del bridge. Pertanto, l'altro pin host rimane nascosto da AudioEndpointBuilder.
Nel diagramma precedente la topologia problematica è stata riprogettata in modo che audioEndpointBuilder possa individuare i due pin host (PCM e AC-3/ PCM) perché ora può vedere due pin bridge (Altoparlante e SPDIF).
Splitter
Un altro tipo di topologia non ottimale viene creato quando un pin host si connette a più di un pin del bridge. Il diagramma seguente illustra una topologia in cui un pin host PCM si connette a un pin del bridge altoparlante e un pin del bridge SPDIF.
In questo caso, AudioEndpointBuilder individua un pin del bridge e traccia un percorso di nuovo al pin host PCM, imposta i valori predefiniti e quindi crea e attiva un endpoint altoparlante. Quando AudioEndpointBuilder individua il pin del bridge successivo, traccia un percorso indietro allo stesso pin host PCM, imposta i valori predefiniti e quindi crea e attiva un endpoint SPDIF. Tuttavia, anche se entrambi gli endpoint sono stati inizializzati e attivati, lo streaming in uno di essi rende impossibile trasmettere all'altro contemporaneamente; in altre parole, si tratta di endpoint esclusivi a vicenda.
Il diagramma seguente mostra una riprogettazione di questa topologia in cui esistono connessioni separate. Questa progettazione consente a AudioEndpointBuilder di tracciare un percorso di nuovo al pin host PCM per ognuna delle due pin del bridge.
Formato endpoint. Quando il motore audio è in esecuzione in modalità condivisa, il formato per l'endpoint presuppone un'impostazione specifica come diretta dal file INF al momento dell'installazione. Ad esempio, il driver audio per un dispositivo audio usa il file INF associato per impostare l'endpoint predefinito su un formato PCM stereo a 44.1 kHz, a 16 bit. Dopo l'installazione, è necessario usare Pannello di controllo o un'applicazione di terze parti per modificare il formato dell'endpoint.
Dispositivo predefinito. L'endpoint impostato come dispositivo predefinito è selezionato al momento dell'installazione usando le informazioni nel file INF. Al termine dell'installazione, è necessario usare Pannello di controllo o un'applicazione di terze parti per selezionare un altro endpoint per essere l'endpoint predefinito.
Nota Se il file INF non seleziona un endpoint da impostare come impostazione predefinita durante l'installazione, un'applicazione client può usare l'API MMDevice per selezionare un endpoint. L'API basa la propria selezione sulla classificazione del fattore di modulo e se l'endpoint è un rendering o un endpoint di acquisizione. Nella tabella seguente viene illustrato l'ordine di selezione.
| Eseguire il rendering della classificazione | Classificazione di acquisizione |
|---|---|
| Altoparlanti | Microfono |
| Line-out | Line-in |
| SPDIF | SPDIF |
Se si usa l'API MMDevice per selezionare un endpoint predefinito e gli endpoint disponibili vengono classificati allo stesso modo, l'API MMDevice alfabetizzerà gli ID endpoint per determinare quale endpoint selezionare come impostazione predefinita. Ad esempio, se un adattatore audio ha connettori line-out e line-in e il file INF associato non seleziona uno per essere l'impostazione predefinita al momento dell'installazione, l'API MMDevice identifica quali ID endpoint sono prima alfabeticamente e imposta tale connettore come impostazione predefinita. Questa selezione persiste dopo il riavvio del sistema perché gli ID endpoint sono persistenti. Tuttavia, la selezione non persiste se un endpoint di classificazione superiore (ad esempio, un secondo adattatore con un connettore microfono) viene visualizzato nel sistema.