Audio Sessions

Une session audio est un groupe de flux audio associés qu’un client WASAPI peut gérer collectivement. Les clients peuvent contrôler le niveau de volume et l’état de désactivation de chaque session individuelle. Le système applique le volume spécifié par le client et désactive uniformément les paramètres à tous les flux de la session.

Lorsqu’un client initialise un flux audio, il affecte le flux audio à une session audio. Pour plus d’informations, consultez IAudioClient::Initialize.

Une session audio contient des flux de rendu ou des flux de capture, mais pas les deux. Par défaut, les paramètres de volume et de désactivation d’une session de rendu sont persistants entre les redémarrages du système. Les paramètres de volume et de désactivation d’une session de capture ne sont pas persistants. (Une session qui contient des flux qui fonctionnent en mode bouclage est traitée de la même façon qu’une session de capture. Autrement dit, les paramètres de session ne sont pas persistants. Pour plus d’informations sur le mode bouclage, consultez Enregistrement de bouclage.)

Chaque flux audio appartient exactement à une session. Un client affecte un flux audio à une session particulière au moment où il initialise l’objet stream. Le flux conserve son appartenance à la session pendant toute la durée de vie du flux. Une fois qu’un objet stream est créé, l’objet existe jusqu’à ce qu’un client libère la dernière référence comptabilisée à l’objet, puis l’objet est supprimé.

Bien qu’un client ne puisse pas modifier la session à laquelle un flux existant est affecté, il peut obtenir un effet similaire en supprimant le flux (en libérant toutes les références à celui-ci), en créant un nouveau flux pour remplacer le flux supprimé et en affectant le nouveau flux à une autre session.

Chaque session de rendu représente un sous-ensemble des flux qui forment la combinaison globale qui est lue via un périphérique de point de terminaison audio particulier. La combinaison globale combine toutes les sessions de toutes les applications qui partagent l’appareil.

Souvent, une application avec plusieurs flux affecte tous ses flux à la même session. Toutefois, l’application peut, en option, affecter différents flux à différentes sessions. Tout flux que l’application n’affecte pas explicitement à une session appartient à la session par défaut.

Les applications audio classiques doivent éviter de modifier les paramètres de volume et de sourdine pour les sessions. Au lieu de cela, les utilisateurs contrôlent ces paramètres via les interfaces utilisateur des programmes de contrôle. Par exemple, dans Windows Vista, le programme fourni par le système, Sndvol.exe, affiche un contrôle de volume et un contrôle de désactivation pour chaque session de rendu active ou récemment active dans le système. Grâce à ces contrôles, les utilisateurs peuvent ajuster les paramètres de volume et de désactivation pour toutes les sessions du système.

Le programme Sndvol affiche actuellement des contrôles de volume pour les appareils de point de terminaison de rendu audio uniquement. Il n’affiche pas les contrôles de volume pour les appareils de capture audio.

Une session est active si elle contient un ou plusieurs flux actifs. Un flux actif est en cours d’exécution. Un flux inactif est à l’état arrêté. Une session devient active lorsque son premier flux devient actif. Une session devient inactive lorsque son dernier flux actif devient inactif. Une fois qu’une session a été inactive pendant une période de temps, le système change l’état de la session d’inactif à expiré.

Sndvol affiche les contrôles de volume et de mise en sourdine pour toutes les sessions de rendu actives et inactives. Sndvol supprime les contrôles de volume et de désactivation d’une session lorsque l’état de la session passe d’inactif à expiré ou lorsque la session se termine. (Une session se termine lorsque le dernier de ses flux est supprimé; autrement dit, lorsqu’un client libère le dernier nombre de références sur le dernier objet de flux restant dans la session.) La seule exception à cette règle concerne les sons de notification système. Sndvol affiche toujours les contrôles de volume et de désactivation pour les sons de notification système, quel que soit l’état de la session pour ces sons.

En règle générale, un flux appartient à une session qui s’étend uniquement sur le processus qui contient l’application qui a créé le flux. Toutefois, les applications ont la possibilité de définir des sessions inter-processus qui combinent des flux de deux processus ou plus.

WASAPI prend principalement en charge les sessions inter-processus afin que :

• Le programme Sndvol peut présenter à l’utilisateur un seul contrôle de volume pour gérer les sons de notification système dans toutes les applications.
• Un lecteur multimédia qui s’exécute dans un processus peut diffuser en continu du contenu protégé vers un programme de déchiffrement qui s’exécute dans un autre processus.

Comme les paramètres de contrôle pour les sessions de rendu spécifiques aux processus, les paramètres de contrôle pour les sessions de rendu inter-processus sont, par défaut, persistants entre les redémarrages système. WASAPI fournit ce comportement principalement pour le bénéfice des sons de notification système, qui doivent conserver les paramètres de volume et de muet de l’utilisateur à mesure que la combinaison d’applications varie au fil du temps.

Le programme Sndvol étiquette le contrôle de volume de chaque session avec un nom d’affichage et une icône. Un client a la possibilité d’attribuer explicitement un nom d’affichage et une icône à une session. Si le client ne fournit pas ces éléments, Sndvol affiche un nom par défaut et une icône par défaut à la place. Le nom par défaut incorpore des informations telles que le titre de la fenêtre d’application. L’icône par défaut est l’icône de la fenêtre d’application. Ce n’est que dans le cas de sessions spécifiques au processus que ces valeurs par défaut fournissent des informations significatives aux utilisateurs. Notez qu’une session interprocesseur peut être associée à plusieurs applications. Dans ce cas, seuls un nom d’affichage et une icône fournis par le client sont significatifs.

Bien que les paramètres de volume et de désactivation d’une session de rendu soient, par défaut, persistants entre les redémarrages du système, le nom d’affichage et l’icône fournis par le client ne le sont pas. Pour s’assurer que Sndvol affiche le nom et l’icône fournis par le client, le client doit attribuer explicitement le nom et l’icône à la session au moment où le client affecte le premier flux à la session. Le système conserve le nom d’affichage et l’icône d’une session uniquement jusqu’à ce que la session se termine.

Chaque session est identifiée par un GUID de session. Au moment où un client ouvre un flux, le client affecte ce flux à une session particulière. Le client fournit les deux informations suivantes pour identifier cette session :

• GUID de session.
• Qu’il s’agisse d’une session inter-processus ou d’une session spécifique au processus, une session spécifique au processus contient uniquement des flux provenant du processus du client.

Ces informations sont suffisantes pour distinguer une session particulière de toutes les autres sessions du même ordinateur. Le GUID de session d’une session spécifique au processus identifie de manière unique la session uniquement dans l’étendue du processus propriétaire de la session. En revanche, le GUID de session d’une session inter-processus est unique dans l’étendue de tous les processus qui s’exécutent sur l’ordinateur.

Dans le cas d’une session spécifique au processus, le système utilise une combinaison de GUID de session et d’ID de processus pour identifier de manière unique la session dans l’étendue de l’ordinateur. Par conséquent, si les clients de deux processus différents attribuent leurs flux respectifs à deux sessions spécifiques au processus avec des GUID de session identiques, le système traite les sessions comme distinctes, car leurs ID de processus sont différents. En outre, si une session inter-processus utilise le même GUID de session qu’une ou plusieurs sessions spécifiques au processus, le système traite la session inter-processus comme différente des sessions spécifiques au processus, même si elles partagent le même GUID de session.

Par exemple, dans Windows Vista, les API de niveau supérieur telles que les fonctions multimédias WaveOutXxx de Windows et DirectSound attribuent généralement les flux audio qu’elles créent à des sessions par défaut spécifiques au processus identifiées par la valeur GUID de session GUID_NULL. Pour les clients de ces API, la session par défaut de chaque processus client est distincte des sessions par défaut pour les autres processus clients, même si les sessions ont des GUID de session identiques. En outre, si une ou plusieurs applications attribuent des flux à la session inter-processus identifiée par la valeur GUID de session GUID_NULL, le système traite cette session inter-processus comme distincte des sessions par défaut spécifiques au processus qui partagent le même GUID de session. Par conséquent, le programme Sndvol affiche un contrôle de volume distinct pour la session par défaut spécifique au processus de chaque client, et il affiche un contrôle de volume supplémentaire pour la session inter-processus identifiée par la valeur GUID de session GUID_NULL, si cette session existe.

Chaque session n’est associée qu’à un seul appareil de point de terminaison audio. Si deux sessions ont des GUID de session et des ID de processus identiques, mais sont associées à des appareils différents, le système traite les deux sessions comme distinctes. Une session ne peut jamais contenir à la fois des flux de capture et de rendu, car un flux de capture ne peut être associé qu’à un périphérique de capture et un flux de rendu ne peut être associé qu’à un appareil de rendu.

Comme mentionné précédemment, les paramètres de volume et de désactivation d’une session sont persistants entre les redémarrages du système. Deux instances ou plus d’une application peuvent créer des sessions spécifiques au processus avec des GUID de session identiques. Par le biais du programme Sndvol, l’utilisateur peut sélectionner différents paramètres de volume et désactiver le son pour chacune de ces sessions. Une fois ces sessions terminées, le système conserve les paramètres de contrôle d’une seule de ces sessions, la dernière session à se terminer. Plus tard, si une nouvelle instance de l’application crée une session spécifique au processus avec le même GUID de session qu’auparavant, cette session hérite des paramètres de volume et de désactivation précédemment enregistrés.

Une application ne doit pas tenter d’ajouter un flux à ou de contrôler le niveau de volume d’une session appartenant à une autre application non liée. En outre, une application ne doit pas tenter de contrôler le niveau de volume de la session gérée par le système pour les sons de notification. Toutefois, une application peut lire un son via la session système pour les sons de notification en appelant la fonction PlaySound . Pour plus d’informations, consultez Sons de notification pour les applications audio héritées.

Une application peut s’inscrire pour recevoir des notifications lorsque l’état d’une session change. Pour plus d’informations, consultez Événements de session audio.

Dans de rares cas, une application qui crée une session spécifique au processus peut avoir besoin de consolider le contrôle des sessions spécifiques au processus pour deux instances d’application ou plus sous un seul contrôle de volume dans Sndvol. Pour plus d’informations, consultez Paramètres de regroupement.

Rubriques connexes

Guide de programmation