Audio distant ne fonctionne pas : correctifs de routage

Rien ne met fin à une session à distance aussi vite que l'absence de son. Vous pouvez voir l'application, contrôler la souris, mais de l'autre côté c'est silencieux — pas de sons de notification, pas de vidéos, pas d'audio de conférence.

Rien ne tue une session distante plus vite que l’absence de son. Vous voyez l’application, contrôlez la souris, mais l’autre côté reste muet — pas de notifications, pas de vidéos, pas d’audio de conférence. Si vous avez tapé "remote desktop audio" dans une barre de recherche parce que l’audio n’est pas routé de la machine distante vers vos enceintes locales (ou inversement), ce guide explique les vérifications pratiques et les correctifs qui résolvent le problème sur Windows, macOS et Linux.

Comment fonctionne réellement le routage audio en bureau à distance

Au niveau basique, l’audio en bureau à distance n’est que de la redirection E/S sur le réseau : l’hôte distant capture l’audio (microphone ou sortie système), l’encode, le streame via le protocole de session distante, le client le décode et le joue sur l’appareil local. Cela paraît simple, mais il existe trois points de défaillance courants :

Paramètres et politiques : le protocole distant peut être configuré pour bloquer la redirection audio (ou n’autoriser que le micro sans la lecture).
Stacks audio serveur/client : incompatibilités ou modules manquants sur l’hôte (PulseAudio / PipeWire sur Linux, Windows Audio Service sur Windows) empêchent la capture/lecture.
Contraintes réseau et codec : pare-feu, mauvais ports ou incompatibilités de codec peuvent empêcher la livraison ou le décodage correct des paquets audio.

Différents outils distants gèrent ces étapes différemment. RDP expose des options explicites de redirection audio. TeamViewer et AnyDesk implémentent des codecs et pilotes propriétaires et fonctionnent souvent immédiatement pour de l’audio Windows-vers-Windows. Les solutions open-source (Tenvo, RustDesk, VNC+PulseAudio) s’appuient sur le stack audio de l’hôte et nécessitent parfois une configuration supplémentaire. Si vous comparez les outils, consultez notre article sur rustdesk-vs-anydesk pour le contexte sur les différences entre stacks open-source et propriétaires.

Checklist rapide — correctifs à essayer en 10 minutes

Si vous voulez juste la voie la plus rapide vers « ça marche », essayez ces étapes dans l’ordre. Ce sont les correctifs courants et peu coûteux que nous voyons le plus souvent.

Redémarrez les services audio : sous Windows, redémarrez les services Windows Audio et Windows Audio Endpoint Builder. Sous Linux, redémarrez PulseAudio ou PipeWire :
```
systemctl --user restart pipewire pipewire-pulse
```
ou
```
pulseaudio -k && pulseaudio --start
```
.
Vérifiez les paramètres du client : dans le client RDP Windows (mstsc) ouvrez Afficher les options → Ressources locales. Sous "Remote audio", cliquez sur "Settings…" et réglez "Remote audio playback" sur "Play on this computer". Pour d’autres clients, assurez-vous que "Share audio" ou équivalent est activé.
Vérifiez les périphériques par défaut : assurez-vous que le périphérique de lecture local est activé et que l’hôte distant a un périphérique de sortie par défaut défini. Essayez de régler les deux sur un périphérique stéréo simple 44,1/48 kHz (beaucoup d’encodeurs distants n’aiment pas les formats exotiques).
Désactivez temporairement le pare-feu/AV (brièvement) : les règles de pare-feu peuvent bloquer les ports audio distants ou le service distant. Testez avec le pare-feu désactivé pour éliminer cette hypothèse.
Essayez un client différent : si RDP échoue, testez TeamViewer ou AnyDesk pour déterminer si le problème est spécifique au protocole. Ces applications propriétaires gèrent souvent mieux l’audio cross-OS.

Hôte ou client Windows : RDP et paramètres natifs

Windows est l’environnement que la plupart des gens utilisent pour RDP. Deux cas distincts importent : vous vous connectez d’un client Windows vers un serveur Windows (mstsc / RDP), ou vous vous connectez vers un hôte Windows depuis une autre plateforme.

Vérifiez le client (mstsc)

Sur la machine cliente lancez mstsc.exe → Afficher les options → Ressources locales. Sous "Remote audio", cliquez sur "Settings…" et confirmez :

Remote audio playback : Play on this computer
Remote audio recording : Record from this computer (si vous avez besoin de la redirection du microphone)

Si vous utilisez l’application Remote Desktop depuis le Microsoft Store, les mêmes options apparaissent dans les paramètres de session. Vérifiez aussi dans le panneau Son local que le périphérique de lecture souhaité est actif et n’est pas en "mode exclusif" qui bloquerait les autres applications.

Vérifiez la configuration de l’hôte (serveur)

Sur l’hôte Windows (la machine à laquelle vous accédez), confirmez que le service Windows Audio est en cours d’exécution :

sc query Audiosrv
sc query AudioEndpointBuilder

Si l’un est arrêté, démarrez-le :

net start Audiosrv
net start AudioEndpointBuilder

La stratégie de groupe peut aussi bloquer la redirection audio dans les sessions RDP. Vérifiez gpedit.msc → Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Device and Resource Redirection. Confirmez que "Allow audio and video playback redirection" et "Allow audio recording redirection" sont activés ou non configurés.

RDP pour le multimédia : codecs et fréquences d’échantillonnage

Les encodeurs RDP préfèrent des formats standards. Si l’application distante émet à une fréquence d’échantillonnage élevée ou en multicanal (ex. 192 kHz ou 5.1), essayez de basculer l’hôte en stéréo 44,1 kHz ou 48 kHz. Dans le panneau Son → Périphérique de lecture → Propriétés → Avancé, réglez le format par défaut sur 2 canaux 16 bits 44100/48000 Hz et retentez.

Hôtes et clients Linux : pièges PulseAudio, PipeWire et xrdp

Les stacks audio Linux varient. Ubuntu 22.04 et de nombreuses distributions contemporaines utilisent PulseAudio ou PipeWire. Les serveurs de bureau à distance comme xrdp ou VNC ne capturent pas automatiquement l’audio du bureau sans modules supplémentaires.

Symptômes courants et correctifs

Pas d’audio dans une session xrdp : installez et activez pulseaudio-module-xrdp ou utilisez l’intégration sink de PipeWire. Sur Debian/Ubuntu :
```
sudo apt install xrdp pulseaudio-module-xrdp
```
puis redémarrez les services :
```
sudo systemctl restart xrdp
systemctl --user restart pulseaudio
```
Client PulseAudio lancé en root : certaines configurations xrdp exécutent votre session sous un utilisateur différent — assurez-vous que PulseAudio s’exécute par session (instance systemd user) et non en root.
PipeWire : les bureaux récents comme Fedora 35+ ou Ubuntu 22.10 utilisent PipeWire par défaut. Assurez-vous que pipewire-pulse est installé (il fournit une couche de compatibilité PulseAudio) et redémarrez les services utilisateur PipeWire :
```
systemctl --user restart pipewire pipewire-pulse
```

Commandes utiles pour le diagnostic

pactl list sinks short        # list playback sinks
pactl list sources short      # list recording sources
pactl info                    # shows server (Pulse/PipeWire) info
journalctl --user -u pipewire -f   # live PipeWire logs

Si vous ne voyez aucun sink, le serveur audio du bureau n’a pas créé de sink pour la session utilisateur à laquelle xrdp se connecte. Créer une instance PulseAudio par session stable ou utiliser les services par-utilisateur de PipeWire résout ce problème. Pour xrdp spécifiquement, suivez la doc de la distribution pour activer pulseaudio-module-xrdp ou configurez /etc/xrdp/startwm.sh pour démarrer PulseAudio par session.

Hôtes et clients macOS : limitations de capture et contournements

macOS rend historiquement la capture audio système plus difficile : la plateforme n’inclut pas de périphérique virtuel de loopback intégré. Les sessions distantes basées sur VNC ne transmettent généralement pas le son système. Chrome Remote Desktop prend en charge la lecture audio pour certaines configurations, mais le comportement dépend de la version de macOS et de l’application cliente.

Options pratiques :

Utiliser une solution matérielle : connecter un câble virtuel (interface audio USB) et router l’audio macOS vers cet appareil, puis partager l’entrée micro depuis ce périphérique. C’est peu élégant mais fonctionne dans certains cas.
Installer un périphérique audio virtuel : BlackHole (open-source) ou Loopback/Soundflower permettent aux applications de capturer l’audio système. Une fois installé, définissez la sortie système sur BlackHole et configurez un pass-through vers le périphérique physique pour conserver la surveillance locale.
Utiliser TeamViewer/AnyDesk : ces solutions embarquent des pilotes audio capables de capturer et streamer l’audio macOS de manière plus transparente que certains outils open-source. Si l’audio macOS est critique, ces options propriétaires génèrent souvent moins de frictions pour les utilisateurs.

Pour des détails sur la connexion depuis macOS ou la configuration d’un client macOS, notre article remote-desktop-for-mac contient des astuces spécifiques à la plateforme.

Clients mobiles, audio à faible latence, et quand un bureau à distance n’est pas l’outil adapté

Les applications mobiles de bureau à distance (Android, iOS) priorisent souvent l’économie de bande passante et de batterie au détriment de l’audio. Si l’audio est essentiel sur mobile, vérifiez les paramètres de l’application pour "Play audio" ou "Use device audio". Les clients Android offrent généralement plus de contrôles que iOS en raison des restrictions de la plateforme.

Si vous avez besoin d’une latence très basse et d’une grande fidélité (collaboration musicale, streaming DAW, audio pro), un bureau à distance n’est pas l’outil adapté. Utilisez une solution audio-over-IP comme JACK sur réseau, Dante, ou des outils spécialisés comme Jamulus ou JackTrip. L’audio en bureau à distance suffit pour la voix, les notifications et les pistes vidéo ; il n’est pas conçu pour des performances musicales sous 20 ms de latence.

Quand essayer un autre outil (et lesquels)

Soyez réaliste sur ce que le protocole distant peut accomplir. Quelques points de guide :

Si vous avez besoin d’un forwarding audio cross-plateforme robuste avec une configuration minimale, TeamViewer et AnyDesk "fonctionnent souvent immédiatement" sur Windows et macOS car ils incluent des pilotes et codecs propriétaires. Consultez nos comparatifs anydesk-vs-teamviewer-2026 et best-teamviewer-alternatives pour les compromis.
Si vous souhaitez une pile open-source auto-hébergée et que la configuration audio Linux ne vous effraie pas, Tenvo et d’autres solutions auto-hébergées sont viables mais peuvent nécessiter l’installation de pulseaudio-module-xrdp, pipewire-pulse, ou de périphériques virtuels sur macOS.
Si le seul manque est la capture du microphone vers la machine distante (et non la lecture), assurez-vous que le client autorise la redirection du micro et que l’application hôte est configurée pour utiliser le périphérique redirigé.

Honnêtement : les outils propriétaires sont parfois meilleurs pour l’audio cross-OS parce qu’ils contrôlent les deux extrémités du pipeline et peuvent fournir des codecs/ pilotes personnalisés. Les stacks open-source peuvent atteindre le même niveau avec du travail et une configuration adaptée, mais attendez-vous à des étapes supplémentaires pour obtenir l’équivalence sur macOS ou des bureaux Linux atypiques.

Checklist pas-à-pas pour un diagnostic complet

Suivez cette checklist ordonnée lorsque les "correctifs rapides" n’ont pas aidé. Ne sautez pas d’étapes — elles réduisent rapidement le point de défaillance.

Reproduisez et notez les symptômes : lecture seulement, microphone seulement, ou les deux. Notez l’OS client et hôte et l’outil distant utilisé (mstsc, xrdp, Tenvo, TeamViewer, AnyDesk).
Sur l’hôte : confirmez que le service audio tourne (Windows : Audiosrv ; Linux : PulseAudio/PipeWire). Redémarrez si nécessaire.
Sur le client : confirmez que "share audio" / "play on this computer" est activé.
Basculez temporairement l’hôte et le client sur des périphériques stéréo simples 44.1/48 kHz.
Vérifiez le pare-feu : autorisez le protocole distant (RDP TCP 3389, ports personnalisés pour Tenvo, ou permissions spécifiques pour TeamViewer/AnyDesk). Si vous utilisez Tenvo en auto-hébergement, assurez-vous que votre relay/port-forwarding est configuré (voir notre article remote-desktop-without-port-forwarding pour les options réseau).
Essayez un autre client ou protocole : un test rapide avec TeamViewer/AnyDesk peut indiquer si l’audio est spécifique au protocole.
Collectez les logs : Windows Event Viewer (Application/Système), logs PulseAudio/pipewire via journal, ou les logs Tenvo dans ~/.config/tenvo/logs si applicable.

Exemples de correctifs — snippets à copier/coller

Linux (Ubuntu) xrdp + PulseAudio : installez le module et redémarrez :

sudo apt update
sudo apt install xrdp pulseaudio-module-xrdp
sudo systemctl enable --now xrdp
systemctl --user restart pulseaudio

Redémarrage PipeWire (session utilisateur) :

systemctl --user restart pipewire pipewire-pulse wireplumber

Windows : vérifier et démarrer les services audio depuis une invite élevée :

sc query Audiosrv
net start Audiosrv
sc query AudioEndpointBuilder
net start AudioEndpointBuilder

Notes finales et attentes réalistes

L’audio en bureau à distance est fiable pour les usages typiques : appels vocaux, lecture vidéo, alertes. N’attendez pas une fidélité de studio ni une latence sous 20 ms. Quand tout semble correctement configuré mais que l’audio reste médiocre, examinez si les conditions réseau (perte de paquets, jitter), une saturation CPU pour l’encodeur, ou le format audio de l’application sont les véritables goulots d’étranglement.

Si vous préférez un bureau à distance open-source et voulez éviter l’approche boîte noire des apps propriétaires, Tenvo vise la prévisibilité et l’extensibilité — mais vous devrez peut‑être ajuster le stack audio hôte sur Linux ou ajouter un périphérique audio virtuel sur macOS. Téléchargez Tenvo ou consultez les options de tarification et d’hébergement sur /download et /pricing pour tester sa gestion de l’audio dans votre environnement.

Pour des guides d’installation spécifiques à chaque plateforme, notre walkthrough Windows (setup-remote-access-windows) et l’article macOS (remote-desktop-for-mac) contiennent des astuces supplémentaires et des captures d’écran.

Si vous avez suivi ces étapes et que le problème persiste, collectez les logs mentionnés ci‑dessus et ouvrez un ticket ou un fil de support en indiquant précisément les versions hôte/client (par exemple : Windows 11 22H2, Ubuntu 22.04, macOS Ventura 13.4), l’outil distant et sa version, ainsi que l’ensemble des symptômes. Cela accélère le diagnostic.

Prêt à tester un bureau à distance open configurable qui ne vous surprendra pas avec des pilotes cachés ? Téléchargez Tenvo sur /download et testez l’audio sur vos machines — et si vous avez besoin d’options managées, consultez /pricing pour les choix de relay et d’hébergement.