A radio station can reach YouTube as a live audio programme paired with a visualizer that fills the video frame. The practical route is to identify a usable mixer output, confirm Linux can capture it, build and test an OBS scene, then send that scene to YouTube Live Control Room.
Do not assume that the mixer output, Linux capture path, channel eligibility or music rights are already in order. Check each before scheduling a broadcast; a moving visualizer does not prove that the intended station audio is reaching viewers or that the music is cleared for this use.
Check that your channel can go live
Before wiring up equipment or announcing a launch, check the channel’s access to live streaming in YouTube Studio. YouTube’s current getting-started guidance says the channel must be verified and must not have had live-streaming restrictions in the previous 90 days; it also says users must be at least 16 to live stream. Read the current eligibility guidance and confirm the status for the channel you will use. Access on a personal channel does not establish access on a different channel managed by the same volunteer.
If the channel is not eligible, resolve that first rather than treating an encoder error as the main problem. Eligibility is separate from broadcast settings: a correct stream key and working OBS scene cannot bypass a channel restriction. If you are planning a first public programme, allow time for any required verification and check the status again before the planned start.
Music permission is a separate check. The technical setup described here does not determine whether you may broadcast a particular recording, catalogue or continuous radio programme on YouTube, or in each territory where viewers may watch. Confirm the rights for the actual recordings and intended use with the relevant rights holders or your organisation’s adviser. A visualizer, artist credit, radio licence for another form of transmission, or successful test broadcast does not by itself establish permission for a YouTube live stream.
Agree who is responsible for the channel, music and on-air decisions. A volunteer who can operate OBS is not necessarily authorised to reset channel credentials or decide that a catalogue is cleared. Put the current contact and escalation route somewhere the person on the next shift can find it.
Find an output from the station mixer
A station mixer may have several outputs: a control-room monitor feed, a recording output, a broadcast output, or a headphone socket. They can carry different signals and may have different connector types and levels. Do not select a socket by name alone. Ask the person who maintains the station whether the output is intended for a recorder or encoder, whether it is affected by monitor controls, and whether it includes every source that should go on air.
Trace the route on paper before connecting anything: programme sources into the mixer, the chosen output into the computer’s audio interface, and the captured interface input into OBS. Mark the left and right channels and note whether the connection is balanced or unbalanced if that information is available. A computer’s built-in microphone jack may not accept a line-level stereo feed; a suitable audio interface may be needed. Check the interface and mixer manuals rather than forcing a connector or raising levels to compensate for an unsuitable input.
Test with the station playing representative material. Listen at the mixer, at the interface’s monitoring output if available, and on the computer. Check speech, music and transitions, not just a quiet moment. Confirm the signal is stereo if that matters to the programme, and listen for hum, distortion, silence on one side or abrupt changes when a presenter adjusts a control.
If a volunteer changes a cable, mixer bus or source selection, have them record what changed and how to restore the previous route. A labelled cable and a simple signal-flow note can prevent the next operator from tracing the entire room during a failed preflight. Keep the station’s normal on-air path intact while testing the stream feed; do not interrupt local broadcasting to troubleshoot YouTube unless that is an agreed fallback.
Capture and test audio on Linux
Linux audio routing varies with the distribution, desktop and sound system in use. First identify the device that the operating system sees, then choose that device and its intended input in the audio settings or in OBS. Do not assume that an interface appearing in a device list means OBS is listening to the right socket: many interfaces expose several inputs, and a mixer output connected to one pair may not be the pair selected by the application.
Play the programme and watch OBS’s audio meters while changing one thing at a time. If there is no meter movement, check the physical connection, interface input selection, operating-system device selection, OBS source and mute state. Avoid adding a second capture route until you know what the first one is doing; duplicate input paths can create echo or doubled audio. If the meters move but the preview is silent, inspect OBS monitoring and output routing separately from the source itself.
Listen to the actual stream from another device, not only to the computer’s local monitor. Monitoring can make an audio path seem healthy even when OBS is sending the wrong source, or when a local application is playing audio that is not part of the stream mix. A private or unlisted test is useful for checking this end-to-end route. Use material representative of the live programme and check the resulting playback for clipping, drop-outs, a missing channel, or a mismatch between the visualizer and sound.
For clipping-specific diagnosis, use the OBS audio clipping checklist as a separate reference; this station setup still needs its own test with the real mixer feed. Do not fix a clipped signal by turning down a random control without locating where distortion enters. Reduce a level at the stage that is overloading, then listen again at both the OBS meters and the remote playback.
A microphone is not required for a music-only station feed. It may be useful if presenters will make live announcements or record identifications, but treat it as another source to test and mix deliberately. Keep it muted when not needed, and check that it does not pick up the control room or create feedback through loudspeakers.
Build the OBS scene and visualizer
Create an OBS scene that contains the intended station audio and a visualizer source. The visualizer should remain visible across the full video frame and at the output resolution you have selected. Keep text, station identification and other essential information away from edges where different screens may crop or obscure it. For a mostly static radio programme, a restrained design can make the channel recognisable without competing with spoken announcements or song information.
One available software route is the Waveform OBS plugin. Its OBS Forums listing describes an audio-source visualizer with frequency-spectrum, meter and waveform modes, including bar and circular forms. Check the current Waveform listing for platform and OBS compatibility before installing it; plugin support and update details can change. The listing reports Linux support and a minimum OBS version, but do not treat that as proof it will work with your particular distribution, OBS build or audio-source type.
The critical setting is the source the visualizer listens to. Choose the captured station programme, not a desktop sound source that happens to be active or a microphone that is not part of the broadcast. Start representative music and speech, then confirm that the visualizer reacts to that exact signal. A visualizer moving in response to a test tone while the station feed is silent is not a successful test.
Compose the scene with clear source names, for example “Station interface input”, “Visualizer” and “Station identification”. This helps another volunteer inspect the scene without guessing. Keep a copy of the scene or document changes before modifying a working layout. If the plugin is unavailable or incompatible, use a simpler visual source rather than postponing the audio-path checks; a visualizer is presentation, not a prerequisite for sending a valid programme.
OBS is a local encoder: the computer must stay available while it is sending the broadcast, and a failure of that computer or its local audio capture can interrupt the feed. If the station needs a broadcast that continues when the room computer is switched off, StreamNeo removes that specific operational dependency by turning an uploaded video into a YouTube live broadcast without leaving the station computer running. That is a different workflow from the Linux mixer-to-OBS route in this guide, and it does not decide whether the station’s music is cleared.
Add YouTube’s ingest URL and stream key
In YouTube Studio, use Create and Go live, then create or select an encoder stream in Live Control Room. YouTube supplies a server or ingest URL and a stream key for the selected stream. Enter these in OBS’s stream settings, taking care to use the matching values for the stream you intend to test or schedule. YouTube’s encoder setup instructions describe the workflow; menu labels can vary as Studio changes.
Treat the stream key like a password. Anyone who has it may be able to send video to the associated stream. Do not put it in a public volunteer rota, screenshots, shared chat or a scene name. Restrict access to people who need to configure the encoder, and remove access when roles change. If you think a key has been exposed, follow YouTube’s guidance to reset it and update the authorised encoder configuration; a newly reset key will mean an old saved configuration no longer sends to the intended stream.
For a volunteer handover, share a checklist that says where to retrieve the key securely, not the key itself. Name the channel and scheduled stream in the instructions so an operator does not paste one channel’s credentials into another channel’s OBS profile. If more than one person handles the broadcast, decide who is permitted to change stream settings and who can reset credentials.
YouTube recommends RTMPS for encoder ingestion. In OBS, select the appropriate YouTube service or enter the server URL and stream key as directed by the current Studio interface. Avoid copying credentials from an old screenshot or assuming a saved profile is current. A connection attempt only proves that OBS can reach an ingest endpoint; wait for the Live Control Room preview and inspect it before starting the public programme.
Set video and audio with upload headroom
The video workload is often modest for a radio visualizer, but it still needs to fit the connection and remain stable. Pick a resolution and frame rate that suit the design rather than choosing the highest available setting by default. YouTube’s encoder settings guidance gives recommended bitrates by codec, resolution and frame rate; the H.264 recommendations in that table include 8 Mbps for 720p at 30 fps, 10 Mbps for 1080p at 30 fps, and 12 Mbps for 1080p at 60 fps. These are settings guidance, not a guarantee that a connection can sustain them.
For H.264, YouTube also lists 8 Mbps for 720p at 60 fps. The table includes separate recommendations for other codecs, so match the row to the codec actually selected by the encoder. Its general guidance calls for constant bitrate, a recommended two-second keyframe interval, and an interval not over four seconds. For stereo audio it lists a 44.1 kHz sampling rate and 128 Kbps audio bitrate. Check the current page before a launch because technical guidance can be updated.
YouTube recommends leaving 20% of upload bandwidth available beyond the total stream bitrate. Measure upload performance on the connection that will carry the actual programme, preferably at the time and location it will run. Other traffic on the same connection can consume the margin. If a volunteer’s laptop backup or a large upload starts at the same time, the measured capacity from a quiet test may not represent the broadcast conditions.
| H.264 output choice | YouTube recommended video bitrate | Practical consideration |
|---|---|---|
| 720p at 30 fps | 8 Mbps | A reasonable starting profile for a simple visualizer if the connection sustains it with headroom. |
| 720p at 60 fps | 8 Mbps | More frames than a mostly static design may need; test whether the smoother motion is useful. |
| 1080p at 30 fps | 10 Mbps | More detail for text or artwork, with a higher upload demand than 720p at 30 fps. |
| 1080p at 60 fps | 12 Mbps | Higher frame rate and bitrate; use only when the design benefits and the link is stable. |
These figures refer to recommended video bitrate, not total connection use: audio and protocol overhead also matter. Include all outgoing stream traffic when checking headroom. A wired network connection can reduce one source of local variability, but it cannot correct an overloaded internet link, an unstable router or an audio capture fault. The right profile is the one that stays healthy in a representative test, not the largest number in a table.
Run a preflight before the programme
Make a short preflight that the next volunteer can follow without relying on memory. Start with channel eligibility, the correct scheduled stream, rights confirmation for the planned material, and access to the current stream key. Then inspect the mixer route, Linux input device, OBS source selection, visualizer response, video framing and mute states. Listen to the remote test from a separate device, using the same network conditions and content type expected during the programme.
Check audio across quiet and loud passages. OBS meters should respond without staying pinned at the top; remote playback should be intelligible and free from clipping or drop-outs. Confirm both left and right channels if the feed is stereo. Speak an announcement if one is planned, then return to the music source and check that the levels and visualizer respond as expected.
Check the preview image for the intended scene and wait for YouTube to report stream health. OBS showing that it is connected is not the same as YouTube showing a usable preview. Verify that the programme audio reaches that preview, that the picture is not black or cropped, and that the visualizer is reacting to the radio feed. Keep a second device available for a viewer-side check; this catches problems that are hidden by local monitoring.
Write down what “ready” means and who can stop the broadcast if something is wrong. For example, pause launch if the preview has no station sound, if the visualizer responds to the wrong input, or if the rights check is unresolved. A volunteer should not have to decide whether a damaged feed is acceptable while viewers are already watching. Keep troubleshooting steps simple and indicate who to contact for mixer, Linux, OBS or channel access issues.
The OBS connection troubleshooting guide is useful if OBS remains stuck while connecting, but verify the current URL, key, network and YouTube status rather than repeatedly restarting at random. If the route is still unclear, return to the signal path and check each stage from mixer output to remote playback.
Monitor Live Control Room during the broadcast
Once OBS is sending, wait for the Live Control Room preview, inspect the audio and picture, and then use Go live when the stream is ready. YouTube’s live stream setup guidance describes previewing and starting an encoder stream. Do not assume a green-looking local OBS state is enough; the preview is the point where you can confirm that YouTube is receiving the intended programme.
Keep Live Control Room visible to the person assigned to monitor the stream. Watch for changes in stream health and listen to the programme from a separate device at sensible intervals. If the visualizer freezes but audio continues, decide whether the channel can continue with a static image while someone investigates. If audio drops or becomes distorted, the priority is to restore a reliable programme feed rather than leave a misleading picture running.
Agree in advance what the operator should do after an interruption. Recheck the mixer and capture path, confirm that the encoder is still using the active stream key, and look at the Live Control Room preview before resuming. Avoid changing several settings simultaneously, because that makes it harder to identify what fixed or worsened the issue. Keep a brief incident note for the next shift: time, symptom, action taken and whether the feed recovered.
When the programme is finished, use End stream in Live Control Room and stop sending content from OBS. YouTube says streams under 12 hours are automatically archived, but check the resulting video and channel settings rather than relying on archive behaviour as a substitute for a recording plan. If an archive matters, confirm where it appears and who is responsible for reviewing it. The guide to writing a title for a 24/7 stream can help you make the archive and ongoing channel purpose clear without promising an audience outcome.
A continuous station schedule also needs a reliable handover, not only a working launch. Record the scene name, selected Linux input, mixer output label, profile and escalation contact in a controlled operations note, but keep the stream key out of that note. If the station changes its programme or visualizer, run the relevant tests again rather than assuming that a previously healthy stream proves the new arrangement.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Can I broadcast only audio to YouTube Live?
An encoder stream needs a video picture as well as audio, so pair the station feed with a visualizer, artwork or another appropriate visual source. Test that the picture reaches YouTube and that the audio is part of the same OBS output. A moving visualizer is optional presentation, not proof that the audio route is correct.
Does the visualizer need to listen to the microphone?
No. For a music-only station, set it to listen to the captured programme feed. If you include a microphone for announcements, decide whether it belongs in the programme mix and test how it affects the visualizer and final audio.
Why does OBS show audio when viewers hear silence?
The local meter may be responding to a source that is not included in the stream mix, or the preview and viewer playback may not match what you hear through local monitoring. Check OBS’s selected source and mute state, then verify the YouTube preview and a separate device with a representative test. Follow the signal from mixer output through Linux capture to OBS rather than changing levels at random.
Does a successful test mean the station can broadcast its music?
No. A test checks the technical route, not the rights for the recordings, catalogue, territories or continuous live use. Confirm the relevant permissions separately before the public broadcast, and recheck if the programme’s material or intended use changes.