u/doodooheadpoopoohead

Last week I posted about ChloroFrame, a native macOS Moonlight-style streaming client I’ve been working on. It’s still alpha, and this v1.1-alpha release is mostly a smaller audio/input update.

The main audio change is a more resilient CoreAudio pipeline for Wi-Fi jitter on my Mac setup. In Moonlight PC’s SDL audio path, the client keeps the audio side shallow: it avoids queueing decoded audio when Moonlight’s pending audio queue is already over about 30 ms. That keeps latency low, but when Wi-Fi delivery comes in bursts, the client has to choose between growing latency and dropping/skipping audio. Those missing samples can show up as clicks, pops, or brief stutters. And on MacOS this problem is annoyingly common, like every few seconds.

In ChloroFrame, this release adds an adaptive audio buffer. It starts around 60 ms, grows when underruns show the buffer is running too thin, and then slowly shrinks back down based on observed buffer drawdown. The adaptive target tops out around 95 ms, with a hard playback clamp around 125 ms. That is more latency than I’d ideally want, and on unstable Wi-Fi you may notice audio sitting a little behind video if you have a sharp eye, but in my testing it produces far fewer clicks and pops.

This update also includes keyboard/mouse input fixes and modifier remapping work. Which basically means you can rebind the modifers around or even diable the if you would like. You can also view stream control keybinds in the main app and by holding ctrl + option + cmd. I also added a way to send function commands from mac on to the host.

Controller support is next on my todo list.

Release: https://github.com/AmanBhardwaj25/ChloroFrame/releases/tag/v1.1-alpha

Hey everyone,

I just published the first alpha of ChloroFrame, a native macOS client for Apollo (the Sunshine fork), and wanted to share it here since this is where all of this work originates. I understand this might be very niche lol

Release: https://github.com/AmanBhardwaj25/ChloroFrame/releases/tag/v1.0-alpha
Repo: https://github.com/AmanBhardwaj25/ChloroFrame

Alpha warning, please read first

This is alpha/experimental software. It is not a Moonlight replacement and shouldn't be your daily driver. Expect bugs, crashes, stream instability, and edge cases that haven't been tested across different apple hardware, hosts, displays, and networks. If you need something reliable today, use Moonlight!

Honest disclosure about AI

I used AI heavily while building this. I'm a backend-heavy full-stack dev with no prior professional experience in real-time streaming, codecs, FEC, or low-latency transport . I started this to learn Swift/macOS development. If AI-assisted code is a dealbreaker for you, that's a completely fair position, and I'd rather you know upfront. Treat the codebase as experimental: read it, test carefully, assume there are mistakes and PLEASE REPORT THEM UNDER THE ISSUES SECTION ON THE GITHUB

What it is

A Swift client built around Apple's media stack: SwiftUI for the app, VideoToolbox for decode, Metal for rendering, Network.framework + POSIX sockets for transport, and CoreAudio + libopus for audio. Much of the core protocol work is a direct Swift translation/adaptation of moonlight-common-c:RTSP negotiation, RTP handling, FEC behavior, ENet control messages, and a lot of hard-earned protocol details within moonlight-common-c which are battle-tested

What works today (still alpha):

• Pairing with Apollo hosts and launching apps
• H.264 and HEVC decode through VideoToolbox
• HDR10/PQ streaming (HEVC, with a supported host app and HDR-capable display.
• Metal rendering with NV12/P010 zero-copy paths and display-link frame pacing
• RTP video assembly with FEC recovery (a Swift translation of moonlight-common-c's logic). For the Reed-Solomon math itself there's a toggle between a vendored C implementation and a pure-Swift translation of it. Both based on nanors, the same RS library moonlight-common-c uses. The C path is the default; I haven't scientifically benchmarked the two but the C path appears faster
• Opus audio via libopus and CoreAudio pull playback. I originally tried Apple's built-in Opus decoder (AudioToolbox's AudioConverter with kAudioFormatOpus), but based on my debugging it silently truncates 5 ms CELT packets to 2.5 ms, you lose half the samples and get robotic, choppy audio. libopus decodes every frame size correctly, so I vendored that instead. Might revisit AudioConverter in the future when i better understand it
• Keyboard and mouse input over the encrypted control channel

What's missing / coming:

• Gamepad, touch, and pen input: not implemented yet (I know, big one to miss). This is because I am trying to understand the input pipeline for game controllers and I want to see if there is any way we can support modern controllers with all the extra buttons and features. Currently on Apollo/ Sunshine side an xbox360/dualshock controller is emulated regardless of what you have paired on moonlight. This is because ViGEmBus, the software used for controller support ended support a very long time ago. So this whole chain needs a little innovation. Thats why I did not want to commit to the existing way of doing things controller wise. For now, if you need to use a controller, consider connecting it directly to the host
• The color scheme is super ugly lol. I know it. you are thinking it. I am not much of a creative designer as you can tell. I am going to ask my wife to help me redesign it when she has time.
• Audio resilience: packet reorder handling, packet-loss concealment, adaptive jitter buffering, clock-drift correction. I am learning about how webrtc handles audio jitter and I am going to use their math for handling AWDL/wifi related jitter issues in audio
• mDNS/Bonjour host discovery (currently a placeholder you have to do a manual IP entry)
• AWDL suppression is broken right now, it is a TODO
• Upstream Sunshine is untested. I develop against Apollo only. It may work where the protocols match, but no promises

Requirements: Apple Silicon Mac (no Intel support) and an Apollo host on the local network. Although, if you have sunshine installed on host im curious to know how it performs.

Testing help wanted: if you're the type who enjoys tinkering and can tolerate alpha-quality bugs, I'd genuinely appreciate GitHub issues. Reports with Mac model, macOS version, Apollo version, codec/HDR settings, and logs are gold.

Finally, a huge thank-you to the Moonlight team. This project simply would not exist without the years of difficult protocol and compatibility work the Moonlight and moonlight-qt developers have done in public. Please understand, this isn't a dig at moonlight-qt or a claim that it doesn't work. Moonlight is the mature client people should use when they need reliability. ChloroFrame is a learning experiment in what an Apple-native client could look like, built directly on the foundation they laid. Thank you!

TLDR: if you are having issues with micro stutters and/or audio stutters on mac silicon based macbooks, please give this moonlight version a try: find the release here and let me know what you think

If you are using mac silicon (M1,M2 and above) for moonlight you might have come across micro stutters and audio glitches/crackles/pops/stutters which make it annoying to stream on moonlight.

One of the moonlight devs have created a fork of the main moonlight-qt client which is written to be a native macos app. I tried it and it did wonders for the visual microstutters. but i still got audio crackles and pops every few seconds and if i stayed on stream for a long time i got visual jitters and micro stuttering too. So I forked that repo to debug these issues. So basically this is a fork of a fork.

One cause of all this as you may know is AWDL. It is the thing that controls airdrop, sidecar and some other features on apple devices. You used to be able to do one command in console and suppress it but these days in macos it just kind of brings itself back after a while. You might have come across some scripts to keep it down while you stream. This works but it is definitely annoying to keep track of. Another solution is to change your 5 gig wifi channel to 149 but that never worked for me. So i forked the code and implemented a script that comes baked in with the moonlight client that suppresses awdl automatically while you stream. when you quit out of moonlight stream it resumes awdl so you dont have to keep track of it.

The other thing that I had a very hard time finding info on was the annoying audio crackling and popping. it is hard to find info on, because when i google it, google thinks im talking about visual micro stutters so every search result was about visual micro stutters. Anyway, I was finally able to figure out why this audio crackle/stutter was happening, I forked the code for the native macos app and implemented a fix. the default value in the code was 30 ms. You can up this to 90 and the audio crackles should go away for the most part. this will introduce and imperceptible amount of audio latency. (well at least to me its imperceptible)

Very brief on why this crackle happens: the original moonlight client drops decoded audio frames whenever more than 30 ms of audio is queued in the pre-decode buffer. On a congested or variable-latency wireless connection this fires constantly, producing crackling and micro-stuttering that is unrelated to the video pipeline. I have implemented a slider to adjust this to a higher value so that the stream is more tolerant of network jitter. This is rooted in a fundamental issue with how macos handles audio. This is why this issue never happens on other clients like steam deck. because how the audio works on those clients is just different.

If you have this issue and dont mind testing:

You can find the release here