Condividi tramite

Algoritmo di Costruzione degli Endpoint Audio

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 di sistema ai dispositivi di acquisizione multiplexed (MUXed) e per facilitare l'uso di topologie che coinvolgono più pin host e più pin bridge o entrambi.

In Windows XP il modello audio usa 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 dispositivo audio è stato riprogettato per rappresentare meglio il dispositivo con cui l'utente interagisce fisicamente.

Con due nuove API in Windows Vista, l'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 rimozioni 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 ed eseguire le azioni appropriate.

L'elenco seguente riepiloga il funzionamento dell'algoritmo usato da AudioEndpointBuilder:

  1. Cerca eventuali pin di ponte non connessi.

  2. Crea un endpoint per tutti i pin del bridge non connessi. Ad esempio, quando AudioEndpointBuilder trova un pin di 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.

  3. Imposta le proprietà predefinite per l'endpoint. Ad esempio, AudioEndpointBuilder imposta il nome, l'icona e il fattore di forma.

  4. Determina se è presente un percorso dall'endpoint a un pin host che supporta la modulazione a codifica di impulsi (PCM), il codec audio AC3 (AC3) o Windows Media Video (WMV). Un pin host è una struttura KSPIN con il relativo membro Communication impostato su KSPIN_COMMUNICATION_SINK o KSPIN_COMMUNICATION_BOTH. Per altre informazioni sulla struttura KSPIN, vedere KSPIN.

  5. Popola l'endpoint PropertyStore con informazioni sulle proprietà dalle chiavi del Registro di sistema dell'interfaccia del dispositivo audio.

  6. 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 Passo 4 e il rilevamento del jack non è supportato da questo endpoint.

  7. 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 multiplexati (MUX) e de-multiplexati (DEMUX) vengono gestiti automaticamente ed enumerati dal servizio AudioEndpointBuilder.

Se sviluppi il tuo driver di dispositivo audio e il file INF per lavorare con il tuo dispositivo audio e sviluppare un'applicazione audio o entrambi, è consigliabile tenere presenti i problemi e le procedure consigliate seguenti. Quando si sviluppano driver e applicazioni tenendo presenti questi consigli, 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 degli altoparlanti, il nome è stato integrato nel codice come "Speakers" e non può essere modificato dal tuo driver o da un'applicazione di terze parti.

  • Topologie non ottimali. Alcune topologie vengono considerate non ottimali a causa dell'algoritmo usato da AudioEndpointBuilder per enumerare gli endpoint. Ad esempio, quando si crea una di queste topologie subottimali, si creano pin host che hanno endpoint nascosti e non sono visibili per l'AudioEndpointBuilder, oppure si creano splitter (endpoint suddivisi) che l'AudioEndpointBuilder non può collegare ai pin host associati.

    • Endpoint nascosti

      Nel diagramma seguente, il filtro KS viene mostrato in modo da avere due pin host collegati a un singolo pin del bridge (altoparlante).

      Diagramma che mostra la topologia problematica con il pin host AC-3 e l'endpoint nascosto sul lato sinistro, singoli PCM e AC-3 che condividono un singolo filtro.

      Quando AudioEndpointBuilder individua il pin del bridge, traccia un percorso di nuovo a uno solo dei pin host, imposta i valori predefiniti per il pin del bridge, crea e attiva un endpoint speaker e continua a individuare altri pin del bridge. Di conseguenza, l'altro pin host rimane nascosto da AudioEndpointBuilder.

      Diagramma che illustra la topologia consigliata con percorsi tracciabili tra i pin host e gli endpoint.

      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 di bridge (Speaker e SPDIF).

    • Divisori

      Un altro tipo di topologia non ottimale viene creato quando un pin host si connette a più pin del bridge. Il diagramma seguente illustra una topologia in cui un pin host PCM si connette a un pin del bridge speaker e a un pin del bridge SPDIF.

      Diagramma che illustra la topologia problematica con due endpoint connessi a un pin host e a un singolo PCM.

      In questo caso AudioEndpointBuilder individua un pin di bridge e traccia un percorso al pin dell'host PCM, imposta i valori predefiniti e quindi crea e attiva un endpoint speaker. Quando AudioEndpointBuilder individua il pin del bridge successivo, traccia un percorso 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 a uno di essi rende impossibile trasmettere l'altro contemporaneamente; in altre parole, si tratta di endpoint che si escludono a vicenda.

      Il diagramma seguente illustra una riprogettazione di questa topologia in cui esistono connessioni separate. L'architettura consente all'AudioEndpointBuilder di tracciare un percorso fino al pin host PCM per ciascuno dei due pin del bridge.

      Diagramma che illustra la topologia consigliata con percorsi tracciabili tra pin host ed endpoint, con due PCM sul lato sinistro.

  • Formato endpoint. Quando il motore audio è in esecuzione in modalità condivisa, il formato per l'endpoint presuppone un'impostazione specifica come indicato 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 il Pannello di controllo o un'applicazione di terze parti per modificare il formato dell'endpoint.

  • Dispositivo predefinito. L'endpoint impostato come dispositivo predefinito viene selezionato al momento dell'installazione usando le informazioni nel file INF. Al termine dell'installazione, è necessario usare il Pannello di controllo o un'applicazione di terze parti per selezionare un altro endpoint come endpoint predefinito.

Nota Se il file INF non seleziona un endpoint da impostare come predefinito durante l'installazione, un'applicazione client può usare l'API MMDevice per selezionare un endpoint. L'API basa la selezione sulla classificazione dei fattori di forma e se l'endpoint è un endpoint di rendering o di acquisizione. Nella tabella seguente viene illustrato l'ordine di selezione.

Eseguire il rendering del rango Rango di cattura
Altoparlanti Microfono
Uscita di linea Ingresso linea
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 predefinito. Ad esempio, se una scheda audio include connettori line-out e line-in e il file INF associato non ne seleziona uno come predefinito al momento dell'installazione, l'API MMDevice identifica quali ID endpoint sono i primi alfabeticamente e imposta tale connettore come predefinito. Questa selezione persiste dopo il riavvio del sistema perché gli ID endpoint sono persistenti. Tuttavia, la selezione non viene mantenuta se nel sistema viene visualizzato un endpoint con classificazione più elevata (ad esempio, un secondo adattatore con un connettore microfono).

  • Last updated on