Using an Android phone as a PC microphone through scrcpy

This case study is about me, at my desk in Singapore, with a desktop PC that has no decent microphone and a spare Android phone that has a good one. The goal was simple: join a video call on Windows and have people hear me through the phone’s mic, using scrcpy and a USB cable instead of a paid app or a second device pairing.

The headline result is that it works, with one catch that trips most people up. scrcpy forwards phone audio to your PC’s speakers. It does not create a microphone device. So the real job is two steps: get the phone’s mic audio into scrcpy, then push scrcpy’s output into a virtual audio cable so Zoom, Teams or Meet sees it as an input. Once that is wired up, the quality is good enough for calls and the delay is small enough that I stopped noticing it, though I did not run a lab benchmark and I will be clear below about what I measured and what I did not.

The question behind scrcpy issue 4208 is, as I read it, the one many people hit: can the phone mic be used as a PC microphone, and why does the audio come out of the speakers instead? The short answer is yes, with a virtual cable, and the rest of this piece is how and where it hurts.

the setup

The stack is deliberately small.

• phone: a spare Android phone I already owned, running Android 13. scrcpy audio forwarding needs Android 11 or newer, so anything older is out.
• cable: a normal USB-C data cable. a charge-only cable is the most common reason adb does not see the device.
• PC: Windows 10 Home, which is what this machine runs.
• scrcpy: a recent 3.x release. audio forwarding arrived in scrcpy 2.0, and the --audio-source=mic option arrived after that, so check scrcpy --version before you debug anything else.
• virtual cable: VB-Audio Virtual Cable from vb-audio.com. it is donationware for the single-cable version as of October 2026, but check their current terms before you rely on that.
• call app: anything that lets you pick an input device. I used Google Meet in Chrome and Zoom.

Cost for me was zero on top of what I owned. If you have to buy a cable, it is a few Singapore dollars. The only paid decision is whether to donate to VB-Audio, which is your call.

The basic command, with USB debugging switched on in the phone’s developer options:

scrcpy --no-video --no-control --audio-source=mic

Each flag earns its place:

• --no-video: skips the screen mirror entirely. no window, less USB traffic, and less for the phone to encode.
• --no-control: stops the PC from sending keyboard and mouse input to the phone. you do not want a stray keypress poking your phone mid-call.
• --audio-source=mic: captures the microphone instead of the default output, which is the phone’s playback audio.

If you leave out --audio-source, scrcpy captures what the phone is playing, which is the original use case. That is why people who just run scrcpy and speak into the phone hear nothing.

The scrcpy project documents all of this in its audio guide. I would read that page once in full, because the flag set changes between releases.

what worked

Four things made the setup reliable.

First, routing through the virtual cable. On Windows, scrcpy plays audio through SDL to the default output device. After installing VB-Cable, I opened Settings, System, Sound, Volume mixer (the app-level device settings), found scrcpy while it was running, and set its output to “CABLE Input”. Then in Meet I chose “CABLE Output” as the microphone. The phone’s mic then shows up in the call as an ordinary input. The catch is that scrcpy has to be running before it appears in the mixer, and Windows remembers the choice afterwards.

Second, picking the right mic source. Android exposes several capture sources, documented in the MediaRecorder.AudioSource reference. Plain mic goes through the phone’s normal processing chain, which usually includes noise suppression and automatic gain. Newer scrcpy releases add variants such as mic-unprocessed, mic-camcorder, mic-voice-recognition and mic-voice-communication. I started with plain mic, then tried mic-voice-communication, which asks for the same tuning the phone uses for calls. Which one sounds best depends on the handset, so I treat it as a thing to test for two minutes rather than a rule. Run scrcpy --help on your version to see which values it accepts.

Third, trimming the latency settings. scrcpy documents --audio-buffer as the buffering delay in milliseconds, where lower values reduce latency but raise the chance of glitches, and its default is 50 ms as of the current docs. There is also --audio-output-buffer, which controls the PC-side output buffer. I tried lowering --audio-buffer in steps and stopped at the point where I first heard a crackle, then went back one step. That is a method, not a number: the right value depends on your USB controller and your CPU load.

Fourth, choosing the codec on purpose. The default is Opus, which is compact and fine for speech. --audio-codec=raw skips the encoder on the phone, which removes encoding delay at the cost of more USB data. Over a USB cable that extra data is not a problem for a single mono or stereo voice stream. For calls I kept Opus most days. When I wanted the lowest delay for a live stream, I switched to raw. flac is lossless but I would not pick it for latency.

There was a smaller win too. Because the phone sits on my desk on a cable, I could put it six inches from my mouth on a stand. A phone mic at that distance sounds better than a cheap headset boom mic, in my own ears, which is a subjective judgement and not a measurement.

what broke

Three problems cost me real time.

nothing in the virtual cable

My first attempt produced silence. The cause was that scrcpy was happily running, but Windows was still sending its audio to my default speakers, so the cable received nothing. The fix was the per-app output setting described above. If you cannot find scrcpy in the volume mixer, make sure it is actually producing sound, because the mixer only lists apps that have an active audio session. Playing something on the phone through --audio-source=output for a moment is a quick way to force it to show up, then restart with the mic source.

the phone’s own apps fighting for the mic

Android lets a limited number of apps capture the mic at once, and behaviour changed across versions. When I had a voice recorder app open on the phone, scrcpy’s capture either failed or went silent. The fix was boring: close other apps that use the microphone, check that the phone is not in a call, and restart scrcpy. If scrcpy exits with an error about audio capture, read the first lines of its console output. It usually states the exact failure, and the project’s issue tracker is searchable by that text.

There is a second cause for silence: the system permission and privacy toggles. Newer Android releases have a global microphone switch in quick settings. If that is off, no tool can capture the mic. Check it before blaming the cable.

drift and crackle on long calls

On a long session I sometimes got occasional crackle, and on one call the audio felt slightly late after an hour. Two things helped. I raised --audio-buffer back up a little, which trades a few milliseconds for stability. And I stopped running other heavy USB traffic on the same hub. Plugging the phone straight into a motherboard port, not a shared hub, removed most of it. I did not isolate this scientifically, so treat it as what worked for me.

If you are also mirroring the screen at the same time, you add video encoding load to the same cable and the same phone. For a microphone-only use case, --no-video removes that variable. If you do want both, I covered how to push the video side into other software in redirecting scrcpy’s video stream into OBS or another app.

the numbers

I will keep this section honest. I did not run an instrumented latency test, so I will not quote a millisecond figure for the whole path. What I can give you are the documented defaults, the costs, and a way to measure it yourself.

• scrcpy audio buffer: 50 ms by default as of the current scrcpy audio documentation, adjustable with --audio-buffer.
• codec: Opus by default, with raw and flac as alternatives.
• extra hardware cost: zero for me, since the phone and cable already existed.
• software cost: scrcpy is open source, and VB-Cable is donationware as of October 2026.
• setup time: about 20 minutes the first time, mostly in the Windows sound settings. About 30 seconds afterwards, since the device choices persist.

The total delay is more than the scrcpy buffer. It adds up from capture on the phone, encoding, USB transfer, decoding, the PC output buffer, the virtual cable, and then your call app’s own processing and network. That is why a single flag cannot get you to zero.

To measure your own setup, record the call app’s local loopback or a screen recording with audio. Clap once near the phone, and compare the clap’s position in the waveform with a clap picked up by a reference mic at the same time. The gap in the waveform is your real delay, and you can then change one flag at a time and re-test. That takes ten minutes and is worth more than any number I could quote.

The relevant quality ceiling is the phone itself. The mic hardware and the phone’s processing chain decide how it sounds. scrcpy does not improve audio, and with Opus at its default bitrate speech is perfectly clear for calls. --audio-bit-rate lets you change it, and for voice I would not bother going much higher.

On the ROI question: this setup is free and reversible. It will not match a proper USB condenser microphone for a podcast. For meetings and casual streaming, it is a good use of hardware that would otherwise sit in a drawer.

lessons

• scrcpy is an audio forwarder, not a microphone driver. you always need a virtual cable, or the equivalent on your OS (PulseAudio or PipeWire sinks on Linux, a loopback driver on macOS), to present the audio to other apps as an input.
• use --no-video --no-control for a microphone-only session. it removes load and removes accidental input.
• test two or three --audio-source values on your own phone. the processing differs between handsets and Android versions, and a two-minute A/B beats guessing.
• tune --audio-buffer downwards until you hear glitches, then back off a step. the stable value is specific to your machine.
• check versions first. flags like the mic sources and extra audio options depend on your scrcpy release, and Android 11 is the floor for audio forwarding. scrcpy --help and the official audio guide beat any blog post, including this one.
• if you hit the same wall as the person in issue 4208, check the output routing first. silence with a healthy scrcpy console is nearly always a routing problem on the PC side, not a capture problem on the phone.

A side note for people who work with adb all day: this is a use of adb that does not involve root or any special access, only standard USB debugging. If you are weighing what needs root and what does not, see root vs non-root Android automation. And if you are new to adb and want the basics of moving files off a phone, how to pull an APK file off an Android device with adb is a good first read. The full list of guides is on the blog index.

Only run this on phones you own or are authorised to use. Capturing the mic of a device that belongs to someone else, without their knowledge, is a privacy problem and may be illegal depending on where you are. This is not legal advice.

would I do it again

Yes, with realistic expectations. For video calls and meetings it is a good solution that costs nothing if you already have a spare phone, and the audio is better than the headset mic it replaced for me. I would not use it for anything where lip-sync or sub-50 ms response matters, such as live music, because the chain has too many stages and I did not verify the end-to-end figure.

The things I would do differently are small. I would install the virtual cable and set the per-app output on day one instead of debugging silence for half an hour. I would write the working command into a .bat file so I am not retyping flags before every call. And I would test two --audio-source values straight away.

If your real need is a more permanent setup, a USB microphone is simpler, since it has no phone, no cable routing, no version drift. The scrcpy route makes sense when you already have the phone, you want a better mic than your PC offers, and you are comfortable with a few flags.

Written by Xavier Fok

disclosure: this article may contain affiliate links. if you buy through them we may earn a commission at no extra cost to you. verdicts are independent of payouts. last reviewed by Xavier Fok on 2026-10-17.