There Are Many Layers Between “Online” and “Audible”
In CVoice Stage, the singer’s microphone is published primarily as Opus over WebRTC, and the room service relays the singing only to listeners in the same room. Video is loaded independently by each browser and does not pass through the karaoke-room server. Even after connection negotiation completes, public media ports, inbound data, decoders, the audio context, or speaker permissions can still fail at any layer.
An early status display showed only “OPUS,” making it easy to mistake successful negotiation for successful playback. It was later split into “OPUS publishing,” “RTC checking,” “OPUS audible,” and “PCM fallback,” so each state corresponds to an observable fact.
How to Prove the Listener Actually Received Audio
Seeing inbound packets is not enough: packets may fail to decode correctly, or they may decode to silence. The listener periodically reads WebRTC inbound statistics and also observes the actual decoded waveform. The parallel PCM fallback is stopped only after valid audible signal has actually appeared recently.
This check must also understand normal pauses. A waveform briefly going quiet while a singer breathes should not immediately be treated as a stream failure. As long as inbound data continues and the track has already been verified as audible, the primary channel remains active. If packets stop, decoded output stays silent, or the track is interrupted, the fallback channel continues carrying audio.
Mobile Browsers Also Require a “User Gesture”
Mobile browsers often block pages from autoplaying audio or resuming an audio context without a click. Room connection should not wait for audio authorization, or a refresh may leave reconnection stuck indefinitely. But when playback is actually needed, the interface should provide a clear “Enable video and singing audio” button that starts media and audio processing within the same user gesture.
iOS also imposes special restrictions on media-element volume control. Stage connects controllable media tracks to a Web Audio gain node and, if the first connection fails, allows a user gesture to trigger another attempt instead of letting one failure prevent mixing for the entire room.
Fallback Must Not Come at the Cost of Obvious Desynchronization
Live singing and the video loaded locally by each listener travel over different paths, so network latency and device buffering cannot be identical. When switching from the primary channel to fallback, the audio must continue to follow the song timeline without making the video jump. The system records the singer’s configured lead and current path estimates, then applies limited delay to remote audio so the two paths stay as close as possible to the same time reference.
| Diagnostic Signal | What It Does Prove | What It Does Not Prove |
|---|---|---|
| Signaling Connection Succeeds | Both sides can exchange negotiation data | Does not prove media packets have arrived |
| Inbound Packets Keep Increasing | The network is carrying media data | Does not prove the browser decoded audible audio |
| The decoded waveform contains a valid signal | Primary Channel Recently Had Real Audio | Does not guarantee the user’s speaker volume is appropriate |
| User Confirms Audio Is Audible | The full path works on the current device | Does not represent other listeners’ devices |