Audio Sessions

Une session audio est un groupe de flux audio connexes 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 uniformément les paramètres de volume et de désactivation spécifiés par le client à 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 comme 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 de flux. Le flux conserve son appartenance à la session pendant toute la durée de vie du flux. Une fois qu’un objet de flux est créé, l’objet existe jusqu’à ce qu’un client libère la dernière référence compté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 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 s’effectue par le biais d’un appareil 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 tant qu’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 le volume et de désactiver les paramètres 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 son pour chaque session de rendu active ou récente dans le système. Grâce à ces contrôles, les utilisateurs peuvent ajuster le volume et désactiver le son des paramètres pour toutes les sessions du système.

Le programme Sndvol affiche actuellement les 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 se trouve dans l’état d’exécution . Un flux inactif se trouve dans 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 donnée, le système change l’état de la session de l’inactif à l’expiration.

Sndvol affiche les contrôles de volume et de désactivation pour toutes les sessions de rendu actives et inactives. Sndvol supprime le volume et les contrôles de désactivation pour une session lorsque l’état de la session passe de l’inactif à l’expiration 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 nombre final de références sur le dernier objet de flux restant dans la session.) L’une des exceptions à 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 interprocesseurs qui combinent des flux à partir 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 contrôle de volume unique 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 pour les paramètres de contrôle pour les sessions de rendu spécifiques au processus, les paramètres de contrôle des sessions de rendu interprocesseurs sont, par défaut, persistants entre les redémarrages du système. WASAPI fournit ce comportement principalement pour l’avantage des sons de notification système, qui doivent conserver les paramètres de volume et de désactivation de l’utilisateur, car la combinaison d’applications varie au fil du temps.

Le programme Sndvol étiquette le contrôle de volume pour 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 plutôt un nom par défaut et une icône par défaut. 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. Uniquement dans le cas de sessions spécifiques au processus, 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, seul 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 sont pas. Pour vous 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.
• Que la session soit une session spécifique à un processus ou à un processus, une session spécifique au processus contient uniquement des flux du processus du client.

Ces informations sont suffisantes pour distinguer une session particulière de toutes les autres sessions sur le 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 interprocesseur 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 dans 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 interprocesseur comme distincte des sessions spécifiques au processus, même s’ils partagent le même GUID de session.

Par exemple, dans Windows Vista, les API de niveau supérieur telles que les fonctions waveOutXxx multimédia Windows et DirectSound attribuent généralement les flux audio qu’ils créent à des sessions spécifiques aux processus par défaut identifiées par la valeur GUID de session GUID_NULL. Pour les clients de ces API, la session par défaut pour chaque processus client est distincte des sessions par défaut pour d’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 interprocesseurs identifiée par la valeur GUID de session GUID_NULL, le système traite cette session inter-processus comme distincte des sessions spécifiques aux processus par défaut qui partagent le même GUID de session. En conséquence, le programme Sndvol affiche un contrôle de volume distinct pour la session spécifique au processus par défaut de chaque client et 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 est associée à un seul appareil de point de terminaison audio. Si deux sessions ont des GUID de session identiques et des ID de processus, mais qu’elles sont associées à différents appareils, 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 appareil 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 muet 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 des paramètres de volume et de désactivation différents 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 à arrêter. Plus tard, si une nouvelle instance de l’application crée une session spécifique au processus avec le même GUID de session que précédemment, cette session hérite du volume précédemment enregistré et des paramètres de désactivation.

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 par le biais de 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