[REQUEST] Server-side multichannel audio splitting for surround sound (5.1/7.1/9.x Atmos) use cases

[eugenio]

Summary

The Sendspin protocol currently streams the same stereo audio to all players in a group. For home theater surround sound use cases (5.1, 7.1, 9.2.1 Dolby Atmos), the server needs the ability to split a multichannel audio source into discrete per-client streams — each player receiving only its assigned channel(s).

Use case

A user has an AVR (e.g. Denon X3800H) with Dolby Atmos decoding and analog pre-outs for each channel. They want to use ESP32-based Sendspin clients (e.g. Louder-ESP32S3 + TAS5805M) as wireless surround and height speakers, while the front stage (L/C/R + subs) remains wired.

The audio path would be:

AVR pre-outs (analog) → multichannel ADC (e.g. Behringer UMC1820)
    → Sendspin Server (Music Assistant / RPi)
        → splits into N discrete mono/stereo streams
            → Client "Surround Left"    receives channel 1
            → Client "Surround Right"   receives channel 2
            → Client "Surround Back L"  receives channel 3
            → Client "Surround Back R"  receives channel 4
            → Client "Top Middle"       receives channel 5

What's needed in the protocol

1. Multichannel source ingestion: The server should accept audio sources with > 2 channels (related to Add a "Source Role" for audio input devices so hardware can have Line-Level Audio input and can act as a Sendspin audio source? #14 Source Role, but specifically for multichannel PCM).

2. Channel mapping per client: When a group is configured for surround, each client should declare (or be assigned) which channel(s) it plays. The current output_channel_mode (stereo/left/right/mono) is a start, but surround needs explicit channel identifiers (e.g. front_left, surround_left, lfe, top_middle, etc.).

3. Server-side demuxing: The server splits the multichannel source and sends each client only its assigned channel(s) as an independent stream. This aligns with the existing architecture where "each client receives its own independently encoded stream."

How it relates to existing issues

• [REQUEST] Stereo Pair Support? #10 (Stereo Pair): Stereo pairing is the 2-channel case of this. Surround is the N-channel generalization.
• Add a "Source Role" for audio input devices so hardware can have Line-Level Audio input and can act as a Sendspin audio source? #14 (Source Role): A multichannel ADC source role is a prerequisite for this feature.
• Sendspin support for client-side "zones" or up to each clients to expose multiple players for multi-room audio? #72 (Client-side zones): Multi-zone AVRs and surround setups share the concept of routing different audio to different outputs.

Prior art

• WiSA: Proprietary protocol that does exactly this — up to 8 discrete channels to wireless speakers with <3ms latency and ±2μs sync. But it's closed, expensive, and limited to 8ch.
• Snapcast: Supports multiple named streams that different clients can subscribe to. No surround semantics, but the multi-stream model works for channel splitting.
• Sonos: Supports surround configurations with dedicated channel assignment per speaker in a group.

Why this matters

Sendspin's 50μs synchronization between ESP32-S3 clients is better than WiSA for this use case. The protocol already has the transport layer quality needed for surround — what's missing is the channel routing semantics. Adding this would make Sendspin the first open-source protocol capable of true discrete wireless surround sound.

This is a significant differentiator: no open protocol currently offers synchronized, discrete multichannel wireless audio for home theater.

[sadpixel]

This would be so, so awesome to have. 🤩 Absolutely game-changing if implemented. 🥹

This is one of those things where the ROI practically justifies itself, given that — as eugenio correctly notes — the hard work/plumbing is already done! “Just” gotta demux the source audio and have the ability to assign roles/channels to specific speakers.