Debugging WSLg Audio: PulseAudio Playback, Microphone Capture, and Routing

WSLg audio is a host-to-guest integration path, not a physical sound card that Linux owns. Microsoft’s WSLg project runs a PulseAudio server in its system distribution. Its playback sink and microphone source plugins transfer audio through the WSLg remote-display path to the Windows host. The regular user distribution receives connection settings such as PULSE_SERVER so Linux applications can use that server.

That architecture gives a useful debugging boundary: first prove the user distro can reach the WSLg PulseAudio server, then prove the expected sink or source exists, then test playback or capture with a small client, and only then debug the target application. Installing another audio daemon, changing an application’s backend, and restarting all of WSL before collecting evidence can obscure the failing layer.

Understand which component owns each part

The Linux application is a PulseAudio client. It connects to the WSLg-provided server socket, commonly exposed in the distro as /mnt/wslg/PulseServer. WSLg’s system distribution hosts the PulseAudio process and its RDP sink/source modules. Windows owns the physical output and input devices and their host-side policy. Therefore, Linux can report a PulseAudio server and visible sink even when the Windows output is muted, the wrong device is selected, the microphone is unavailable to desktop apps, or an audio stream cannot be created.

This also distinguishes protocol compatibility from hardware discovery. The expected path is PulseAudio-compatible playback/capture through WSLg; do not expect the distro to enumerate the host’s hardware as a native PCI/ALSA sound card merely because a GUI audio app opens. Programs that speak only a different audio API may need that distribution’s compatibility library or a supported client backend.

WSLg is shared infrastructure for Linux GUI and audio applications. It is separate from systemd inside an Ubuntu user distro, and the Linux user distro’s own PulseAudio/PipeWire service should not be started casually to replace WSLg’s server. A local daemon can redirect applications away from the host integration or compete for expected sockets and environment variables.

Capture the host and distro version before troubleshooting

From Windows, record the Windows build and installed WSL/WSLg component versions. Keep a WSL terminal open while reproducing the problem:

wsl.exe --version
wsl.exe --status
wsl.exe --list --verbose

Inside the affected Linux distribution, inspect the inherited audio and GUI variables and shared mount:

printf 'PULSE_SERVER=%s\nDISPLAY=%s\nWAYLAND_DISPLAY=%s\n' \
  "$PULSE_SERVER" "$DISPLAY" "$WAYLAND_DISPLAY"
test -S /mnt/wslg/PulseServer && echo "WSLg PulseAudio socket exists"

Do not assume that every GUI environment variable must be used by a particular application, but a missing PULSE_SERVER or socket is strong evidence that the application cannot reach the default WSLg audio endpoint. Search shell startup files, IDE launch configurations, containers, and service units for an override that points PULSE_SERVER at localhost, an obsolete path, or a locally started daemon. WSLg’s default environment is set for the user distro at startup. Changes to WSL startup configuration or WSLg settings require the relevant distro or WSL restart; a shell startup-file change can instead be tested in a newly launched shell. Closing a terminal tab alone may leave the distro running.

Inspect the server, sinks, and sources with PulseAudio tools

Install the command-line client utilities if needed. This installs utilities such as pactl, paplay, and parecord; it is not the same as starting a second PulseAudio server:

sudo apt update
sudo apt install pulseaudio-utils
pactl info
pactl list short sinks
pactl list short sources

pactl info tests whether a compatible server answers. The short sink/source lists reveal the endpoints visible to that client. The current WSLg project configures a playback sink named RDPSink and a capture source named RDPSource; the actual server output remains the runtime authority. Use the listed name rather than assuming an index such as 0 or copying a device name from another machine.

If pactl cannot connect, verify the socket path, environment, and distro lifecycle first. Do not try pulseaudio --start as a generic repair. If pactl connects but there is no expected endpoint, capture the WSLg version and logs before editing PulseAudio configuration. If endpoints are present but only one direction fails, keep playback and capture diagnosis separate: an output sink can work while the microphone source is unavailable, and vice versa.

Test playback and capture independently

For playback, use a known, non-sensitive WAV file and choose a sink from pactl list short sinks:

paplay --device=RDPSink /path/to/known-audio.wav

Replace RDPSink with the exact sink name shown on your system. If the client reports an unknown sink, the audio file is not the first thing to debug; re-check the endpoint list and use the default sink once as a control. Then confirm the Windows output device, application mixer level, mute state, and whether another Windows application can produce sound through the same host output.

For microphone capture, choose the source from pactl list short sources and record a short test file:

parecord --device=RDPSource --file-format=wav /tmp/wslg-mic-test.wav

Replace RDPSource with the exact listed source name, speak briefly, and stop the command with Ctrl-C. Then check that the file has nonzero audio data and play it back through the working sink. A WAV header without samples, a timeout, or a file that contains only silence is evidence to keep investigating the capture path; it is not proof that a voice-recognition application is at fault.

Confirm Windows microphone access and device selection using Windows privacy and sound settings. If Windows blocks desktop applications from using the microphone, Linux-side PulseAudio tools cannot override that host policy. Also check whether another app has exclusive control of a device and whether the same physical microphone works in a Windows recorder application. Microsoft’s current Windows guidance distinguishes microphone access, app access, and desktop-app access, so check the applicable setting for the host and workload.

Route application failures to the right layer

If both paplay and parecord work but one GUI application has no audio, the transport is likely functional and the application path deserves attention. Inspect the app’s selected output/input device, backend, sandbox permissions, and environment. Launch it from the same terminal where pactl info succeeds so it inherits the same PULSE_SERVER. If it runs inside a container, compare the container’s environment and socket mount with the host distro; a process in a container does not automatically inherit WSLg integration just because its parent command was launched from WSL.

If a program expects ALSA, verify which ALSA-to-PulseAudio plugin and device selection its distribution provides. WSLg’s documented architecture is PulseAudio-based; it does not promise that every application which opens a raw ALSA hardware device will work without a compatibility layer. Avoid replacing /etc/asound.conf or ~/.asoundrc globally until the application’s backend is known, and keep a copy of the prior configuration for rollback.

If the tools and multiple apps fail in the same direction, check the Windows side, WSLg component version, and WSLg logs. Microsoft’s WSLg project documents that its PulseAudio process writes a log in the WSLg shared area by default. Treat those logs as diagnostic evidence and keep them with the time of reproduction, WSL version, distro, selected sink/source, and exact client error.

The WSLg repository also documents optional debugging configuration for PulseAudio logging. Use that only as a temporary diagnostic on the configuration path appropriate to your WSL servicing channel; those debugging switches are not everyday distro settings and should be removed after capture. Do not edit the read-only WSLg system distribution or install packages into it as a workaround.

Restart only after capturing state

After saving outputs and logs, restart the affected distro from PowerShell:

wsl.exe --terminate Ubuntu-Dev
wsl.exe --distribution Ubuntu-Dev

If the shared WSLg/VM state itself needs a clean restart, wsl --shutdown stops every running distro and the WSL 2 utility VM. Use it only when that broader interruption is acceptable, then start the distro and repeat the same pactl and playback/capture tests. A restart that temporarily restores sound is useful evidence, but it is not a durable fix if an environment override, conflicting daemon, or host device policy reappears.

Acceptance test for a WSLg audio workflow

Record one successful playback and one successful capture from a known application, including the exact sink/source names. Repeat after closing and reopening the distro; if the workflow depends on Windows sleep, docking, Bluetooth, or switching host audio devices, test those transitions as well. Confirm the Windows-selected device still routes audio and the Linux application does not require a private workaround that disappears when its terminal or distro restarts.

For an operational bug report, include Windows build, wsl --version, distro name/release, PULSE_SERVER, socket existence, pactl info, sink/source listings, whether playback and capture fail independently, and relevant WSLg logs. Do not attach recordings unless they are necessary and approved; microphone test files can contain private conversations. This evidence separates a Windows device issue, a WSLg transport issue, and an application-specific backend issue without changing multiple layers at once.

Related:

Sources: