Linux screen recording has no audio? Check these 7 things

The quick answer

If the picture records but the sound does not, check the audio path separately from the screen-capture path. In Screenix, confirm that the microphone or system-audio source is not set to Off, select the exact device, and watch its level meter before recording. For system audio, select the same output device that is currently playing the sound.

Understand the two audio paths

Linux audio tools use sink for a playback target such as speakers, HDMI, or headphones, and source for something applications can record. In the PulseAudio model, every sink automatically has a monitor source that exposes the sound being sent to that sink for recording. That monitor relationship is documented by PulseAudio.

Screenix discovers sinks and sources with pactl, falling back to wpctl when necessary. It passes the selected microphone source to FFmpeg and converts the selected output sink to its .monitor source for system audio. FFmpeg's PulseAudio input accepts either a named source or default. FFmpeg documents that input contract.

1. Check Screenix before changing Linux

Start with the controls that provide direct evidence. Open the microphone or system-audio picker, confirm the source is enabled, select the exact device, and watch the live meter. A moving meter means Screenix is receiving samples from that selected device before recording starts.

• Use Refresh if you connected USB, HDMI, or Bluetooth audio after opening the recorder.
• For system sound, choose the output where the sound is actually playing—not merely a similarly named device.
• Test microphone and system audio separately before selecting both.

Screenix checks requested sources before capture. If one is unavailable, it can continue recording video without that audio source and report a warning. That design explains how a valid video can still arrive without the requested sound.

2. Inspect the audio graph with wpctl

On a WirePlumber-managed PipeWire session, wpctl status lists the devices, sinks, sources, and active streams that WirePlumber currently manages. The upstream manual defines this output and the getting-started guide recommends it as the first graph overview.

wpctl status

Look under three headings:

• Sinks: playback targets such as built-in speakers, a USB interface, HDMI, or Bluetooth headphones.
• Sources: capture targets such as built-in, USB, or headset microphones.
• Streams: applications currently playing or recording audio.

If the device is absent here, Screenix cannot select it through that audio session. Fix device recognition or its active profile before changing recording settings.

3. Match the output sink to its monitor source

These are the same Pulse-compatible queries Screenix uses to discover outputs, inputs, and defaults:

pactl get-default-sink
pactl list short sinks
pactl list short sources

If pactl is not installed, keep using wpctl status for the graph overview and Screenix's refreshed device list. Screenix itself falls back to wpctl when pactl does not provide an input or output list.

Find the sink that is actually playing your audio. Then look for a source with the same name followed by .monitor. Screenix records that monitor source when you choose the sink in its system-audio picker.

On a PipeWire setup that runs pipewire-pulse, the server implements PulseAudio compatibility, and PipeWire states that common tools including pactl should keep working through it. See PipeWire's Protocol Pulse documentation.

4. Verify the microphone as a source

A microphone is a regular capture source, not a sink monitor. Screenix deliberately keeps .monitor entries out of its microphone list so the microphone picker and system-audio picker represent different jobs.

pactl get-default-source
pactl list short sources
wpctl get-volume @DEFAULT_SOURCE@

The last command reports the default source's volume and mute state. WirePlumber documents both the default-source identifier and the mute-aware volume query. If your intended microphone is not the default, select it explicitly in Screenix rather than assuming the fallback is correct.

If the microphone exists but its Screenix meter stays flat, confirm it is not muted in the desktop audio settings and that the selected source name matches the hardware you are speaking into.

5. Recheck after HDMI, USB, or Bluetooth changes

A newly selected default does not prove that every existing playback stream moved to it. WirePlumber's set-default targets new streams that request automatic connection, while PulseAudio's stream-restore behavior can reconnect a known stream to the device it used previously. WirePlumber documents the new-stream behavior, and PulseAudio documents remembered stream targets.

1. Start the audio you intend to record.
2. Use wpctl status to see its current playback stream and sink.
3. Refresh Screenix's device list.
4. Select that same sink in the system-audio picker and confirm the meter moves.

If you intentionally want another default, use the desktop audio settings or run wpctl set-default <sink-id> with the sink ID shown by wpctl status. Reopen the playback stream if it remains attached to its previous target.

6. Check WirePlumber before resetting anything

On a systemd-based system that uses WirePlumber, its own documentation recommends checking the user service and reading its journal:

systemctl --user status wireplumber
journalctl --user -u wireplumber

A healthy service plus a complete wpctl status graph points you back toward device selection and routing. A failed service or missing sinks and sources points toward the audio session itself. Both commands come from WirePlumber's getting-started guide.

Do not begin by deleting audio configuration or resetting WirePlumber state. Those actions change more than the recording route and remove useful evidence. Capture the status and journal output first.

7. Prove whether the file contains an audio stream

A media player can hide the difference between “no audio stream” and “an audio stream containing silence.” Use ffprobe to check the recording directly:

ffprobe -v error -select_streams a -show_entries stream=index,codec_name,channels,sample_rate -of default=noprint_wrappers=1 "recording.mp4"

For a valid, readable recording, no printed stream fields means the file has no audio stream. If the command prints an audio index and codec details, an audio stream exists, but this command alone does not prove that the captured samples are audible. The FFmpeg documentation defines audio-stream selection and entry filtering.

What each result means

Common questions

Why can Linux record video but not sound?

The screen stream and audio sources are selected through different paths. In Screenix, an unavailable requested audio source does not have to invalidate the video capture, so the video can continue with a warning and without that sound.

Does approving the Wayland screen-share prompt approve audio?

That prompt selects the monitor or window stream described by the XDG ScreenCast portal. Screenix's microphone and system-audio choices remain separate controls.

Should I use PipeWire or PulseAudio commands?

Use wpctl to inspect a WirePlumber-managed PipeWire graph. Use pactl for the Pulse-compatible sinks and sources that Screenix and FFmpeg record from. On systems running pipewire-pulse, both views describe the same active audio system through different interfaces.

Can Screenix record microphone and system audio together?

Yes. Screenix lets you select both independently and mixes both inputs into the recording. Testing each one alone first makes a missing route easier to identify.

Looking for setup instructions rather than troubleshooting? See the existing Linux screen recorder with audio guide.