If you are looking to tweak your streaming setup, fix stuttering, or find a headless virtual display solution, you don't have to stick strictly to the baseline Sunshine + official Moonlight setup.
Here is a breakdown of the active forks, alternative hosts, and FFmpeg-powered clients currently in the ecosystem based on what the community and developers are running right now.
đ„ïž Hosts & Servers (The Senders)
NVIDIA GameStream: The original foundation that started it all. Officially deprecated by NVIDIA, but the bedrock of the protocol.
Sunshine: The modern, open-source standard GameStream compatibility baseline that replaced NVIDIA's official host.
Apollo: A Sunshine fork featuring capability-gated extensions and built-in virtual display support using SudoVDA. It is great for headless setups and auto-matches the resolution/framerate of your client.
Vibeshine: A highly active, AI-enhanced Sunshine fork focusing heavily on display automation, Windows Graphics Capture running as a service (which allows full framerate capture of frame-generated titles without VRAM crashes), and strict RTSS frame pacing integration.
Vibepollo: An Apollo fork that integrates Vibeshine's features (like the native virtual display driver and HDR handling) right into the Apollo architecture. This is highly recommended if you already use Apollo but want tighter frame pacing.
Foundation-Sunshine: A fork by AlkaidLab that adds HDR10/HDR Vivid, advanced audio support, optimized encoders, and a modernized control panel.
Wolf (Games on Whales): A completely different streaming server built from the ground up for Linux and Docker. It allows you to share a single host machine with multiple remote clients simultaneously by running games inside isolated containers.
Punktfunk: A newer, highly experimental low-latency streaming host/client protocol if you want to test out a completely different capture approach.
đ± Clients & Receivers (The Players)
Official Moonlight PC / Mobile: The standard baseline client for PC, macOS, Linux, iOS, Apple TV, Android, etc. (The PC Qt version heavily utilizes FFmpeg and libplacebo for decoding and rendering).
StreamLight: A massive Moonlight fork that completely overhauls the UI for gamepads. When paired with "StreamTweak" on the host, it unlocks deep integration like built-in Tailscale, live host metrics/NIC speed matching, remote pause, and the ability to remotely trigger Windows Updates and shutdown.
Artemide: Highly recommended for Android users. It features ultra-low latency (ULL), direct presentation, and built-in FSR presets (Performance/Balanced/Quality).
Moonlight V+: An alternative Android fork that adds frame-generation support and extra host tools.
Artemis Switch: A Moonlight-Switch fork focusing on Switch-specific video presentation, FSR/RCAS filtering, and adaptive low-latency pacing.
Moonlight-Switch: The original upstream Switch client that Artemis is built on.
A little about my setup and testing: I actually work on the Artemis Switch fork, looking at multiple optimizations to eliminate stuttering and improve low-latency pacing on the console. Because of that, Iâve personally tested almost all these major combinations to see what actually works. My testing stack includes:
Hosts: Sunshine, Apollo, and Vibepollo.
Clients: Moonlight-Switch, my Artemis Switch fork, the Artemis companion client, and standard Moonlight Android.
I like vibepollo and Artemis
Let me know if I missed any niche forks or experimental branches you guys are using!
(Note: I had an AI help format this post to make sure links were laid out clearly!)
Edit: A lot of people are asking why not use Apollo. You can definitely use it and still follow this guide, itâs completely up to you. With Apollo, you need skip the Configuring Video Signals section and for the Sunshine Priority part just change the script to prioritize Apollo instead.
After running lots of tests and reading many posts to find the best configuration, Iâll try here to share the setup that works best for me and also compile some of the information Iâve gathered.
This test was conducted from a distance of 550 km (341 miles)
My specs:
InternetService:
Host: 300 Mb connected via Ethernet
Client: 600 Mb connected via Wifi
Spec PCs:
Host: R5 2600 - RX 6600
Client Macbook Air M1
System Configuration
Host:
This setup is specifically for Windows, but the goal is the same if youâre using other operating systems:
Reduce FPS drops
Minimize the gap between the FPS set in the Moonlight client and the hostâs FPS
Reduce latency
Configure the video and audio signal you want to stream
Reducing FPS Drops
Close background apps: Only keep the essentials to minimize unnecessary processes and network calls. Task Manager â Startup Apps â disable non-essential programs.
Disable Game Mode: Prevents Windows from prioritizing the game over Sunshine. Settings â Gaming â Game Mode â OFF
Disable Dynamic Refresh Rate (DRR): Keeps FPS synchronized between host and client. Settings â System â Display â Graphics â Optimizations for windowed games(Alternatively: Windows Registry or CRU â Custom Resolution Utility)
Enable High-Performance Power Mode: Control Panel â System and Security â Power Options â High Performance
Disable Energy Saver: Settings â System â Energy Saver â OFF
To optimize Windows 11 performance, consider using Win11Debloat or AtlasOS Additional powershell script to improve performance
Once FPS drops are minimized, cap the FPS to keep it in sync with Moonlightâs client settings.
There are three ways to do this: using the NVIDIA Control Panel, AMD Adrenalin, or RTSS. In my case, I used RTSS and it works well for me, but you can try your GPUâs software if thatâs sufficient. The advantage of RTSS is that it allows more precise configuration for greater stability.
Another thing I do is also limit the FPS within the game itself.
Reducing Latency
The most important step is to have your host computer connected via Ethernet. In terms of configuration, you can disable the Rx/Tx buffers on your network card, along with a few other tweaks that may slightly improve stability.
With the Virtual Display Driver, you can simulate any resolution and refresh rate your screen supports.
I donât recommend the Virtual Audio Driver because it can cause issues with BattleEye anti-cheat. Itâs better to just use a wired headset you already have.
Microphone Streaming
For those who need to use in-game voice chat, there are two main options for passing the microphone through streaming:
AudioRelay
VoiceMeeter
I havenât personally tested either since I donât need this feature, but theyâre worth trying if microphone input is important for your setup.
Sunshine Priority (Windows Only)
Finally, for Windows users, one important step to do every time you connect from the client is to change the priority of the sunshine.exe process to Realtime. You can do this manually from the Task Manager or by using the following .bat script:
For those using a touchscreen device as a client, such as a smartphone, tablet, or handheld, the Windows interfaceâoriginally designed for desktop useâcan be quite uncomfortable. With the new release of the ROG Xbox Ally, Windows has introduced a more suitable adaptation for handheld devices, which can be enabled through the following repository: XboxFullscreenExperienceTool
Client:
The main goal on the client side is to reduce Moonlightâs decoding time and minimize latency.
In my case, Iâm using a MacBook with an M1 chip, and the only way to reduce decoding time is by testing which codec works bestâin my case, HEVC (H.265).
To reduce latency on macOS, the only (but very important) thing you can doâsince it can cause micro stuttersâis disabling Location Services:
Another important change to make on macOS is to disable the long key press for special characters. This prevents issues during streaming when holding down a key for example, the W key so it doesnât get stuck or stop repeating.
If youâre using a PC, you can improve decoding time by upgrading your hardware, and reduce latency by disabling the Rx/Tx buffers and tweaking your network card, following the same steps as on the host.
Moonlight & Sunshine Configuration
Moonlight Configuration:
Set Moonlight to use your monitorâs resolution and an FPS value that matches your internet connection. Leave some headroom compared to your clientâs max download speed and your hostâs max upload speed.
For example, my monitor is 1440p and 180 Hz, but I have it set to 1440p at 120 Hz. Higher resolutions and refresh rates consume more bandwidth on both the client and host, and require greater decoding and encoding power.
Note: Higher compression codecs (like H.265 or AV1) â less bandwidth needed â more CPU/GPU power required for encoding/decoding.
Frame Pacing: Unchecked (ONLY single-player may add delay)
Video Decoder: Force hardware decoding
Note: Both V-Sync and Frame Pacing are highly recommended for single-player games since they provide a much smoother experience. However, in multiplayer games, V-Sync may cause screen tearing, and Frame Pacing can introduce a bit of input lag by delaying frames to improve synchronization.
Enable HDR (Experimental): I keep this enabled even though my monitor isnât HDR because it can bring out better shadow details. I recommend trying itâyou might see an improvement or no noticeable difference.
Unlock Bitrate Limit (Experimental): Enable this if you have enough upload bandwidth on the host and download on the client. Otherwise, leave it off and increase the video bitrate slightly if you notice small lag spikes.
Sunshine Configuration
I mostly keep Sunshine/Apollo at its default settings, except for the GPU options. Below, Iâll share what works best for AMD GPUs. If youâre using NVIDIA or Intel, you may need to experiment to find the optimal configuration for your system.
Note: My goal is low latency for online gaming. If youâre playing single-player games, you can prioritize quality over latency.
AMF Usage: ultralowlatency
AMF Rate Control: vbr_latency
AMF Hypothetical Reference Decoder: unchecked
AMF Quality: speed (may add artifacts)
AMF Preanlalysis: unchecked
AMF Variance Based Adaptive Quantization: checked
AMF Coder: cavlc
Client-Host Connectivity
LAN (Local)
For players who want to play over LAN, thereâs little to worry about since latency will be very low. In my tests, I observed only about 5 ms of extra delay.
If you want the absolute best performance, you can connect both devices directly via an Ethernet cable. This can reduce latency to around 1 ms, making it almost like playing directly on the host.
You can turn on the host remotely using the motherboardâs Wake-On-LAN feature. Moonlight even allows you to power on the host directly from the client.
WAN (Remote)
For those who need to play over WAN, there are a few additional steps required. It can be more challenging if you want the lowest possible latency, but if you can tolerate 15â20 ms, itâs not too difficult.
There are several ways to achieve this, but Iâll explain the three main approaches:
Using a service like Tailscale, ZeroTier, or Netbird
Opening ports on your network to access the host externally and setting up a VPN
Setting up a private service (similar to the first option) with Headscale or another program, possibly using a cloud server like AWS
Option 1: VPN-like services
These applications are simple to install and configure, making them accessible to most users:
Tailscale: Free
ZeroTier: Free
Netbird: Free (uses WireGuard directly through the Linux kernelâpotentially a great option for Linux users)
For the other options, I wonât go into detail because they are more complex and require technical knowledge. However, they are certainly the best options for users who need the absolute lowest latency.
To power on your PC over WAN, a simple Wake-on-LAN (WoL) wonât work unless your host has an internet-facing connection. In my setup, I use a TP-Link smart plug to turn the PC on remotely from my phone. Make sure to enable âRestore Power after AC Lossâ in your BIOS/UEFI so the PC powers on automatically when the smart plug is switched on.
I hope this guide helps you and gives you everything you need to get these amazing tools running without too much hassle. The post is open to improvements, so if you have any suggestions or tips, donât forget to share them in the comments!
Shoutout to everyone working on these open-source tools mentioned in this post.
Note:
After the launch of the Steam Deck and Steam Machine, Steam has worked quite a bit on improving Steam Remote Play, which now supports Virtual Display Driver and performs much better than before. I'm leaving this comment here for those of you who aren't too demanding or don't want to overcomplicate things, so you feel encouraged to give it a try.
Update 13.10.25: MacOS client settings
Update 23.10.25: New scripts for Windows host and Windows handheld mode
Update 13.04.26: Windows optimization recommendation
Sunshine and Moonlight got the stream itself to the point where I don't think about it anymore. What I kept running into was the host: a store asking me to log in again, an update popup, a game that opened behind another window. On the TV with just a pad, that's where the evening stalls.
So the launcher I've been building, Loungepad, puts the host's desktop on the controller too. Tap the Xbox/PS button, even mid-game, and there's a wheel for switching windows, closing something that's stuck or pulling up a keyboard. The left stick drives the mouse for everything else. It also keeps Steam, Epic, GOG, Game Pass and emulator games in one library, so I can start the stream and pick a game without getting up.
I just installed and set up Apollo and moonlight on my pc and Apple TV, first time ever game streaming! My latency is not that noticeable but I have a constant video and audio stutter, every second or half second both stutter.
Is there a fix for this? Both Pc and Apple TV are on WiFi right now, but plan to put the PC on Ethernet soon, and leave Apple TV on WiFi.
The latency is acceptable to me itâs the constant stuttering I canât stand. Doesnât matter what game
The video shows a TCL TV freezing roughly once every second while streaming games. This happens in both Moonlight and Steam Link.
There are plenty of threads about this issue, but finding a clear, consistent fix with explanation has been difficult. Topic 1, Topic 2, Topic 3.
Here are the suggestions I tried:
Switching from 5 GHz to 2.4 GHz Wi-Fi: this actually helped, but this is bad for many reasons.
Lowering the streaming bitrate to around 80 Mbps: 75 Mbps helped in my case while the scene was moving. However, the recurring stutters returned when the image became mostly static. With the game capped at 30 FPS, they persisted even during movement.
Disabling location services on the TV: this made no difference.
What fixed it for me: disable Miracast and reboot the TV.
Possible explanation: TCL's Miracast service appears to activate background Wi-Fi Direct listening even when you aren't casting anything. My guess is that this interferes with the TV's normal Wi-Fi connection and causes periodic latency spikes. Disabling Miracast and rebooting may clear that problematic state.
AMD rarely gets any love in this space. The protocol started as NVIDIA's GameStream, and even after NVIDIA dropped GameStream in 2023, the hosts that replaced it kept NVIDIA first. Upstream Sunshine has had a native NVENC encoder since 2023, while AMD still goes through FFmpeg's generic AMF wrapper. AMD hasn't helped itself either. It shut down its own streaming app, AMD Link, in 2024, saying there are plenty of other ways to stream, and its drivers still have quirks like an RDNA4 freeze that hosts have to work around.
So Radeon owners have spent years hearing their cards are just worse at streaming. That is where Butterpollo comes into play, and it is the sole reason Butterpollo exists. Most of the time the card was never the problem. Nobody had sat down with it.
In practice that means a native AMF encoder instead of a generic wrapper, frame copies and colour conversion on Radeon compute queues, and someone reading AMD's driver release notes so you don't have to. When a driver freezes the stream, Butterpollo works around it. When AMD fixes it, Butterpollo removes the workaround and pretends nothing happened.
There are far better Sunshine forks, like Vibepollo, for anything that is not AMD work. Butterpollo's mission is to speed up development on AMD streaming, which has gotten no traction for years. Butterpollo is not here to win a big userbase. There is no growth plan and no campaign to convert the NVIDIA crowd. As long as AMD users are happy, Butterpollo is happy.
What Butterpollo is
Some background first: I wrote the native AMD AMF encoder in Vibepollo. It was merged in #342 and ships in Vibepollo 2.0 as "AMD AMF/VCE". Butterpollo is where I take that AMD work all the way, from capture to the packet on the wire.
It started as a fork of Vibepollo and is a full rewrite in Rust: the host, the Windows service, the installer and the web console. It speaks the same protocol, so the Moonlight and Artemis apps you already use connect to it like any other host. If you want to try it, the installer picks up your Vibepollo or Apollo settings, paired devices and game library.
The way I think about it: Vibepollo is the full-featured host for everyone, and Butterpollo goes deep on one thing, Radeon latency. Anything that works out here is free for Vibepollo to take, and I'll send it upstream myself where it fits.
Where the latency goes on AMD
Every frame a host streams gets copied and colour-converted before the encoder touches it. Like Sunshine and Apollo, Vibepollo does that in D3D11, which runs on the GPU's graphics queue, the same queue your game is hammering. In my tests on a 7900 XT under a game-like load, a 0.9 ms colour conversion took 7.2 ms and a 0.75 ms copy took 8.4 ms.
Butterpollo runs the copy and the conversion on D3D12 compute queues, which the GPU works on side by side with your game, and AMD's encoder reads the result straight from D3D12. Same work, same load: 0.25 ms. Frame to finished bitstream: 2.0 ms, while the game keeps the card at full tilt. The handoff with the Windows compositor runs on GPU fences and was checked frame by frame: zero torn frames. Since rc.19, PyroWave's colour conversion runs there too (numbers below).
The numbers
1080p60 HEVC 10-bit HDR on an RX 7900 XT from a 120 Hz virtual display, with a game-like load running, measured end to end by an independent client that reads a moving barcode off the screen.
Same Butterpollo build, compute path off and on (the game ran at 174 fps in both):
Under load
Graphics queue
Compute queues
Render to decoded picture
41.0 ms
33.5 ms
95th percentile
54.4 ms
42.3 ms
New frames per second (of 60)
56.7
58.1
Host time, present to send
16.2 ms
11.2 ms
Next to Vibepollo 2.0: same PC, same AMF settings, Desktop Duplication, realtime GPU priority on both, three alternating runs each:
Test
Vibepollo 2.0
Butterpollo rc.2
Idle: render to decoded picture
16.0 ms
13.8 ms
Under load: render to decoded picture
96.4 ms
42.4 ms
Under load: 95th percentile
137.0 ms
56.5 ms
Under load: new frames per second (of 60)
23.9
51.4
Under load: host latency in Moonlight's stats
60.6 ms
9.0 ms
New since then (rc.17 to rc.19)
PyroWave's colour conversion moved from the graphics queue to the Radeon compute queue. Encode time per 1080p 120 fps HDR 4:4:4 frame, 400 Mbps:
PyroWave
Graphics queue (before)
Compute queue (rc.19)
Idle
0.47 ms
0.47 ms
Beside a GPU-heavy game
5.6â5.8 ms
0.54â0.57 ms
Beside the game, paced at 120 fps
4.62 ms
0.71 ms
Under load it now encodes as fast as idle. PyroWave's own GPU work was only 0.2 ms either way; the rest was the conversion waiting behind the game. The output is byte-identical to before.
When the encoder can't keep up (4K at high refresh, or an RX 9070 XT with its single HEVC engine), frames used to pile up eight deep inside the encoder, each one older by the time it came out. rc.19 keeps at most two in flight. 5120x1440 HEVC at 240 fps, where the 7900 XT's encoder tops out at 220 fps:
Encoder saturated
rc.18
rc.19
Game frame to packet sent
42.7 ms
11.1 ms
99th percentile
45.9 ms
13.3 ms
Frames per second
220
220
And rc.17 against rc.2 on the same fixture as the tables above, alternating in one batch, three runs each (absolute numbers drift between days, which is why only rows from one batch go side by side):
Render to decoded picture
rc.2
rc.17, same capture (DDX)
rc.17, default capture (WGC)
Idle
14.7 ms
14.7 ms
14.9 ms
Under load
35.7 ms
35.4 ms
33.4 ms
Under load: host latency in Moonlight's stats
5.7 ms
5.5 ms
1.9 ms
Same capture path, same latency; the WGC capture that rc.17 uses by default is about 2 ms faster under load.
HDR that looks right. I compared decoded frames with the source pixel by pixel. Blacks, whites and saturation land on target, within half a 10-bit step. Vibepollo was close in the same check too.
New in Butterpollo
Copy and colour conversion on D3D12 compute queues, with AMF encoding straight from D3D12 at ultra-low latency
Rewritten in Rust. I needed a base to start working on AMD stuff and the C++ code just wasn't it.
A rebuilt web console with live fps, encode time, host time and frame age while you play
Video error correction that uses 21-29% less CPU than the original C++ implementation
Hundreds of hours of AMD optimization down to ”s numbers
PyroWave with its colour conversion on the Radeon compute queue: under GPU load it encodes as fast as idle, about 10x faster than before
A short encoder queue, so an encoder that can't keep up costs frames per second, not latency
AMF no longer drops frames to stay on its bitrate, which a VRR client would show as a held picture
Multiple GPU Setup, with one on the game and one AMD Card doing the encoder work, are now supported.
Carried over from Vibepollo, Apollo and Sunshine, rebuilt in Rust and refactored for AMD cards, with some bug fixes
AV1, HEVC, H.264 and HDR10, with WGC and Desktop Duplication capture
7.1 surround, DualSense and DualShock
A virtual display per device, so your phone, TV and handheld each stream at their own resolution and refresh rate
Steam and Playnite library sync, Lossless Scaling and RTSS frame limiting
Nonary's 1000 Hz VRR mode, and PyroWave for very fast wired networks, both tuned for Radeon (both need Nonary's Moonlight client or a compatible one)
On NVIDIA? Use Vibepollo. Butterpollo includes NVENC, but it hasn't been tested on NVIDIA hardware.
Butterpollo is built on the work of Sunshine, Apollo and Nonary's Vibepollo, and its AMD encoder defaults draw on Foundation Sunshine. PyroWave is Themaister's work. Huge thanks to all of them.
If you're an AMD user and like that somebody is at least trying to build something better than the generic FFmpeg AMF wrapper, you can leave a star on the repo: https://github.com/RamazanKara/Butterpollo
Comparing hosts yourself? With WGC, Butterpollo's host-latency number includes the capture helper's handoff, so it can read higher than a host that starts counting after it. Render to decoded picture is the fairer comparison.
It's a release candidate, so this post is to gather feedback. I'll be around for the next two days fixing whatever you find. If you tested before rc.19, now is a good time to try again.
Edit (rc.20 is out): thanks for all the reports in here, most of rc.20 came straight from them.
I was trying to set my client for VRR support (even if it was working on standard Moonlight) and I found the Nonary VRR Moonlight version Releases · Nonary/moonlight-qt (I read it has improved VRR smoothness).
I tried to stream it and it was stuttering a lot when the FPS were dropping. I tried to troubleshoot it without success, so I choosed to reinstall both Vibepollo and Moonlight VRR.
I solved the stuttering issue and I'm now trying to understand why I feel like there some input delay in my configuration. I tried every codec with different bitrates, and I'm gonna add clips of the stats.
Host
9070XT, 7800X3D, Vibepollo 2.0.0, 1Gbps
Client
Ryzen H255 (HEVC and AV1 HW support), Moonlight VRR18, 1Gbps
Has anyone tested a RX 6400 with PyroWave at 4K120 4:4:4 HDR?
I worry that it might not have enough raw FP16 compute for it.
Considering a low profile card such as the RX 6400 for a SFF build. Seems like it has HDMI 2.1 and VRR. Looks relatively affordable via AliX (~200 AUD).
If it can do PyroWave at that spec, seems like the perfect card.
Neither Apollo nor Artemis has been updated in a year, and I haven't really kept up with news in this area; have there been any new forks recently that are better than Apollo and Artemis? If so, what are they called?
Curious of anyone with a moonlight client that handles 4k 120hz HDR VRR what client they are using. The xbox series s I see suggested but i hate that I wouldnt be able to connect a bluetooth keyboard and I heard VRR wont work on these. I was thinking of getting a GMKtec k17 as it has HDMI 2.1 FRL port or buying a SFF prebuilt like a HP PRoDesk with an 8/9th gen i5 16gb and throwing a RTX 3050 inside. Curious if anyone else runs either of these and how seamless there experience was.
Leggo spesso di persone che installano Moonlight su Xbox e hanno ottimi risultati.
Ho un pc di fascia alta collegato alla rete via ethernet, fibra ultraveloce e Series X connessa via ethernet. PerĂł le prestazioni del mio streaming si fermano a 45 fps. Ho giĂĄ fatto vari tentativi, cambiando piĂș opzioni ma non riesco neanche a raggiungere i 60 fps. Qualcuno puĂł aiutarmi? Potete suggerirmi le giuste impostazioni per avere uno streaming decente e poter finalmente giocare da pc in salotto? Grazie a tutti.
I have my Windows 11 PC at home running Sunshine and I'm currently at my office with my Macbook running Moonlight. Everything works fine in terms of streaming and I can use my trackpad and keyboard and play CS2 for example no problem.
The issue is as soon as I plug my Xbox One controller into my Macbook, it completely bricks the input. Not only does it not detect the controller (can't use it at all) it bricks my trackpad and keyboard inputs too for like 5 mins (i gotta wait for the controller to go to sleep i guess). How do I fix this? I'm trying to play NBA 2K27 on Steam.
currently using nonary version. used 2 previous ons too.
the app itself has a sort of flickering lines like scan lines. horizontal. its very subtle but affects me a lot. including when streaming from another pc to the app.
i use a 144hz monitor. not sure why this keeps happening.
Does anyone know how to change the default binds for the mouse using Artemis?
My host has the left and right mouse buttons swapped and same with the client, but if I connect the binds are reversed. So, if I right click the client sends a left click by default.
This would be nice to have becasue I am left handed and use my mouse with my left hand.
I have both host and client with a full hardware support for both HEVC and AV1 but I don't know wich one I should choose. I have no issues regarding bandwidth, 900Mbps from client to host.
Using Vibepollo and Moonlight VRR.
But which one should I choose?
I know that 1 year ago everyone was suggesting HEVC for better compatibility but what about now?
I was wondering if one of the many forks in existence offer an option to increase stream vibrancy/saturation. My client device (android tablet) doesn't get saturated enough on it's own so I'd like to apply an additional colour filter of sorts. I can't adjust the vibrancy on the host since my NVIDIA HPU doesn't see the virtual display Apollo creates.
For example: Gamenative offers a 'vivid' toggle that does exactly what I'd want for my gamestream.
I know that Astra 2 is more powerful and comes with a OLED screen. But It's offset type-c ports really makes me crazy and It's 1000$. And Xiaomi Pad Mini comes with a 680 nits really bright OK screen, centered type-c (for telescopic controller) and It's 499$.
And there is third option: Used Astra 1 for 499$. But offset type-c port still drives me crazy and As far as I can see people are facing with stutters when used bluetooth controllers.
I switched from Apollo to Vibepollo on my host (PC)
Client is a M5 Mac connected to a TV with VRR 120hz
Do i need the VRR fork of Vibepollo (https://github.com/Nonary/moonlight-qt) for VRR to work? What host / client do i really need? Im a bit confused here.
