Why wireless is so slow?

[Lurker00]

I've tried wireless connection (Android device as Wi-Fi access point, 5GHz, Windows laptop as a network client) via "adb connect". Obviously, "adb reverse" does not work, but "adb forward" works.

The result is very slow display update. It even looses frames and events. Why it is so? As I understand, it is TCP which shall not loose any data, and 8Mbps stream shall not be a problem for direct WiFi connection at 5GHz, when devices are side by side. Miracast works just fine.

I've tried wired "adb forward" and didn't notice any performance drop. Also, from the source code I don't see any difference between reverse and forward after the connection has been established.

Any idea on how to improve wireless connection? I don't ask for any action, only for information :)

[rom1v]

Why it is so?

Probably TCP head-of-line blocking. When a packet is lost, the whole stream will wait until it is retransmited.

As I understand, it is TCP which shall not loose any data

In the end, it does not loose data, but to do that it waits for retransmissions. If there are too many packet lost, your bandwidth will be smaller than your video stream.

You should try to reduce the bitrate/definition:

scrcpy -b 2M -m 1024

[Lurker00]

Thank you for your input! I've eliminated "adb forward" from the chain by implementing direct connect from desktop to ServerSocket, disabled SKIP_FRAMES, tuned socket parameters, and my experience over Wi-Fi is much better now. It is the same with 2 or 8M.

[rom1v]

tuned socket parameters

Which ones?

[Lurker00]

setSendBufferSize to 2MB. I also use SocketChannel to write ByteBuffer without additional layers.

I wish I'll find some time to publish the changes one day... So far:

• Works via TCP without manual adb commands.
• Supports multitouch (up to 10 points).
• Switches device's resolution and density, dims device backlight, restores all on stop.
• Autorotates device's screen in sync with my notebook screen orientation.
• Full keyboard support with a help of ADBKeyBoard (enables and activates ADBKeyBoard on start, restores all back on stop). I'm Russian, I need to type Cyrillic...
• "Quit" shortcut :)

[RedAngel86]

Thank you for your input! I've eliminated "adb forward" from the chain by implementing direct connect from desktop to ServerSocket, disabled SKIP_FRAMES, tuned socket parameters, and my experience over Wi-Fi is much better now. It is the same with 2 or 8M.

Hi,
When will your changes be available?
It would be really nice to use scrcpy in wifi quickly.
Thanks

[qlyoung]

@Lurker00 post patch pls

[Lurker00]

Sorry, I was in trouble with this project: I've damaged the computer used for development, and only recently purchased a new one and restored the environment.

Currently I've forked this project, and merged all my changes into the official 1.9 version. It is there. I only have Android 8.1 devices, so I'm not sure that all my changes will work for all. It requires additional app (my dirty build of ADBKeyBoard) to type any language and to sync device's orientation by PC. In general, I'm not sure should I try a pull request... But you may build both projects yourself and give it a try...

The full list of my changes (sorry for misuse this thread!):
User visible changes:

• 10-fingers multitouch support.
• Any charset input support with an aid of ADBKeyBoard.
• Quit command (Ctrl-Q)
• Ctrl-Shift-O turns device screen on.
• Connection timeout detector from the device side (useful with connection over wireless network).
• Screen density and screen size can be set on the device during the session.
• "Tablet mode": dim device screen, synchronize device screen orientation with PC (requires additional service on the device).

Internals:

• The server "forks" itself for full life cycle control (adb may kill it instead preventing required cleanup).
• Full cleanup at exit.
• Expandable parameters to the server applet, allowing compatibility between versions.
• Java NIO to simplify network I/O and not be limited to Unix sockets.
• Different connection type: direct connect to the device instead of "adb forward".
• Commands: actions with no parameters

[rom1v]

@Lurker00 I created a specific thread for it: #679

[opulos]

For what it's worth, the following command line arguments seem to help with performance over WiFi:

scrcpy.exe -b 1M --display-buffer=200 -m 960

The 200 millisecond buffer delay along with decreasing the display dimension from 1920 to 960 using the -m 960 option seem to help a lot.