Start by finding who is affected and where the audio disappears. A silent microphone, an interrupted encoder upload and a website player that will not start need different fixes.
Use your account's Quick Listen Link on a second device as a comparison. Keep that device quiet or use headphones so its delayed audio cannot feed back into the broadcast.
Match the symptom to a starting point
| What you notice | Check first |
|---|---|
| Encoder cannot connect at all | Connection settings and source conflicts |
| Encoder is connected but its input meter is flat | Microphone or programme input, routing buttons and mutes |
| Encoder meter moves but every listener hears silence | The selected programme feed, stream/mount and encoder output |
| Every listener loses audio at the same time | Encoder connection log, source computer and upload connection |
| Only one listener has trouble | That device, player, network and output selection |
| Quick Listen works but your website player does not | Direct stream URL, HTTPS and player configuration |
A moving meter in the music player proves that application is producing audio. It does not prove the encoder receives it or that listeners can play it.
Silence: follow the audio through the setup
- Play a known track or speak into the microphone. Check the first application's input or playback meter.
- Check the mixer or virtual audio device feeding the encoder. Confirm the intended source is routed to the broadcast output and is not muted.
- Check the encoder's own meter. Select the programme device rather than an unused microphone, loopback or cue output.
- Check the correct station through Quick Listen Link, with the listener's volume turned up and the expected headphones or speakers selected.
For Voicemeeter Standard, the relevant strips need B enabled and BUTT must capture Out B1. For Mac BlackHole routing, check the player's output and BUTT's BlackHole input. A headphones-only route will not put that sound on air.
If music works but speech does not, follow the microphone path separately. Check its physical mute, input gain, software permission and mixer routing. Avoid solving a missing route by turning every gain control up; that can produce distortion when the source returns.
With Icecast, confirm that the encoder and player use the mount shown in the account. With any server type, check that an old player bookmark is not pointing to a different account or port.
Dropouts affecting the whole audience
Check the encoder log around the time listeners lost audio. Repeated disconnects point toward the source connection, while a connected encoder carrying silent audio points toward the programme input.
- Keep the broadcasting computer powered and awake during the show. Schedule restarts and software updates outside programme times.
- Compare a wired connection with Wi-Fi where practical. Pause unrelated uploads, backups or downloads that compete with the show.
- Leave upload capacity beyond the encoded audio rate for protocol overhead and other activity. A brief speed-test peak does not establish a stable connection for a full programme.
- Set MP3 bitrate at or below your account's Maximum Bitrate. If the source network cannot sustain your chosen rate, try a lower rate that suits the programme and compare the result.
- If the encoder reconnects automatically, still investigate the first failure. Reconnection restores the source after an interruption; it does not prevent the gap.
Choosing a radio bitrate explains the quality and data trade-offs. Your encoder uploads one programme to VosCast; the hosted server distributes it to listeners.
Crackling or distorted audio
Listen to the local programme before it reaches the encoder. If the fault is already there, check the source recording, microphone gain, mixer levels and audio devices first.
For virtual audio routing, use device-supported sample rates and check driver/buffer settings. A mismatch or a buffer that is too small can interrupt local audio even when the network is healthy. Follow VB-Audio's crackling and dropout guidance when using Voicemeeter. Do not repeatedly increase gain to correct a timing or driver problem.
If local sound is clean, compare the encoder feed and public stream in turn. Note whether the distortion begins only after a particular microphone, player or effect is enabled.
Problems affecting one listener or website
Ask the listener to press Play, check the tab and device volume, and confirm the output device. Bluetooth may have routed audio to headphones that are no longer being worn. Browsers may require an intentional tap before playing sound.
Compare Quick Listen Link with the embedded player. If Quick Listen works, check that the website player uses the direct audio URL rather than a station landing page, playlist download or server status page.
An HTTPS website needs a genuinely HTTPS-capable stream endpoint. Do not make one by changing http to https on a plain source/listener port. Our HTML5 player guide and WordPress player guide explain the setup. MDN describes why browsers block mixed HTTP content on secure pages.
If a second device plays normally on another connection, investigate the affected device or network. Mobile reception changes, data-saving settings and background restrictions can interrupt listening. See listening on a mobile device for the basic checks.
Check a hosted Auto DJ changeover
Stop hosted Auto DJ before connecting a live encoder. When the live show ends, stop the encoder and start Auto DJ manually. A closed encoder or browser window does not by itself start hosted playback.
If Auto DJ is running but silent, check that its playlist contains playable tracks and review the Auto DJ setup guide. Keep that investigation separate from the live computer's microphone and mixer settings.
Send support a useful example
If the problem continues, contact support with the server hostname, affected listening URL, exact time and time zone, encoder/version, and whether all listeners or one device were affected. Include a short, relevant log extract and say whether the local programme and encoder meters continued normally.
Remove passwords, access tokens and private account details from screenshots and logs. A specific example makes it easier to compare the source, server and listener sides of the same interruption.