Sound Isn't Everywhere: How to Find the Cause During a Restream

Why Sound Disappears on Only One Platform

During a restream, a single broadcast is sent to several platforms at once. That's why it seems like all destinations receive exactly the same signal. In practice, after the stream is sent, each platform separately receives, checks, and processes the audio. It may use its own player, a different set of codec requirements, separate audio tracks, and automatic content checks.

If sound is present on two platforms but not audible on a third, the microphone isn't necessarily faulty. More often, the problem lies after the shared mix is created: in the settings of a specific destination, the audio track selection, the processing of the incoming signal, or the player itself.

Sound can disappear at various stages. It may not make it into the output mix, get lost in transmission to one destination, fail a format check, be disabled by the platform's system, or play only for some viewers. That's why you first need to determine exactly where the silence occurs, and only then change the encoder parameters.

The most useful reference point is to compare a local recording, the preview, the public broadcast, and a direct send to the problem platform. This order lets you avoid changing the microphone and all settings at random.

First, Make Sure the Problem Really Relates to Sound

Don't rely on a single viewer's report. The player may be muted, and the browser or app volume may be turned down. Sometimes the problem occurs only in the mobile app, a specific browser, or embedded viewing on another page.

Check the broadcast yourself in several ways:

• open the stream in incognito mode, where there are no saved player settings;
• watch it from another device or through another network;
• check the volume of the player itself, the browser tab, and the device;
• compare the public broadcast with the preview in the platform's control panel;
• after finishing, check the stream recording if the platform saves it.

If there's no sound in only one player, but it's present in the recording or for other viewers, there's no need to change the microphone and encoder settings. First check the cache, the app, the browser, and the state of the player itself.

If problems are audible everywhere, move on to checking the local recording and the output track. This will separate a source malfunction from an error on a specific platform.

Check Audio Before Sending to the Restream

The level indicator in the streaming program shows whether the mixer is receiving a signal. If the microphone or game meter is moving, that doesn't yet mean the sound is going into the right track and being sent to the platform. The mixer may show activity while the output stream uses a different set of channels.

Make a short local recording with the same settings used to launch the broadcast. It should capture all sources: voice, game, notifications, and other elements you plan to transmit. If the local recording is silent, the problem is in the source, the mixer, or the program's output audio.

Separately check for physical and software causes:

• whether a disabled or temporarily unavailable input is selected as the microphone;
• whether the sound is turned down on the source's fader;
• whether a scene source that should transmit the game or browser is turned off;
• whether a filter that completely suppresses the signal is applied;
• whether the input device changed after restarting the program or connecting a headset.

Listening through the program's monitoring isn't a complete check. Monitoring may work along a separate path and not match what goes out to viewers. It's more reliable to compare the indicators, the local recording, and the actual broadcast.

Check the Audio Track Selection

One common cause of selective silence relates to multiple audio tracks. In advanced output mode, voice, game, and music can be recorded separately. This is convenient for editing, but not every platform or restream service transmits and processes such tracks the same way.

One platform may take the first track and hear the full mix, while another receives a track that has only voice or no active sources at all. As a result, the video keeps going, but the sound disappears on that specific destination.

For diagnostics, temporarily route all necessary sources into one main track. Make sure that this track is the one specified for streaming, not just for local recording. If sound appears after this, the cause is found: you need to reconfigure the source distribution across tracks, taking into account each platform's capabilities.

Don't confuse separate tracks with the left and right channels. A track is a separate audio mix, while a channel is one side within that mix. If channels are mapped incorrectly, the voice may end up only on the left or right. It will be audible on one device, while on another the viewer will think there's no sound.

How to Set Up Tracks for a Compatible Broadcast

For a standard restream, it's safer to start with a simple shared mix. Create a main broadcast track and route voice, game, alerts, and other sources that viewers should hear into it. In the settings of each source, check the box for exactly that track.

Additional tracks can be kept for local recording. For example, save the full mix for the broadcast on one track, only the microphone on another, and the game on a third. But the streaming settings must have the track with the full mix selected. Separate recording tracks on their own don't guarantee that the restream will receive the shared sound.

After changing the scheme, save the profile and make a short recording. Then check the broadcast on the problem platform. If the restream service doesn't allow selecting a separate track for each destination, use a shared compatible mix for all platforms. A separate audio option for a specific platform is only possible when the service or an additional encoder supports different outputs.

If voice and game are distributed across different tracks, don't try to solve the problem by changing the volume. Volume won't add a source to another track. You need to open the audio mixer properties, mark the needed sources in the broadcast track, and restart the stream.

Typical Platform Audio Requirements

A platform may accept the video portion of the stream while processing the audio incorrectly at the same time. This happens with an unsupported codec, too high or too low a bitrate, the wrong sample rate, an unsuitable number of channels, or a non-standard combination of these parameters.

Exact requirements depend on the platform, protocol, and connection method. Before setting up, open the official help for the specific destination and find the incoming audio requirements. Pay especially close attention to them after switching to your own RTMP or RTMPS address, changing the encoder, or connecting a new restream service.

• Codec. For streams via RTMP and RTMPS, AAC-LC is often used. Opus and other options may be supported only with a certain protocol or type of incoming stream. You can't choose a codec just because it's available in the program.
• Bitrate. The requirements may specify a specific level, an acceptable range, or a maximum value. Compatible profiles often use values around 128 or 160 kbps, but this isn't a universal rule. If the platform limits the bitrate, exceeding the limit may cause the audio to be rejected while the video is retained.
• Sample rate. For broadcasts, 44.1 and 48 kHz are often used. It's important that the rate in the program, mixer, audio interface, and output encoder doesn't conflict. If the platform requires a specific value, select it at every stage.
• Number of channels. Mono contains one channel, stereo contains two. The platform may accept both options or require a specific scheme. Mono may be sufficient for voice, while game and music need a stereo mix if the requirements allow it.
• Codec profile and channel layout. Even a supported AAC may be configured with an unsuitable profile or incorrect left and right channel mapping.

If the official documentation doesn't specify a separate profile, use a simple option that your protocol supports for a control test: AAC-LC, the sample rate from the platform's requirements, a moderate bitrate, and a standard stereo mix. After a successful test, you can bring back additional tracks and complex processing one setting at a time.

Check Mono, Stereo, and Channel Layout

A channel problem can look like complete silence. For example, the microphone transmits a signal only to the left channel, and the platform or player processes such a stream incorrectly. In another situation, the shared mix is formed in mono, but the encoder expects a stereo signal with two channels.

Open the audio mixer settings and look at the balance of each source. For voice, check whether the slider is shifted fully to the left or right. If the program has a function to merge channels into mono, apply it to the microphone when the voice should be centered. This will eliminate the situation where speech is only on one side.

If the problem platform requires stereo, the output must contain two correct channels. Simply duplicating a faulty left channel doesn't always solve the task: you first need to make sure the source actually has a useful signal. Don't convert music and game to mono without necessity, since you can lose the spatial component.

After changing the channels, make a recording with voice and game, listen to it in headphones and on regular speakers. Then check the specific problem destination, because a local player may perform channel mixing in its own way.

Verify the Settings of the Specific Restream Destination

In the restream service panel, each platform may have its own configuration. Even if the source is shared, a destination sometimes has its own encoding profile, track selection, audio parameters, and connection method. After copying a setting from another broadcast, some fields may turn out to be unsuitable.

Check that the needed platform is actually active, connected to the correct channel, and receiving the current broadcast. A stopped or outdated destination may appear as connected even though the stream is no longer being received. If destination statistics are available, check whether the audio stream is being transmitted, not just the video.

Check whether an empty track is assigned to this destination. If the settings have an audio source selection, set the main track with the full mix. If you can specify the codec, bitrate, sample rate, and number of channels separately, compare these fields with the platform's official requirements.

After changing key parameters, fully stop the broadcast and start it again. Some settings are applied only when a new connection is created. Simply refreshing the page or pressing the start button again doesn't always rebuild the stream.

What to Do After Diagnostics: Reconfiguring for the Problem Platform

After checking, you need to not just identify the cause but change the specific part of the chain. First, save the working profile and note the original parameters. This will let you return to them if the new setting affects other destinations.

1. If the problem is the track, select the main track for streaming in the program and add all the sources viewers should hear to it. Keep additional tracks only for local recording. Restart the broadcast and check the result.
2. If the problem is the codec, select the codec explicitly specified in the platform's requirements. For RTMP or RTMPS this is often AAC-LC, but you should follow the documentation for the specific input. Don't use Opus if this protocol doesn't accept it.
3. If the bitrate doesn't match, set the value from the requirements or don't exceed the specified maximum. For a test, it's better to use one fixed profile rather than an automatic mode that changes parameters during the broadcast.
4. If the sample rate doesn't match, set the required value in the streaming program and check the audio interface settings. Don't let one part of the chain run at 44.1 kHz while another forcibly expects 48 kHz without correct conversion.
5. If the problem is the channels, set the required mono or stereo mode. For voice, first achieve an even centered signal, then set the output number of channels per the platform's requirements.
6. If none of the settings help, temporarily disable music, additional tracks, filters, and complex processing. Check a clean mix of voice and game to rule out the influence of a specific source.

After each change, run a short test. Don't change the codec, track, bitrate, and channels at the same time: otherwise it will be hard to link the result to a specific cause.

How to Convert Audio Before Sending

If the program or restream service can't bring the sound in line with a specific destination's requirements, you can use an intermediate audio converter or an additional encoder. It must receive the needed track, change the codec, sample rate, number of channels, and bitrate, and then send the stream to the problem platform's address.

For a compatible RTMP output, an example command might look like this: ffmpeg -i INPUT -map 0:v:0 -map 0:a:0 -c:v copy -c:a aac -profile:a aac_low -b:a 128k -ar 48000 -ac 2 -f flv RTMP_URL. Here the first video track and the first audio track are selected, audio is encoded in AAC-LC, the bitrate is set to 128 kbps, the sample rate to 48 kHz, and two channels. These values are an example control profile, not universal requirements for all platforms.

If the documentation requires mono, the channel count parameter is changed from "-ac 2" to "-ac 1". If a 44.1 kHz sample rate is specified, use "-ar 44100" instead of "-ar 48000". The bitrate is also replaced with the value from the requirements. Before launching, make sure the output protocol supports the selected codec.

The "-map 0:a:0" parameter is important: it explicitly selects the first audio track. If the full mix is on another track, you need to specify the corresponding number. A random track selection may again send voice without game or an empty audio stream to the platform.

There's no need to transcode video just because of a sound problem if it's already compatible with the platform. However, copying video with the "-c:v copy" parameter is only acceptable with a suitable video codec and container. The stream address and broadcast key must not be published in commands, screenshots, or logs.

Rule Out Automatic Muting Due to Content

If only music, video fragments, or another specific element disappears, the cause may be an automatic copyright check. Different platforms use different rules and recognition systems. One may keep the sound, another may temporarily mute the broadcast, block a specific fragment, or disable the sound in the recording.

Check the notifications in the creator panel and the status of the saved broadcast. It's important to compare not only the live broadcast but also the recording after it ends. If the sound was audible during the broadcast but disappeared in the recording, this points to subsequent processing, not a malfunction of the microphone or restream.

For a control test, use a short broadcast without music, video clips, and sounds whose rights aren't confirmed. Leave only voice and game sound. If the problem platform starts playing sound in such a test, the cause should be sought in the usage rules for specific content. Circumventing automatic restrictions by changing technical parameters isn't advisable: it doesn't remove the basis for the block.

Check the Network and Stream Reception

Audio data takes up less space than video, but it's transmitted in separate packets and depends on the stability of the connection to the server. If the connection is lost, the platform may continue showing video frames while the audio stops updating. This is especially noticeable if the problem appears a few minutes after the broadcast starts or disappears after reconnecting.

Check the statistics of the streaming program and the restream service itself. Pay attention to frames lost due to the network, reconnections, latency spikes, and error messages for a specific destination. If problems occur only when sending to one platform simultaneously, there may be a route issue between the service and its server.

Compare the result at different times and run a short test with the minimum necessary settings. If sound disappears on the same destination on every attempt while other platforms work, the problem is more likely in the reception or processing of that destination. If the result changes randomly, additionally check the network, the connection server, and the stability of the outgoing stream.

Compare the Restream with a Direct Send

A control launch directly to the problem platform helps separate the causes. Stop the multi-platform broadcast and send a test broadcast only to the needed platform, using the same audio source and a comparable profile.

• If sound also disappears with a direct send, check the platform, its requirements, the content, and the encoder settings.
• If sound is present directly but not through the restream, look for an error in routing, track selection, or the specific destination's profile.
• If sound is present in the preview but disappears for viewers, check the player, the broadcast recording, and processing after reception.
• If sound is present at first and then disappears, study reconnections, network errors, moderation, and transcoding behavior.

It's better to conduct such a test on a short private, restricted, or test broadcast if the platform allows selecting the appropriate mode. Don't change the scene, microphone, and all output parameters at the same time: the comparison will only be useful if the conditions remain the same.

How to Determine the Cause by the Nature of the Problem

Complete silence from the moment of launch is usually related to the wrong track, an unsupported format, or a missing source in the output mix. If the program's indicators are active but the local recording has no sound, the problem is almost certainly in the track selection or output path.

When the local recording has sound but one platform doesn't, check the settings of that destination and the receiver's requirements. If the problem appears only for some viewers, first rule out the player, browser, app, and device settings.

If voice is audible but the game isn't, or vice versa, this more often indicates sources split across tracks, a wrong fader, or a filter. If sound is present on only one side, check the mono and stereo channels, the balance, and whether the source channels match the output mix.

If the platform shows sound in the live broadcast but removes it from the recording, look at the copyright and content policy notifications. If sound disappears after a connection drop, the reconnection logs and network statistics matter.

What to Check Before Contacting Support

Platform or restream service support will find it hard to help with a report of "no sound on one platform." Prepare an accurate description and the results of short tests:

• the name of the problem platform and the connection method;
• whether sound is present in the local recording, preview, and public player;
• whether all sound disappears or only a specific source;
• whether it disappears immediately or after some time;
• whether sound works with a direct broadcast without a restream;
• which errors, reconnections, and notifications are shown in the logs;
• whether a separate audio track is enabled and which track is assigned to the stream;
• which codec, bitrate, sample rate, and number of channels are used on the output.

Attach a link to the test broadcast, the exact time the problem occurred, and screenshots of the audio mixer and destination settings. Passwords, broadcast keys, and access tokens must not be shared.

Brief Conclusions: What to Do Step by Step

1. Check the sound in the player, on another device, and in the saved recording.
2. Make a local recording and make sure the needed sources are audible in it.
3. Check the main audio track and temporarily combine voice and game into a shared mix.
4. Study the settings of the specific restream destination and its connection status.
5. Verify the codec, bitrate, sample rate, channels, and mono or stereo requirements.
6. Set up the broadcast track, then convert audio with a separate encoder if necessary.
7. Run a test without music and content whose rights may be checked.
8. Compare the restream with a direct send to the problem platform.
9. Save the logs and contact support with an accurate description of the result.

If the local recording and most platforms work, don't start by replacing the microphone. First check the audio track, the settings of the specific destination, the incoming stream format, the channels, the player, and automatic content processing.