feat(ws): drop embedded audio from CAL messages#26
Merged
Conversation
- NewCALMessage signature changed to (payload) — second []byte parameter removed; payload is metadata only, no "audio" field. - ws.Hub.BroadcastCAL no longer touches the disk: docstring updated to reflect that audio is fetched on demand by clients via GET /api/calls/:id/audio. The hub already received pre-built bytes, so no signature change there. - handler/calls/upload.go and dirmonitor/watcher.go: removed the os.Root + io.LimitReader audio read whose sole consumer was the WS payload. Unused 'io' / 'os' imports cleaned up. - ws/messages_test.go: dropped TestNewCALMessage_WithAudio; updated TestNewCALMessage to call the new single-arg signature and added a bytes.Contains guard asserting the marshalled frame contains no "audio": substring. - CHANGELOG: bullet under [Unreleased] ### Changed. Frontend client will be updated in the next PR — current SPA build will lose live audio playback once this merges; ship the frontend rewrite PR immediately after.
revtex
added a commit
that referenced
this pull request
Apr 25, 2026
#27) - Replace base64-over-WS + Web Audio decode pipeline with a single persistent hidden HTMLAudioElement, wired through MediaElementAudioSourceNode → GainNode → AudioContext.destination so the existing volume slider and gain graph keep working. - WS client no longer parses or holds an audio callback; on CAL it dispatches callReceived(call) to Redux. A new listener middleware drives the player off the calls slice. - Per-call playback flow: audio.src = /api/calls/:id/audio, preload auto, play() on canplay, advance queue on ended/error. - Download buttons in BookmarksPanel and SearchPanel are now plain <a download> anchors pointing at the same authenticated endpoint. - Shared-call page uses <audio src=/api/shared/:token/audio> directly. - Autoplay-unlock now also primes the persistent <audio> element inside the user-gesture handler (play().then(pause)) so subsequent programmatic play() calls succeed on Mobile Edge / Mobile Safari. - Tests updated to drive the new flow; 188 frontend tests pass. Pairs with backend PR #26 dropping audioData from CAL frames; merge that one first, then this.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR breaks live audio playback for the current frontend. The frontend rewrite PR (Phase 3) must merge immediately after this one. They form a paired hard cut. Do not deploy
devto production between the two merges.Summary
WebSocket
CALmessages no longer carry embedded base64 audio. The listener WS becomes a pure metadata/notification channel; clients fetch audio on demand via the existingGET /api/calls/:id/audioHTTP endpoint, authenticated via theos_sessioncookie shipped in the previous PR.Changes
backend/internal/ws/messages.goNewCALMessage(payload)— second[]byteparameter removed; noaudiokey in the payloadbackend/internal/ws/hub.gobackend/internal/handler/calls/upload.goos.Root+io.LimitReaderaudio read whose sole consumer was the WS payload. Unused imports cleaned.backend/internal/dirmonitor/watcher.gobackend/internal/ws/messages_test.go"audio":substringCHANGELOG.md[Unreleased]### ChangedWire-size impact
A typical CAL was 30–80 KB depending on the codec and call duration (base64 inflates by ~33 %). Going forward each CAL is a small JSON object — under 2 KB in practice. The audio file is downloaded once via HTTP with full
Rangesupport and benefits from the browser HTTP cache on replay.Verification
go vet ./...— cleango build ./...— cleango test ./...— all passrg '"audio":' backend/internal/— only test assertions confirming absencerg 'audioData' backend/internal/ws/— zero hitsSelf-review
publicAccesssemantics; this PR removes a duplicate delivery channel, not an authorization layer.Pairing
The frontend rewrite (Phase 3) is on branch
feat/audio-element-playback(will be opened next). Merge sequence: