MICROPHONE PASSTHROUGH
Use your local microphone inside the remote Linux session
Noland can capture a microphone selected on your client computer, send Opus audio through the managed connection, and expose it to remote applications as Noland Microphone.
QUICK ANSWER
What you need to know
Microphone passthrough runs alongside the Moonlight stream. A managed local sender captures the selected input, forwards RTP/Opus audio over ports authorized for the WireGuard peer, and a supervised receiver feeds a persistent PipeWire source on the cloud host.
CAPTURE
Select the operating-system default or a specific input
The same managed sidecar that captures audio also enumerates available microphone devices. You can follow the operating-system default or select a specific device ID, then persist forwarding, auto-connect, device, and quality preferences per cloud instance.
On Windows and Linux the sender captures through CPAL; on macOS it uses the managed GStreamer CoreAudio path and requests the system microphone permission. Capture enters a bounded stale-dropping queue so old audio does not grow into an unbounded delay when the downstream path is under pressure.
- Default-device and explicit-device selection
- Per-instance forwarding and auto-connect preferences
- Bounded audio buffering that favors current speech
- Mute, unmute, reconnect, and device recreation controls
TRANSPORT
Keep microphone transport separate from video streaming state
When a Moonlight session starts, Noland resolves the corresponding instance and schedules microphone startup independently. It authorizes a short-lived host endpoint over SSH, allocates RTP and RTCP ports, and restricts access to the WireGuard peer before starting the sender and receiver.
The microphone service is supervised separately from Sunshine and Moonlight. Noland can report WireGuard reachability, local capture, queue health, packet loss, jitter, and remote PipeWire status independently, which makes failures more actionable than treating all audio problems as a single stream error.
- RTP/RTCP transport with Opus audio
- Short-lived host authorization for the active peer
- Three-second sender supervision and bounded restart behavior
- Independent health metrics for each stage of the path
REMOTE DEVICE
Present one stable microphone to remote applications
The receiver decodes the audio into a persistent PipeWire topology named Noland Microphone. Keeping the remote source stable lets applications continue targeting the same device while the client-side sender connects, disconnects, or is restarted.
Microphone forwarding still depends on client permissions, local device drivers, network quality, WireGuard connectivity, and remote PipeWire health. It is designed for interactive voice use, but Noland does not promise studio recording quality or zero packet loss on every route.
FAQ
Questions about microphone passthrough
01Does microphone passthrough use Moonlight's audio channel?
No. It is coordinated with the stream lifecycle but uses a separate managed RTP/Opus path and a remote PipeWire source.
02Can I choose a specific microphone?
Yes. Noland can follow the operating-system default input or persist a specific device exposed by the managed microphone sender.
03What appears inside the remote session?
Remote applications see a persistent PipeWire source called Noland Microphone. The sender and receiver can stop while the remote device topology remains available.
04Does microphone forwarding start automatically?
It can. Auto-connect is stored per instance and microphone startup is scheduled when the corresponding Moonlight session starts. Permission, device, network, or remote audio failures can still prevent activation.
