SocketSVC DocsTroubleshooting
Automatic reconnection, /ssvc status, error messages, developer mode and common problems
Automatic reconnection
While you are still on the same Minecraft server, if voice had connected successfully and then drops because of the network or the voice service, the client automatically requests a new one-use token and reconnects — no /ssvc reconnect needed.
| Item | Behavior |
|---|---|
| Retry delays | 5, 10, 20, then 30 seconds after each failure, then at most every 30 seconds |
| Timeouts | Waiting for a token response and opening the WebSocket each time out after 30 seconds |
| Backoff reset | After the connection stays up for 30 seconds |
| Drop detection | A 10-second WebSocket ping/pong detects a dead connection even when nobody is talking; the retry delay starts from then |
| Tokens | Every attempt requests a fresh one-use token; a failed token is never cached or reused. The token's 30-second validity only applies to admission, so established connections need no periodic refresh |
| Preserved state | Mute/deafen and the first-run privacy setting survive recovery |
| Notifications | Repeated failures notify chat only once until voice recovers; settings shows "Voice will reconnect automatically" and the HUD shows "Reconnecting..." |
Even if a proxy doesn't advertise the plugin channel, a game connection that previously connected to voice can still request new tokens; the server must support socketsvc:handshake_request. Servers without SocketSVC simply stay offline, silently.
Automatic retries stop when:
- You leave or switch Minecraft servers (the schedule is cleared and late responses from the old server are ignored)
- Voice is stopped explicitly
- The connection is closed for replacement, quit, rate/policy rejection or an unsupported message (close codes 4000/4003/4008/1008/1003)
Old tokens are never reused, and the client never blindly reconnects to a server not confirmed to run SocketSVC. After retries stop, /ssvc reconnect explicitly starts again. Transient errors and token rejection (4001) retry automatically.
When your microphone disconnects
Unplugging a headset, a USB microphone resetting or a Bluetooth headset dropping out does not end your voice. The client reopens the microphone by itself — there is no need to go back into settings and pick it again.
| Situation | What happens |
|---|---|
| The microphone comes straight back (a brief reset) | Capture resumes within about half a second. Nothing is shown in chat |
| Your chosen microphone is gone, but another one exists | The system default microphone is used in its place, and chat says so |
| There is no microphone at all | The client keeps trying — every few seconds at most — and chat says so once |
| Your chosen microphone is plugged back in | The client switches back to it within a few seconds and chat says it is back |
| The microphone stays connected but stops sending audio | Treated as disconnected after 3 seconds of nothing, and reopened |
Switching back relies on your system reporting the device again once it is reconnected. If the chosen microphone does not come back on its own, pick it again under Devices — that always reopens it.
Manual reconnect and status
| Command | Purpose |
|---|---|
/ssvc status | Shows connection state, mute/deafen, mic RMS level and threshold, frames sent this session, and input/output devices |
/ssvc reconnect | Requests a fresh token without leaving Minecraft; requires an updated server, at most once every 5 seconds |
See Controls for details.
Error messages
| Message | Meaning |
|---|---|
| Invalid voice server URL. Ask the server admin to check public-url. | The voice URL sent by the server is malformed; the server admin needs to fix public-url |
| Voice authorization expired or was rejected. Run /ssvc reconnect to request a new token. | The token expired or was rejected |
| Could not connect to voice. Run /ssvc reconnect to retry. | The voice listener could not be reached |
| Could not start voice connection. Check the server URL and try /ssvc reconnect. | Opening the connection failed |
| Voice connection timed out. Run /ssvc reconnect to retry. | The connection didn't complete in time |
| Voice disconnected (reason). Run /ssvc reconnect to retry. | The connection dropped; the reason is in parentheses |
| Invalid voice handshake received. Ask the server admin to check SocketSVC. | Malformed handshake data, usually a server-side version or configuration problem |
| Microphone unavailable. Reopen your input device to resume. | The mic was unplugged or can't be opened; choose the microphone again on the General tab |
| A custom sample is silent, noisy, or reported as "could not be read" | Older builds misread 24-bit and 32-bit WAVs and could hand a WAV to the MP3 decoder; both are fixed. If it persists, the file name may match no drum — the drum kit setting lists which drums fell back to the built-in sound and which files went unused, and why |
| Instrument unavailable: ...line with format PCM_SIGNED... not supported | The device refused every capture format SocketSVC tried. Usually it is in use by another program — a DAW holding an interface exclusively is the common one — so close that first. The message quotes the device's own reason, which is the part worth reading |
While automatic reconnection is in progress, errors that mention /ssvc reconnect usually recover on their own.
Common problems
| Symptom | Check first |
|---|---|
| In game but no voice | /ssvc status, the server's status, base URL, listener reachability, proxy negotiation, first-run setup and mute state |
| Nobody hears me during first-run setup | No mic audio is transmitted until setup is closed with "Get started" |
| Works locally, but players on other machines can't connect | Ask the server admin to make sure public-host/public-url is an address players can reach, not localhost (see Run a server) |
| Audio tests pass but real calls sound wrong | Device routing, capture/playback settings, and a real two-player test; synthetic tests don't cover every acoustic condition |
| Others hear an echo of themselves | Make sure Advanced → Echo cancellation is on (an older saved "off" is kept on upgrade); for difficult devices turn off Automatic echo delay and set it manually. Headphones are the most reliable fix |
| Word beginnings or endings get clipped | Use Push to talk, or set Voice detection to Manual and lower the threshold |
| Background noise or game sound is transmitted | Turn on Noise suppression; on supported platforms download the Advanced Noise Cancellation model |
| Player volume shows "Waiting for players. Older servers do not support this list." | The server is too old; voice still works but there's no roster. Update both ends |
| Nameplates never show the deafened icon | Deafen-status sync requires both ends to be updated |
| Can't tell whether a voice is in front or behind | Use stereo headphones with other surround processing disabled; positioning is horizontal only, see Headphone spatial audio |
| Advanced Noise Cancellation says "Not available on this platform" | Only Windows x64, Linux x64 and macOS Apple Silicon are supported; other platforms use RNNoise |
| Advanced Noise Cancellation model download failed | Click to retry; RNNoise is used while downloading and after a failure |
The game crashes about when voice connects, with an hs_err_pid log saying EXCEPTION_ACCESS_VIOLATION in msvcp140.dll on the socketsvc-mic-capture thread | Windows only: your Java runtime ships an older Microsoft C++ runtime than the Advanced Noise Cancellation model (ONNX Runtime) needs, which crashes the game rather than failing. Turn Advanced Noise Cancellation off. Updated clients detect this and use the default noise suppression instead, showing Blocked by an old Windows runtime. To use the model anyway, run Minecraft with a newer Java 21 build, or install the latest Microsoft Visual C++ Redistributable if the old copy is Windows' own |
| "Another Voice Chat Mod Detected" on the title screen | Simple Voice Chat or Plasmo Voice is also installed. Both can stay; SocketSVC steps aside on servers that don't run it (see Compatibility) |
| No SocketSVC icon and its keys do nothing | Simple Voice Chat or Plasmo Voice is connected to this server and the server doesn't run SocketSVC, so SocketSVC is stepping aside. Expected |
| No Simple Voice Chat or Plasmo Voice icon, and its keys do nothing | That mod isn't connected, so SocketSVC switches its keys off. If the server does run it, it failed to connect; open its config screen from the mod list |
| Simple Voice Chat's or Plasmo Voice's V doesn't open its menu | Minecraft gave the shared key to SocketSVC; rebind one of the two in Controls (see Compatibility) |
| Opened a world to LAN but guests have no voice | Guests need the SocketSVC client mod for their own loader, and Advanced → LAN hosting → Host voice chat on LAN must be on; see LAN and singleplayer |
| Chat says the system default microphone is being used | Your chosen microphone is unplugged or unavailable; it is switched back to automatically when it returns — see When your microphone disconnects |
| Soundboard says "This server doesn't support the soundboard channel yet…" | The server is too old; clips go through your mic channel and can't play concurrently |
| Others can't hear my soundboard | The server may have soundboard-enabled: false or deny your socketsvc.soundboard permission; deafened listeners don't hear it either |
| URL download says ffmpeg couldn't be auto-downloaded | On macOS, install ffmpeg yourself (e.g. brew install ffmpeg) and restart the game |
| Disconnected icon on a server without SocketSVC | Expected: there is nothing to connect to. Press H to hide the HUD |
| HUD shows "Connecting..." on a server without SocketSVC | Shouldn't happen any more: "Connecting..." only appears once the server advertises SocketSVC or sends its handshake. If it does, the server (or a proxy in front of it) advertises SocketSVC's channel without running it |
Developer mode
Advanced → Diagnostics → Developer mode shows local voice statistics at the top right, refreshed twice per second; the setting persists:
- Packets per second sent (accepted into the WebSocket send queue) and received, plus session totals
- Local TX drops and their percentage
- Playback queue frames, source count, rebuffer target, overflow drops and latency trims
- Decoded frames, decode errors and invalid packets
- Buffer-ran-dry count (includes ordinary speech pauses) and time since the last audio packet
- Microphone RMS and whether you're transmitting
- Echo cancellation state (off / locked with delay / no lock, learning or ducking)
- Negotiated protocol version (v1/v2), missing frames, successful PLC frames and stale/duplicate frames
Reading it correctly:
- A sent packet means accepted into the WebSocket send queue, not acknowledged delivery.
- Missing frames are playout/application sequence gaps, not true TCP network loss; end-to-end latency and server-side drop telemetry aren't available in the overlay.
- Receiving nothing can simply mean nobody nearby is talking.
- Latency trims are frames skipped deliberately to give back buffered delay, not frames the link lost. A steady trickle of them means audio keeps arriving in clumps; a count that stops rising means the queue is sitting at its target.
- Counters reset on each new connection attempt and remain visible after a failure.
- No tokens, server URLs or player identities are displayed.
When reporting a problem, also turn on "Verbose logging" to write the connection, audio and network trace to latest.log.
Network delay and buffering
These are built-in client behaviors with nothing to configure:
- Playback adapts its start prebuffer between 60 and 400 ms based on arrival jitter, with a hard 1-second (50-frame) backlog cap per speaker. Arrival gaps raise the target quickly; it holds for one second and then decays a frame every 250 ms.
- Delay that a stall leaves sitting in the queue is given back. The queue cannot drain on its own - one frame arrives and one frame plays every 20 ms - so audio that piles up behind a hiccup is skipped back out, gently (one 20 ms frame per 240 ms, faster while far behind), until the queue is back to its target. A connection with no backlog is never trimmed. This is the behavior to expect if voice through a tunnel or reverse proxy used to start out fine and get steadily laggier the longer you talked.
- An instrument's line-in is drained the same way at the capture end, so a momentary stall on your own machine no longer leaves the instrument permanently behind your playing.
- Gaps of 1–3 frames (up to 60 ms) are concealed with Opus PLC; longer holes reset the decoder and resume with real audio.
- During temporary WebSocket backpressure, the sender keeps at most 25 packets per speaker and 256 in total, and discards the oldest packets once unsent audio is older than 600 ms.
Arbitrarily long TCP stalls can't be hidden with finite buffering; real cross-region connections still need testing.