Mixxx does not document a direct YouTube Live output. Its built-in Live Broadcasting feature sends your mix to Shoutcast or Icecast, so YouTube needs a separate encoder between Mixxx and the live channel.
The working route is: Mixxx produces the radio audio, an operating-system-supported capture or loopback path feeds that audio into an encoder, and the encoder adds a visual before sending the result to YouTube. The exact audio-routing steps vary by operating system and configuration, so test the complete path before you publish it.
What Mixxx Live Broadcasting supports
Mixxx's Live Broadcasting documentation describes sending audio to Shoutcast and Icecast servers. It does not document YouTube as a destination. That distinction matters because the settings you enter in Mixxx are not the same as the connection details YouTube gives an encoder.
In Mixxx, you can open Preferences and select Live Broadcasting. The manual describes connection types including Shoutcast 1, Icecast 1 and Icecast 2. You normally enter the server host, port, login details and other information supplied by the radio-server provider. For Icecast, the mount field must not be blank. The host field should contain the hostname or IP address, while the port belongs in its separate field rather than being included in a complete URL.
After saving the connection, the documented menu route is Options, then Enable Live Broadcasting. The labels can differ between releases or platforms, so use the manual matching your installed version if you see different wording.
That feature is useful when you want Mixxx to publish an internet-radio feed to an Icecast or Shoutcast server. It is not, by itself, a YouTube encoder. Mixxx can be one part of the workflow, but YouTube still needs a video-capable output carrying the stream URL and stream key.
Also check the format accepted by the radio server you are using. Mixxx notes that Ogg Vorbis is not supported by Shoutcast. If you are configuring a Shoutcast or Icecast leg, follow the format requirements of that server rather than assuming that a setting suitable for YouTube will also suit the radio-server connection.
Why YouTube needs a separate encoder
YouTube Live receives an encoded audio-and-video stream. Even if your channel is intended to be an audio station, the YouTube destination still expects video. A still station image, a visualiser, or another appropriate moving source can provide the picture while Mixxx supplies the sound.
YouTube's encoder workflow asks you to put the YouTube Live server URL and stream key into an encoder. Its official encoder instructions describe that connection rather than a Mixxx connection. In practical terms, the encoder is the bridge: it receives Mixxx audio, combines it with a video source, encodes the programme and sends it to YouTube.
This is why it is misleading to say that Mixxx streams directly to YouTube. Mixxx's documented broadcast output and YouTube's ingestion input are different stages. You can use OBS Studio or another encoder, but you must confirm that the chosen encoder can receive the particular audio capture or loopback input available on your computer.
There are two broad ways to build the bridge:
| Route | How it works | Main advantage | Main trade-off |
|---|---|---|---|
| Local capture or loopback | Mixxx plays audio, and an operating-system-supported capture input feeds it to the encoder | Fewer network services and usually a shorter path | Audio routing and permissions vary by operating system |
| Radio-server hand-off | Mixxx sends audio to Shoutcast or Icecast, and a compatible encoder takes audio from that service | The public radio feed can remain independently available | More services, credentials and failure points to configure |
The second route should not be confused with YouTube ingestion. Mixxx supports the radio-server leg, while YouTube supports the encoder-to-YouTube leg. Whether a particular encoder can ingest a particular Shoutcast or Icecast output must be checked in that encoder's current documentation.
For a small station that only needs YouTube, local capture may be the simpler architecture if your operating system exposes a dependable loopback or capture device. If the station already has a working Icecast or Shoutcast service that must continue serving listeners elsewhere, the server-based route may be worth the extra configuration.
Route or capture Mixxx audio
Start by deciding where the encoder will obtain its audio. Do not begin with a copied setting from another operating system. A method that works with one system's virtual device, monitor source or loopback utility may not appear on another system, and the names shown in Mixxx, the operating system and the encoder may all differ.
For a local workflow, the general sequence is:
- Play a known track or programme in Mixxx.
- Make an operating-system-supported capture or loopback input available.
- Select that input in the encoder.
- Watch the encoder's audio meter while Mixxx is playing.
- Confirm that the captured signal is the intended Mixxx output and not an unrelated microphone or system sound.
The crucial point is that the encoder needs an input carrying Mixxx. Selecting a microphone will not capture Mixxx unless your operating system has been configured to route the Mixxx output there. Selecting a generic desktop or system-audio source may capture notifications, browsers or other applications as well. That can be acceptable for a controlled test, but it is risky for an always-on station.
Check permissions before troubleshooting the encoder. The operating system may ask for permission to access audio capture, desktop audio or input devices. If Mixxx is playing but the encoder meter remains silent, inspect the selected device, the operating system's input and output assignment, the loopback or virtual-device configuration, and Mixxx's own output level.
Keep the signal path simple. Every extra mixer, virtual device or monitoring route creates another place for silence, clipping or feedback. Use headphones only when you can monitor without sending the encoder's output back into the captured input. If you hear an echo, stop and identify whether the encoder is capturing its own return signal.
A server-based workflow is different. In Mixxx, configure the Shoutcast or Icecast connection as documented, then enable Live Broadcasting. The encoder must then have a compatible way to receive the station audio from that server. That could involve a network stream input or another feature documented by the encoder, but you should not assume that every encoder can open every radio-server output.
This route adds a useful separation: the radio server may continue to serve listeners even if the YouTube encoder is stopped. It also adds credentials, network connections and another service to monitor. If the station does not need an independent internet-radio stream, the local route may avoid that additional dependency.
For a long-running channel, write down the complete audio path before going live. For example: Mixxx master output, operating-system loopback device, encoder audio input, encoder programme output, YouTube preview. This gives you a useful checklist when the station is silent after a restart.
Add a visual source for the radio station
YouTube Live is not an audio-only destination, so add a video source in the encoder. For an internet radio station, that may be a station logo or programme card, a still image with the current show information, or a restrained visualiser. The source should be appropriate for the rights you hold and should remain readable on a phone as well as a larger screen.
A static image is the simplest test source. It lets you confirm the audio path without adding motion, browser sources or additional applications. Once the basic stream works, you can replace it with a visualiser or a sequence of programme images if that serves the audience better.
Avoid treating a visualiser as proof that the audio is working. Some visual sources animate even when the encoder is receiving silence. Always use the encoder's audio meter and YouTube's preview to confirm sound separately from picture.
The visual also affects your encoder settings. A still image does not require the same video treatment as fast-moving footage. YouTube says it transcodes live streams for viewers, so choose a resolution, frame rate and video bitrate that match the visual content and the upload connection you can sustain. For a station image, stable audio and network headroom matter more than pushing unnecessary video quality.
If you use text for the station name, schedule or song information, make sure it remains legible after YouTube's processing. Keep important text away from the edges and test it in the preview at the size your viewers are likely to use. Do not rely on a browser page that needs your personal account to remain signed in unless you have tested what happens after a restart.
A guide to setting up a YouTube Live stream for guided meditation covers similar decisions about calm visuals and a long-running presentation. The same principle applies to devotional, classical music and local radio channels: give viewers a clear reason to keep the stream open without making the picture harder to maintain than the audio.
Send the encoder output to YouTube Live
First make sure your YouTube channel meets the current live-streaming requirements. YouTube says live streaming requires a verified channel, no live-streaming restrictions in the preceding 90 days, and a minimum age of 16. Check the current YouTube live-streaming eligibility guidance before planning a launch, because platform requirements can change.
In YouTube Studio, create or select the live stream and open the encoder workflow. YouTube will provide a server URL and a stream key. Copy those values into the corresponding fields in your encoder, not into Mixxx. YouTube describes the stream key as similar to a password, so do not publish it in a screenshot, tutorial, chat message or station description.
The broad order is:
- Prepare the YouTube live stream in Studio.
- Copy the current server URL and stream key.
- Paste them into the encoder.
- Add the Mixxx audio input and the visual source.
- Start the encoder.
- Check the Live Control Room preview and stream health.
- Start or confirm the broadcast according to the workflow shown in your YouTube Studio account.
The exact buttons can differ between scheduled streams, reusable stream settings and other YouTube workflows. Follow the instructions currently shown in Studio rather than assuming that starting the encoder automatically makes the broadcast public.
For encoder parameters, use YouTube's current recommended live encoder settings. The page lists RTMP and RTMPS options, supported video codecs, AAC or MP3 audio, constant bitrate encoding and frame-rate guidance. It recommends RTMPS where available. For a typical stereo radio programme, the same page lists 44.1 kHz and 128 kbps as recommended advanced audio settings. These are YouTube encoder recommendations, not a claim that every Mixxx radio-server connection uses the same values.
The settings page also recommends a two-second keyframe interval and says not to exceed four seconds. Use the current YouTube table for the video codec, resolution and bitrate you select. A modest static visual can justify a simpler video configuration than a station showing fast motion, but the encoder still needs to produce a format YouTube accepts.
Keep enough upload capacity for the entire encoded output and other activity on the connection. YouTube's streaming guidance recommends leaving 20 per cent upload-bandwidth headroom. Treat that as platform advice, not as a guarantee that a connection will remain stable. A shared connection, a backup service or a computer performing other uploads can reduce the margin available to the stream.
If the station's main problem is leaving a computer running overnight, an upload-once cloud workflow can remove the need to keep the local Mixxx and encoder session active. StreamNeo is designed for the separate case where you upload a finished video, add the YouTube stream key, and let that video run as a monitored YouTube stream without keeping your computer switched on.
Test the complete audio path
Do not judge the setup by seeing a moving visual in the encoder. Test from Mixxx to the encoder, from the encoder to YouTube, and from YouTube to a viewer device. YouTube's encoder guidance says to test before starting the live stream, including representative audio and motion.
Use a private or unlisted test where that suits your channel. Play the types of material you expect to broadcast: speech over music, quiet passages, louder tracks, jingles and any live microphone input. A test using only one song may hide clipping, silence, excessive compression or a routing problem that appears when the programme changes.
Check these points in order:
- Mixxx is playing the intended source and its master output is moving.
- The chosen capture or loopback input receives Mixxx and no unwanted desktop audio.
- The encoder audio meter responds without persistent clipping.
- The visual source is present and remains stable.
- YouTube's preview contains both sound and picture.
- The stream health indicator remains acceptable while the test runs.
- A separate viewer device can hear the stream at a sensible volume.
Listen for a delay between Mixxx and the YouTube playback. Some delay is normal in a live platform workflow, but a rapidly growing delay, repeated buffering or missing audio points to a connection or encoding issue rather than to Mixxx's song library.
If there is no Mixxx audio in the encoder, check the selected input, operating-system permissions, the routing device and whether Mixxx is actually playing. If the encoder meter moves but YouTube has no preview, recheck the current server URL, stream key, protocol and encoder output settings. If YouTube shows a picture but silence, verify that the encoder's programme mix includes the captured input rather than only the visual source.
If an Icecast connection fails, confirm that the host contains only the hostname or IP address, that the port is in its own field, that a mount is present and that the credentials came from the provider. If a Shoutcast or Icecast server rejects the stream, check its accepted audio format and compare it with Mixxx's configuration.
For longer tests, observe the computer and connection rather than walking away immediately. Heat, sleep settings, operating-system updates, competing uploads and audio-device changes can all affect an unattended setup. A checklist for keeping a YouTube church stream running overnight is also useful for radio operators because the operational risks are similar.
Once the test passes, record the working input names, encoder settings, YouTube workflow and restart order. If you later change the operating system, audio device or encoder version, repeat the test instead of assuming that the old route is unchanged.
Plan for an unattended station
Mixxx and a local encoder can work well for a staffed or closely monitored broadcast, but an always-on station needs an operating plan as well as a technical path. Decide who will notice silence, who can rotate the stream key if it is exposed, and what happens when the internet connection or computer restarts.
Keep the YouTube stream key in a password manager or another restricted location. Avoid placing it in screen recordings, shared notes or public configuration files. If you think it has been exposed, replace it in YouTube Studio and update the encoder.
Write a short recovery procedure. It might say: check Mixxx playback, check the capture input, check the encoder meter, check the network, then inspect YouTube Studio. Include the order in which applications should start. On some systems, the loopback device may not be available until its audio software has started.
If the computer must remain on, disable sleep for the broadcast account and prevent ordinary notifications from entering the captured audio. Consider whether a local setup is still appropriate if the station needs to run while nobody can reach the machine. A comparison of OBS and FFmpeg for a 24/7 study stream explains why the encoder choice affects monitoring and maintenance, even though the audio source here is Mixxx.
YouTube can disconnect a live broadcast, and a local encoder does not automatically make recovery dependable. If you need an automatic restart process, document it and test it during a controlled interruption. The guide to restarting a YouTube 24/7 stream after a disconnect covers that operational problem separately.
Do not assume that a successful first broadcast proves that the station is suitable for unattended operation. Test a complete programme change, a temporary network interruption and a computer restart before making the stream a permanent part of your channel.
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 Mixxx stream directly to YouTube?
Not according to the Mixxx Live Broadcasting documentation. Mixxx documents Shoutcast and Icecast destinations, so you need an encoder to receive the Mixxx audio, add video and send the output to YouTube Live.
How do I get Mixxx audio into OBS?
Use an operating-system-supported audio capture or loopback input, then select that input in OBS and confirm that its meter responds while Mixxx is playing. The exact device and routing steps depend on your operating system, so do not assume that one platform's method applies to another.
What do I enter in YouTube Live?
Enter YouTube's current server URL and stream key in the encoder, not in Mixxx. Keep the key private, then check YouTube Studio's preview and stream health before starting the public broadcast.
Should I use a local capture route or Shoutcast or Icecast?
Local capture usually involves fewer network services, but it depends on reliable operating-system audio routing. A Shoutcast or Icecast route can preserve an independent internet-radio feed, but it adds another service and requires the encoder to support that server's output.