It has to be something with the macOS implementation of moonlight.
#VIPBOX APP FOR MAC TV#
Apple did recently confirm that the currently released versions of iOS continue to broadcast the U1 even if location services are disabled.Ĭonsidering this doesn’t affect moonlight streaming onto the Apple TV or iPhone 11 and Steam in-home streaming works fine in all settings, I don’t think it’s the shield protocol or a macOS networking driver/interface issue. which makes me think the U1 chip doesn’t obeys the iOS airplane mode setting. My memory is vague but I recall replicating this issue in airplane mode. I’ve personally never had the iPhone X/XS trigger this jitter/packet loss just from waking the screen. Perhaps it is yet another variant of this problem. The iPhone X doesn’t have the U1 chip, so I’m stumped. The post above you by suggests it also happens when connected via Ethernet. I mostly just keep my iPhone on the other side of the house or off when playing games and rely on MacOS to notify me of iMessage/FaceTime/Calls. Honestly, I haven’t really followed up on this in a while. The other reason I don’t think it is handoff related is because other iPhone 11’s not affiliated with my Apple ID trigger this jitter/packet loss on my moonlight game stream when in proximity to my laptop. Likewise, this mystery doesn’t affect Steam in-home streaming. I’ll try disabling Handoff/AirDrop but having those features enabled has never been a Moonlight problem for me on past MacOS/iOS/iPhones. [Stream index: you for the insight and sharing the link. User Datagram Protocol, Src Port: 47998, Dst Port: 62455 00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)Ġ. = Differentiated Services Codepoint: Class Selector 7 (56)
When packets get dropped, you hear the audio crackle as it runs out of audio to play and see the video freeze until the congestion passes. When packets are delayed, you see the video run in slow motion. In many ways, you are really seeing and hearing your network's performance. Very short network congestion conditions arise all the time, especially on WiFi with multiple clients and shared airspace, and real-time remote gameplay is about as intolerant of application to an imperfect network as you can find. I'm not even totally convinced this isn't what I'm seeing on my own network.
It takes pretty extraordinary evidence to prove that it's not the network's fault when we can prove that packets are being delayed or dropped before reaching the client. We need to remember that 99.9% of the time these issues really are transient network problems that have nothing to do with Moonlight.
#VIPBOX APP FOR MAC PC#
Moonlight iOS and PC have totally different codebases and I haven't personally seen iOS affected myself.
I'm highly suspicious of jumping to conclusions that iOS may be affected. This is consistent with the stutter observed, because we are getting a bunch of data dropped and the rest delayed significantly. In the trace I recorded, I saw recvfrom() take over 150 ms to return a single packet at one point. This confirms the issue is not our fault and lies with the network or OS network stack. The Moonlight receive thread is not being preempted during that time or anything, since it's able to run and call recvfrom() again when the first call times out. So it really appears that recvfrom() is blocking for over 100 ms without receiving a packet. Thread is waiting for event/lock with id 0xa33ba8a859006e9f. _recvfrom ← (6 other frames)Ġ0:05.386.880 The thread was made runnable by a timer expiration (handled by CPU 0's timer interrupt handler).
0 kommentar(er)
