Repository navigation
"robotic" and glitchy sound #3793
Description
Environment
- OS: Windows 10 Professional x64
- scrcpy version: 2.0
- installation method: Windows release
- device model: Realme GT 5G
- Android version: 12
Describe the bug
I've tried changing audio buffer to higher values (video buffering too), have also changed audio bitrate and so on, but it always come out as a "robotic" sound with many "clicks" and "impurities" as well (I'm trying my best to describe it, bear with me, please). So, when I decided I was going to place an issue about this, of course I recorded a minuscule sample video to showcase it. I was displeasedly surprised after playing it with perfect sound, not "robotic" or glitchy at all, just smooth audio playback. That's why I didn't consider uploading that sample.
So, I've hunted my Windows audio config to see if anything was causing this strange behavior. I've let go of the thought after many tweaks with no positive (or negative) changes.
Have you or anybody else gone through this before?
EDIT by @rom1v: Run scrcpy --audio-output-buffer=10.
EDIT 2: the default value is 10ms since #6775.
Activity
rom1v commentedon Mar 12, 2023
So the problem only occurs in real-time playback, but not recording via
scrcpy --record.Please run
scrcpy -Vverboseand post the output when the sound is "robotic".BillVGN commentedon Mar 12, 2023
Here it is:
rom1v commentedon Mar 12, 2023
Wow, that's weird :/
Here is a build with this diff:
scrcpy.exeSHA-256: c4f164bde115dd5838f556c7d7224a776eaff8d087755f43e65cc48ea8b99820Please retry
scrcpy -Vverbosewith this binary (replaced in your v2.0 release folder).BillVGN commentedon Mar 12, 2023
new binary output:
rom1v commentedon Mar 12, 2023
The audio callback is not called frequently enough by SDL to consume the samples.
Let's try with a bigger audio output buffer:
scrcpy.exeSHA-256: fa907e4529fcab80f316f21462a28548578bc912230171e88bd740ad4a25fc5bBillVGN commentedon Mar 12, 2023
Wow! That did the trick!
No more robotic sound. Simply pure and smooth audio as should be.
Are you releasing it as a hotfix or new version? Looking forward to it.
Thanks a lot, man!
rom1v commentedon Mar 12, 2023
I think I will keep 5ms by default, but add an option (e.g.
--audio-output-buffer=10) to adjust it when necessary.rom1v commentedon Mar 12, 2023
I submitted an issue on SDL to get more feedback about the problem: libsdl-org/SDL#7450
rom1v commentedon Mar 12, 2023
Could please you try the official release with a different audio driver: #3799
BillVGN commentedon Mar 12, 2023
Directsound sounded as robotic as before (no pun intended)
WinMM was even worse...
As per wiki SDL v2.0 is being used, right? So it does not make sense trying other drivers for v1.2, I guess...
Edit: I don't know if I messed anything up, but I tried that binary you offered me before and now it is robotic as well, but a tiny bit less...
tordenflesk commentedon Mar 13, 2023
set SDL_AUDIODRIVER=directsound and adding --audio-buffer=200 to my command line fixed it for me.
Add --audio-output-buffer
rom1v commentedon Mar 13, 2023
On a branch, I implemented an option
--audio-output-buffer.Please restore the original
scrcpy-serverin the v2.0 release. Confirm that you get a robotic sound.Then replace this binary:
scrcpy.exeSHA-256: ba21fc3966aec8423ff51baf96e7fe046b4310c3cd3b2d5525db128014cc468cConfirm that you still get a robotic sound.
Then execute
scrcpy --audio-output-buffer=10, and confirm that it works as expected.Thank you
tordenflesk commentedon Mar 13, 2023
Yes, works.
Add --audio-output-buffer
Add --audio-output-buffer
Add --audio-output-buffer
rom1v commentedon Mar 14, 2023
I merged this new option
--audio-output-bufferintodev: 39544f3oxota74 commentedon Jan 15, 2026
Thanks! Added this for wireless:
--audio-buffer=150I'm still tuning it up, but there are much fewer brakes, creaks, and over-pitched sounds, and there are almost none.
I didn't add this
audio-output-bufferand everything is fine without it.Mikachu commentedon Mar 19, 2026
This is unlikely to help many people, but running scrcpy with schedtool -I (sched_iso, which is only available in the -ck patchset, which was itself discontinued after 5.12), I can lower --audio-buffer to 2 milliseconds without any underruns on my almost 20 year old core2duo cpu even under heavy load. Hopefully one day mainline schedulers will be less crap too :).
Set default audio-output-buffer to 10ms
Set default audio-output-buffer to 10ms