[Yundi339]

The following is translated by AI.

Hi, I'm the developer of the Sunshine-Foundation and moonlight-vplus.

Moonlight has always been a one-way street for audio/video - downstream only, no microphone upstream. We implemented a microphone transmission protocol in Moonlight VPlus, and it's been in production with many users.

This PR contributes the code to the community, aiming to establish a unified specification. Better to standardize now before wider adoption to avoid microphone protocol conflicts down the road.

Everything defined here is open for modification - we'll follow the official guidelines.

---

Protocol Overview

Client captures mic → Opus encode → UDP send to host. Supports both plaintext and encrypted modes.

Packet Format

typedef struct {
    uint8_t  flags;           // Reserved, currently 0x00
    uint8_t  packetType;      // Fixed 0x61 (Opus audio)
    uint16_t sequenceNumber;  // Little-endian
    uint32_t timestamp;       // Little-endian
    uint32_t ssrc;            // Client identifier, little-endian
} MICROPHONE_PACKET_HEADER;  // 12 bytes

Followed by Opus-encoded audio (optionally encrypted). Total packet <= 1400 bytes.

Key Constants

#define MIC_PACKET_TYPE_OPUS  0x61        // Audio type
#define MAX_MIC_PACKET_SIZE   1400        // Max packet size
#define MIC_PACKET_MAGIC      0x12345678  // Client identifier
#define SS_ENC_MICROPHONE     0x08        // Encryption flag

---

Encryption Support

We use Sunshine-Foundation and Moonlight VPlus. The old version only supported plaintext MIC data transmission; the new version adds encrypted transmission.

For smooth upgrades (some users may still be on older versions), we implemented compatibility handling: RTSP handshake identifies whether both sides support encryption. If one side doesn't support it, falls back to plaintext. Developers can also force MIC to use encrypted transmission in code for absolute security.

• Algorithm: AES-128-CBC, reuses remoteInputAesKey
• IV Generation: riKeyId + sequenceNumber (big-endian) in first 4 bytes
• Negotiation Logic: If audio encryption is enabled, mic encryption is automatically enabled; if one side doesn't support encryption, falls back to plaintext

---

Design Notes

MIC_PACKET_MAGIC

This value is sent in every packet's SSRC field. Sunshine currently doesn't validate it.

Design intent: If multiple mic implementations emerge (different codecs, configs), this value can identify client type and enable plugin-based processing.

Reserved Interfaces

These are defined but not currently used, reserved for scenarios where mic needs to be dynamically started/stopped via control stream:

#define SS_MICROPHONE_MAGIC   0x55000008
#define MIC_CONTROL_START     0x01
#define MIC_CONTROL_STOP      0x02

FEC and Packet Loss

Opus library has built-in FEC and packet loss concealment, default FEC level is 1. Not explicitly configured in code - can be added to RTSP handshake if stronger FEC protection is needed.

---

Files Changed

File	Description
MicrophoneStream.c	NEW - Core implementation
Limelight.h	Added enableMic config and encryption flag
Limelight-internal.h	Internal function declarations
Input.h	Reserved interface definitions
Connection.c	Lifecycle management
RtspConnection.c	RTSP handshake
SdpGenerator.c	Encryption negotiation

---

Compatibility

• Mic initialization failure doesn't affect the connection, just mic unavailable
• Legacy Sunshine handshake failure auto-disables mic feature
• Encryption negotiation failure falls back to plaintext

[Yundi339]

Our microphone implementation is based on VBCable. While it shares functional similarities with another ongoing Sunshine Pull Request, the underlying mechanisms differ. We have considered merging the complete microphone codebase into the upstream repository; however, several challenges remain:

• Feature Coupling: The microphone logic is deeply integrated with our other proprietary features, making it difficult to isolate for a clean merge.
• Stability and Iteration: Having undergone several version updates, we believe the features require further maturation and optimization through continued real-world testing.
• Technical Refinement: Certain aspects, such as the Acoustic Echo Cancellation (AEC), have not yet reached peak performance. Additionally, two-way microphone communication between Sunshine and Moonlight is currently unsupported.

Given these factors, our current priority is to continue refining these capabilities. Should the opportunity arise to integrate with the community version in the future, we intend to perform a complete rewrite of the microphone logic to ensure it meets community standards and maintains long-term maintainability.

[jackson00w]

Hi, I'm a small developer and I'd like to know if you're still working on Moonlight's microphone support or if you've given up on the project. What was the last success you had with that project? Maybe I... I can help if you allow me to. I really want this to move forward because what the community wants most is a native microphone in Moonlight, right?

[Yundi339]

@jackson00w This PR is still active. It only covers the client microphone protocol in moonlight-common-c. I rebased it onto current master and left out everything that is not part of that protocol.

Detail:

The client captures microphone audio, encodes it as Opus, and sends it over UDP after an RTSP SETUP/PLAY for streamid=mic. Encryption is optional and reuses the existing remote-input AES-128-CBC key. The IV is riKeyId + sequenceNumber, big-endian, in the first four bytes. A negotiated encrypted packet carries exactly one PKCS#7 pad. If either side does not negotiate encryption, the packets stay plaintext. A microphone setup or initialization failure disables only the microphone and does not fail the connection.

The host-side capture stack, including the virtual microphone device and acoustic processing, remains in our own fork and is not part of this PR.

If you want to experience it, you can use our fork:
https://github.com/AlkaidLab/foundation-sunshine
https://github.com/qiin2333/moonlight-vplus

Notice: You need to install VBCable. However, you can also use other virtual microphones. I added the function of mixer a while ago, and unexpectedly, other virtual microphones can also be used! If you hear echoes, it’s probably because the speaker and microphone are using a virtual device