Hear Your Microphone Through Speakers on Linux

Hearing a microphone through the same laptop that records it sounds simple until the first howl of feedback arrives. Linux can create the route in one command, whether your desktop runs PipeWire’s PulseAudio-compatible service or PulseAudio itself. The important part is choosing the right source and sink, starting quietly, and keeping the module ID so the route can be removed cleanly.

What the loopback actually creates

• A source output captures samples from the selected microphone/source.

• A sink input plays those samples into the selected speaker/headphone/sink.

• The audio server adapts buffering/resampling to keep source and sink clocks aligned.

• The requested latency is a target, not a guaranteed physical microphone-to-ear delay. Hardware, ALSA, Bluetooth, resampling, scheduling, and acoustic distance add latency.

• The route exists in the user audio session; ordinary pactl commands generally should not be run with sudo.

Confirm whether the audio server is reachable

$ pactl info | sed -n '1,20p'

Server String: /run/user/1000/pulse/native
...
Server Name: PulseAudio (on PipeWire ...)
Default Sink: ...
Default Source: ...

The client API can look like PulseAudio on PipeWire

• pactl talks to a PulseAudio protocol server; modern Ubuntu desktops commonly provide that protocol through pipewire-pulse.

• The server name/version gives context but exact text varies by distribution and release.

• Run inside the logged-in graphical user session with its user bus/runtime directory.

• If connection fails, inspect user services and environment before installing random packages or running audio tools as root.

Install the mixer UI if you want it

$ sudo apt update
sudo apt install pavucontrol

... package lists and proposed installation ...

pavucontrol is optional but excellent for routing

• The install changes system packages; review apt’s proposed transaction.

• pavucontrol exposes input/output devices and the loopback’s Recording and Playback streams.

• The loopback command itself needs pactl, commonly supplied by pulseaudio-utils or distribution dependencies.

• Other desktops provide native mixers, and PipeWire graph tools such as qpwgraph can visualize routing.

List exact microphone sources and output sinks

$ pactl list short sources
printf '\n--- sinks ---\n'
pactl list short sinks

52  alsa_input.usb-Example_Microphone-00.mono-fallback ... RUNNING
53  alsa_output.pci-0000_00_1f.3.analog-stereo.monitor ... IDLE

--- sinks ---
44  alsa_output.pci-0000_00_1f.3.analog-stereo ... RUNNING

Do not choose a monitor source by accident

• A source name containing .monitor captures what a sink is playing, not the physical microphone.

• Use stable symbolic names rather than numeric indices when possible; indices can change after reconnect/reboot.

• USB, analog, headset, webcam, Bluetooth, and HDMI profiles can expose several ports/devices.

• In pavucontrol, confirm the physical input meter reacts to speech before creating the loopback.

• Bluetooth headset profiles trade quality, direction, and latency; select a profile that actually exposes the required microphone and output.

Check and set the intended ports

$ pactl list sources
pactl list sinks

...
Ports:
    analog-input-mic: Microphone (...)
Active Port: analog-input-mic
...

A device can be correct while its port is wrong

• Inspect active port, mute, volume, profile, sample specification, availability, and properties.

• Laptop analog hardware may distinguish internal mic, headset mic, line input, speakers, and headphones.

• Use the desktop audio settings or documented pactl set-source-port / set-sink-port only with an exact listed port.

• A 2.5 mm or 3.5 mm plug may be electrically incompatible with the laptop jack; adapters do not automatically provide microphone bias, TRRS wiring, or line/mic-level conversion.

Create a named microphone-to-speaker loopback

$ source_name=alsa_input.usb-Example_Microphone-00.mono-fallback
sink_name=alsa_output.pci-0000_00_1f.3.analog-stereo

module_id=$(pactl load-module module-loopback \
  source="$source_name" \
  sink="$sink_name" \
  latency_msec=60 \
  source_dont_move=true \
  sink_dont_move=true)

printf 'Loopback module ID: %s\n' "$module_id"

Loopback module ID: 536870913

Save the numeric ID printed by pactl

• Replace the example names with values listed on your machine; shell variables reduce quoting mistakes.

• source selects capture and sink selects playback explicitly instead of relying on changing defaults.

• latency_msec=60 is a conservative starting request; tune from evidence rather than copying an extreme 1 ms target.

• The dont_move options keep desktop policy from silently moving the two stream ends; omit them if you want to reroute in pavucontrol.

• The module ID uniquely identifies this loaded instance and is the cleanest way to stop it later.

Adjust volume without creating a howl

1. Start with the output muted or headphones connected.

1. Set the microphone near a moderate level while speaking at real distance; avoid clipping/red meters.

1. Unmute the loopback playback stream at a very low level.

1. Increase slowly while watching for ringing/feedback.

1. If feedback starts, mute immediately; reposition/isolate equipment before trying again.

1. Use pavucontrol’s Recording tab for loopback capture and Playback tab for loopback output.

Stop only the loopback you created

$ pactl unload-module "$module_id"

No output on success.

Do not use pactl exit

• unload-module ID removes the selected loopback instance while leaving the audio server and other applications running.

• If the shell variable is gone, locate the instance with pactl list modules short.

• pactl unload-module module-loopback can remove all instances by name on servers supporting name unloading; an ID is more precise.

• pactl exit asks the PulseAudio-compatible server to terminate and is not the correct stop-loopback command.

Find an existing loopback module

$ pactl list modules short | grep -F module-loopback

536870913  module-loopback  source=... sink=... latency_msec=60

Read arguments before unloading anything

• The first column is the module index/ID used by pactl unload-module.

• Arguments identify source, sink, latency, and policies for each instance.

• Several applications/config files may create legitimate loopbacks; remove only the one you own.

• No output means no matching loaded module in the current audio server/session.

Tune latency without chasing an impossible number

• Lower latency reduces monitoring delay but raises CPU load and the risk of underruns/crackling.

• Higher latency is more stable but can make speech/music monitoring distracting.

• Start around 50–100 ms, then reduce in steps while testing the real devices and workload.

• USB power saving, Bluetooth codecs, sample-rate conversion, CPU scheduling, virtual machines, and different device clocks affect the result.

• For live musical performance, a JACK/PipeWire-native low-latency workflow and suitable audio interface may be more appropriate than a desktop Pulse loopback.

Check for underruns and server load

$ pw-top

S   ID  QUANT  RATE  WAIT  BUSY  W/Q  B/Q  ERR  NAME
...

PipeWire exposes real-time graph behavior

• pw-top shows node timing, quantum, rate, errors/xruns, and busy/wait behavior on PipeWire.

• On PulseAudio-only systems, use journal logs and PulseAudio tools instead.

• Crackles can come from an overambitious latency, CPU pressure, power management, device/driver problems, resampling, or Bluetooth—not simply volume.

• Change one parameter at a time and retest under realistic load.

Optional persistence on PipeWire

pulse.cmd = [
  {
    cmd = "load-module"
    args = "module-loopback source=SOURCE_NAME sink=SINK_NAME latency_msec=60 source_dont_move=true sink_dont_move=true"
    flags = [ "nofail" ]
  }
]

Persist only after the temporary route is proven

• Replace both placeholders with exact symbolic names from your system.

• A user drop-in is preferable to editing vendor configuration under /usr/share.

• nofail avoids preventing the service from starting when a removable device is absent, but verify installed PipeWire syntax/version.

• Restarting user audio services interrupts applications and calls; schedule/test it.

• Automatic microphone monitoring can violate privacy expectations or cause feedback at login—make the behavior visible and easy to disable.

Echo cancellation is not magic feedback suppression

• An echo-cancel module can reduce known playback leaking into a microphone for calls, depending on server/build/method.

• It does not guarantee prevention of high-gain acoustic feedback in a room.

• Noise suppression, automatic gain control, and echo cancellation can color music and add latency.

• For public-address use, use appropriate mixers, microphones, speaker placement, gain structure, feedback control, and hearing-safety practices.

Troubleshooting by symptom

• Failure: Connection refused: run as the logged-in user; inspect systemctl --user status pipewire pipewire-pulse wireplumber or PulseAudio service state.

• No microphone source: choose the correct card profile/port, check hardware mute/privacy permissions, cabling, jack wiring, and USB detection.

• Silence despite module: unmute source/sink/loopback streams, inspect levels, and confirm exact source/sink names.

• You hear desktop audio instead: a .monitor source was selected.

• Severe delay: lower requested latency gradually; avoid Bluetooth if low-latency monitoring is required.

• Crackling: raise latency, check xruns/CPU/power/device rate/driver, and test wired hardware.

• Feedback: mute immediately, use headphones, reduce gain, and separate microphone/speakers.

• Module disappears after reboot: temporary modules are session state; create a reviewed user drop-in only if persistence is truly wanted.

Privacy and accessibility considerations

• A loopback makes microphone audio audible to nearby people; obtain consent and prevent accidental monitoring.

• Show/announce when the microphone route is active and provide a physical/software mute.

• Avoid automatically loading it on shared, classroom, office, or public machines without policy.

• Keep volumes within safe limits and consider latency’s effect on speech fluency.

• For assistive listening, validate intelligibility, delay, reliability, privacy, and appropriate professional equipment.

Clean verification checklist

• Correct physical input reacts in the meter; no .monitor source was chosen accidentally.

• Exact symbolic source and sink are recorded.

• Headphones/low volume and feedback precautions are in place.

• Loopback module ID is saved and appears with expected arguments.

• Latency is stable without xruns under real workload.

• Mute, device disconnect/reconnect, suspend/resume, and output switching behave acceptably.

• pactl unload-module ID stops monitoring without terminating the audio server.

• Any persistent configuration is user-scoped, documented, privacy-safe, and reversible.

Primary references

• PipeWire documents its PulseAudio-compatible modules, including load/list/unload behavior and user drop-ins.

• The PipeWire `module-loopback` reference defines source, sink, latency, channels, remapping, and move-policy options.

• The Ubuntu `pactl(1)` manual documents device listings, module IDs, load/unload, and stream movement.

• The PulseAudio module documentation explains adaptive resampling and why requested loopback latency is not guaranteed.

• Use the installed pactl(1), PipeWire/PulseAudio, WirePlumber, ALSA, and desktop documentation because available devices/options vary by release and hardware.