Spectralis devlog #6
—Hello again proggers—
Website stuff wrapped up at the 310ee27 merge, then everything shifted straight into Streamer Queue and shared play. Ten commits deep on dev, plus one fix that’s sitting uncommitted in the working tree because it’s the kind of thing you want to stare at twice before you trust it.
Cat or dog? Mp3FileReaderBase
print(f”I try to make stu{2f} which {actually_decodes} {cross_platform}”)
Okay let’s get into it~
—Yap—
Streamer Queue went from “backend endpoints exist” to “actual UI with history and add-to-queue” over the course of ten commits, shared play picked up presence and reactions along the way, and then right at the end I found out the MP3 decoder has been quietly depending on a Windows-only codec this whole time. Great.
cross-platform, they said. it’ll be fine, they said
—The Great Suffering—
1 — Streamer Queue Backend, Then Actually Wiring It Up
402e2ef–2b74f97 built out the Streamer Queue backend endpoints — host add, mark played, mark skipped — and wired them into the client through a new StreamerQueueViewModel. Backend existing and backend actually being called by anything are two different milestones, and this covered both.
2 — The UI Caught Up
16c4b26 added the add-to-queue button and a history panel, so Streamer Queue stopped being an API you’d have to hit manually and became something that’s actually usable in the app.
3 — Shared Play Learned About Presence and Reactions
ecb43e6 and c7a19c2 — shared play now fetches and exposes presence and reaction snapshots straight from the CDN. 7e60e15 then had SharedPlaySessionController pass presence, reactions, and queue through properly instead of any of those three living off on their own.
4 — HostAsync Was Ignoring The Host
92f2079. Found and fixed HostAsync quietly ignoring the host’s actual settings — not great for a feature called “host a shared play session.”
the host had opinions the whole time, we just weren’t asking
5 — Preloading and the Full Shared UI
22bc56e preloads the next track into the shared room too, so listeners aren’t waiting on it live. f2df836 (HEAD) rounds it out with listener count, a reactions ticker, and a request list in the shared play UI — the room finally looks like it has people in it.
Net diff for this stretch: SectionViewModels.cs (+206), backend/src/main.rs (+103), plus the SharedPlay CDN client/models and StreamerQueueView.axaml.
6 — The Uncommitted One: MP3 Playback Was Windows-Only This Whole Time
AudioEngine.cs and VideoExportEngine.cs were both using Mp3FileReader, which under the hood calls Windows’ ACM codec (msacm32.dll) to decompress. Which does not exist on Linux or macOS. Swapping to Mp3FileReaderBase with an NLayer decompressor instead — NLayer.NAudioSupport added to Spectralis.Core.csproj — since NLayer is a pure managed decoder and doesn’t care what OS it’s on. Not committed yet, wanted to sit with it first.
—FAQ (no one asked these but they are here)—
Q: What is a “progger”?
A: A human programmer. You. The one who just found out MP3 playback only worked on one OS.
Q: Was Spectralis actually cross-platform before this fix?
A: For anything that wasn’t MP3 audio, sure. For MP3 specifically, only on Windows, silently, this whole time.
Q: Why leave the audio fix uncommitted?
A: Swapping a decoder for something this central deserves a beat of “does this actually sound right” before it goes in, not just “does it build.”
Q: What’s the difference between Streamer Queue and the regular request queue?
A: Streamer Queue is host-controlled — add, mark played, mark skipped, from the streamer’s side, with its own history panel, separate from the public submission flow.
Q: Did shared play or Streamer Queue touch the Discord bot?
A: No, this round’s entirely Spectralis.App/Spectralis.Core and the Rust backend. Bot’s untouched.
—This is the end*—
*end for now, ACM codecs permitting
PARROT!!!