Scream: Server's (sub)system hangs 3 sec for every packet if unicast destination in LAN is unreachable.

[ReeseWang]

I've set up a dev-test environment and want to solve the issue by myself, I just need some directions as I'm not familiar with Windows Driver development.

I found that if the unicast address is set to a nonexistent IP in the same LAN as the server, CSaveData::SendData will hang for 3 seconds before sending the next packet. The result is that everything related to sound (Sound Settings, Volume Control, etc) is inhibited from launching. Captured packets show that the system tries to find the host that has the IP through ARP every time it wants to send a UDP packet and gives up after 3 seconds.

How can I make Scream stop sending UDP packets if unicast address' ARP resolution fails?

[duncanthrax]

Interesting question. I just checked the WSK API for ARP related functions, and there's nothing. One guy with a similar problem here: https://social.msdn.microsoft.com/Forums/en-US/0b9d19a7-d196-40d2-a26e-e1f6c5ac4404/sendarp-timeout?forum=wsk

Why the sound subsystem acts up while the sending worker waits for the ARP reply is another question. There's probably a lock being held.

Fixing this problem in kernel space might be hard. If you can live with a userspace solution, add a matching ARP entry from a userspace program.