Configuration du réseau
Il existe plusieurs façons de se connecter à un autre serveur PulseAudio (connexion directe, tunnel, RTP) ou à un autre périphérique audio réseau (RTP, RAOP, Rygel).
Notez que toutes les méthodes décrites ici diffusent de l’audio PCM brut sur le réseau. Cela peut utiliser une grande partie de la bande passante du réseau (environ 1,4 Mb/s pour un son de qualité CD). Si vous obtenez un son saccadé, essayez de définir un taux d’échantillonnage inférieur pour le flux réseau. De plus, même si de nombreuses connexions WiFi peuvent supporter de tels débits, souvent la gigue de la latence des paquets rend la transmission audio à faible latence sur une liaison sans fil impossible dans la pratique.
Connexion directe
Définissez simplement la variable $PULSE_SERVER
d’environnement sur le nom d’hôte du serveur PulseAudio. Vous pouvez également modifier ~/.pulse/client.conf
ou /etc/pulse/client.conf
et définir default-server
. Voir Chaînes de serveur pour une explication du format. Dans cette entrée de FAQ , tous les emplacements où vous pouvez spécifier le serveur à utiliser sont répertoriés. Toutes les méthodes qui se connectent au démon sur le réseau à l’aide du protocole natif doivent charger module-native-protocol-tcp . Cela inclut les tunnels et les configurations Zeroconf. Avec ce module chargé, le serveur écoute sur le port 4713 les connexions client entrantes.
Autorisation
Pour l’authentification, vous avez besoin des mêmes cookies d’authentification de tous les côtés. Pour cette copie ~/.pulse-cookie
à tous les clients qui seront autorisés à se connecter. Alternativement, les cookies d’autorisation peuvent être stockés dans le serveur X11. Le serveur doit avoir chargé module-native-protocol-tcp . Pour activer tous les sons de tout le réseau, définissez l’ auth-anonymous=1
argument. Une option plus sécurisée consiste à gérer l’accès à ces serveurs avec une ACL IP. Cela peut ressembler à ceci dans votre script de démarrage /etc/pulse/default.pa
ou ~/.pulse/default.pa
pour PulseAudio :
load-module module-esound-protocol-tcp auth-anonymous=1 load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1;192.168.0.0/16
Ces deux modules ne sont pas chargés dans la configuration par défaut car ils pourraient ouvrir PulseAudio pour des attaquants distants.
X transfert
Si la $PULSE_SERVER
variable n’existe pas ou est vide, PulseAudio vérifiera alors les propriétés X11 sur la fenêtre racine. Ces propriétés ressemblent beaucoup aux variables d’environnement, mais seront disponibles à distance si vous vous connectez en SSH à une autre machine avec un transfert X11. Vous pouvez voir une liste des propriétés liées à PulseAudio en faisant :
xprop -root | grep PULSE
Les noms de variables utilisés sont les mêmes que ceux utilisés dans l’environnement, donc PulseAudio recherchera une propriété appelée PULSE_SERVER
. Notez que seules les propriétés X11 sont transmises via le tunnel SSH, mais le client pulseaudio se connecte toujours au serveur en utilisant son propre protocole natif.
Si vous ne souhaitez pas vous reconnecter au démon d’impulsion en cours d’exécution sur l’ordinateur qui a l’affichage X, vous pouvez soit définir PULSE_SERVER=localhost
à partir de la connexion SSH (assurez-vous que module-native-protocol-tcp est chargé) ou exécuter pax11publish -r
avant SSHing à l’ordinateur distant pour supprimer les propriétés de la fenêtre racine.
Utilisation d’un tunnel
Avec un tunnel, vous pouvez créer un nouveau récepteur qui transfère tout l’audio sur le réseau vers un autre serveur. Pour le puits du serveur distant, le tunnel ressemble à un autre flux se connectant sur le réseau. Il en va de même pour les sources. Voir la documentation sur module-tunnel pour plus de détails sur les arguments du module.
La configuration d’un tunnel nécessite un démon PulseAudio en cours d’exécution sur le serveur distant avec module-native-protocol-tcp chargé, tout comme avec la connexion directe. Une fois le tunnel configuré, les applications clientes se connectent au récepteur de tunnel sur le démon PulseAudio local. Cela présente l’avantage que vous pouvez basculer le flux de manière transparente entre un récepteur matériel local et le récepteur du tunnel. Avec une connexion directe, le client doit généralement être redémarré pour changer de serveur. Une connexion directe a l’avantage que le client a plus de contrôle sur les paramètres de mise en mémoire tampon.
mDNS
Afin d’éviter d’avoir à configurer manuellement le tunnel entre les ordinateurs d’un réseau, Zeroconf peut être utilisé.
Configurez module-zeroconf-publish
et module-zeroconf-discover
manuellement ou utilisez la case à cocher dans paprefs.
Vous pouvez vous connecter à d’autres serveurs de son fonctionnant sur le LAN en utilisant la technologie Zeroconf/ Avahi . Assurez-vous donc de compiler PulseAudio avec le support Avahi et de charger les modules Zeroconf sur toutes les machines du LAN. De plus, assurez-vous de charger le module-native-protocol-tcp
et qu’il autorise les connexions à partir d’autres hôtes, voir Autorisation ci-dessus.
#for servers load-module module-zeroconf-publish #for clients load-module module-zeroconf-discover
Ces modules ne sont pas chargés dans la configuration par défaut car ils pourraient ouvrir PulseAudio pour des attaquants distants.
RTP
RTP est le protocole de transfert en temps réel . Il s’agit d’un protocole bien connu pour le transfert de données audio et vidéo sur IP. Deux protocoles connexes sont SDP et SAP. SDP est le protocole de description de session et peut être utilisé pour décrire des sessions RTP. SAP est le protocole d’annonce de session et peut être utilisé pour annoncer des sessions RTP décrites avec SDP. (Les téléphones VoIP modernes basés sur SIP utilisent également RTP/SDP pour leurs sessions) Les trois protocoles sont définis dans les RFC IETF (RFC3550, RFC3551, RFC2327, RFC2327). Ils peuvent être utilisés à la fois en multidiffusion et en monodiffusion. PulseAudio utilise exclusivement la multidiffusion RTP/SDP/SAP contenant des données audio.
Pour plus d’informations sur l’utilisation de ces technologies avec PulseAudio, consultez la documentation des modules .
Comment puis-je utiliser PulseAudio pour diffuser de la musique depuis mon PC principal vers mon LAN avec plusieurs PC avec haut-parleurs ?
Du côté de l’expéditeur, créez un récepteur RTP :
load-module module-null-sink sink_name=rtp load-module module-rtp-send source=rtp.monitor set-default-sink rtp
Cela fera de rtp le récepteur par défaut, c’est-à-dire que toutes les applications écriront sur ce périphérique RTP virtuel par défaut. Du côté client, chargez simplement le module récepteur :
load-module module-rtp-recv
Vous pouvez maintenant écouter votre musique préférée du côté de l’expéditeur et tous les clients la diffuseront simultanément. BTW : Vous pouvez avoir plus d’une machine d’envoi configurée comme celle-ci. Les données audio seront mixées côté client.
Comment puis-je utiliser PulseAudio pour partager une seule prise LINE-IN/MIC sur l’ensemble du LAN ?
Côté émetteur, chargez simplement le module émetteur RTP :
load-module module-rtp-send
Côté récepteur, créez une source RTP :
load-module module-null-sink sink_name=rtp load-module module-rtp-recv sink=rtp set-default-source rtp_monitor
Désormais, les données audio seront disponibles à partir de la source par défaut rtp_monitor
.
Comment puis-je utiliser PulseAudio comme solution de conférence multidiffusion N:N basée sur RTP pour le LAN ?
Après avoir chargé tous les pilotes audio nécessaires à l’enregistrement et à la lecture, chargez simplement les modules récepteur et émetteur RTP avec les paramètres par défaut :
load-module module-rtp-send load-module module-rtp-recv
Tant que le démon PulseAudio s’exécute, les données du microphone sont diffusées sur le réseau et les données des autres hôtes sont lues localement. Veuillez noter que cela peut générer beaucoup de trafic. Par conséquent, envisagez de passer rate=8000 format=ulaw channels=1
au module expéditeur pour économiser de la bande passante tout en conservant une bonne qualité pour la transmission de la parole.
Puis-je avoir plus d’un groupe RTP multidiffusion ?
Oui! Utilisez simplement une nouvelle adresse de groupe multicast. Utilisez les arguments destination
/ sap_address
des modules RTP pour les sélectionner. Choisissez vos adresses de groupe dans la plage 225.0.0.x pour vous assurer que les données audio ne quittent jamais le LAN.
Merci de votez pour cet article :