When Video, Audio, and Recording Pull in Different Directions
Audio makes scrcpy's bridge more demanding because sound is not simply another kind of video frame. Audio has different Android capture permissions, a separate clock, its own encoder and buffers, and applications that may refuse to be captured. Recording adds a second complication: it can consume the encoded streams without displaying or playing them. This chapter uses those differences to show when audio should degrade gracefully, when buffering is worth the delay, and why scrcpy's own recording path is not the same as recording a desktop window and its speakers.
Audio is a capability matrix, not a checkbox
The default audio source is the device's output. scrcpy can also capture the microphone, and newer Android releases offer a playback-capture source with different behavior. These choices answer different questions. Output capture asks what the device is playing as a whole. Microphone capture asks what the device's input hardware hears. Playback capture asks what eligible applications expose through Android's audio policy. Treating them as interchangeable hides the Android capability that each one depends on.
The Android release is the first boundary. Audio forwarding is supported from Android 11 onward; on Android 10 and earlier it is disabled automatically because the required capture path is not available. Android 12 and newer support the default path more directly. Android 11 is a special case: the device must be unlocked when scrcpy starts. The server is a Java process launched from the shell rather than a normal foreground application, while Android 11 checks foreground status for audio recording. scrcpy briefly starts a shell activity so the system will treat the shell identity as foreground, retries the recording start, and then stops that workaround.
This is a good example of a feature whose visible simplicity conceals a platform contract. A person can have working ADB and video on Android 11 and still see audio fail because the screen was locked at the moment capture began. The failure does not imply that the video bridge is broken. Conversely, unlocking the device cannot make audio capture available on an older Android release. The same scrcpy command crosses different system boundaries depending on the device version.
The default output source also has a side effect: the documentation describes it as forwarding the whole audio output and disabling playback on the Android device. That may be desirable when the computer should be the only place the sound is heard, but it is not desirable for someone who wants both local and host playback. On Android 13 and newer, scrcpy can use playback capture and request duplication so the sound continues on the device. This path depends on Android's audio-policy interfaces, and individual applications can opt out of playback capture. “Audio available” therefore still does not mean “every app's sound is guaranteed to arrive.”
Microphone capture changes the use case again. With video disabled, the device can function as a source for a recording on the computer, such as a simple dictation or field-audio workflow. The source is then the microphone rather than the Android output, and the relevant limits are the selected source, device hardware, and the selected audio encoder.