To run separate Hindi and Punjabi music streams on one VPS, use one Icecast server with two mountpoints and configure Liquidsoap to send an independent playlist to each. Listeners choose the Hindi or Punjabi mountpoint URL; this setup creates two audio feeds, not two YouTube livestreams.
The playlists, output settings and listener paths stay distinct, but the VPS and its network connection are shared. You need to size and monitor them for the combined work, and confirm that you have the rights needed for the recordings you broadcast.
Choose one server and two mountpoints
Icecast is the server listeners connect to. Each stream has its own mountpoint, such as /hindi and /punjabi, even though both are handled by the same Icecast installation. Liquidsoap reads the relevant audio and sends each playlist to its assigned mountpoint. The Icecast Project explains how one server can house multiple streams as mountpoints.
Think of the arrangement as two separate audio paths sharing one host: Hindi playlist → Liquidsoap Hindi source → Icecast /hindi, and Punjabi playlist → Liquidsoap Punjabi source → Icecast /punjabi. A listener opening one path receives that feed. A mountpoint is not a YouTube channel or a YouTube livestream. If YouTube distribution is your goal, it requires a separate broadcast workflow and the relevant YouTube channel setup.
One VPS can be a practical starting point if both feeds are modest and listener demand is manageable, but it does not have unlimited capacity. Audio processing, the two outgoing feeds, concurrent listeners, storage and other workloads all use finite resources. The research behind this setup does not establish a particular VPS size or listener ceiling, so do not choose a plan based on an assumed audience benchmark.
Before installing software, decide whether you want the channels to use the same audio format and bitrate. Matching settings simplify administration; different settings may suit distinct player compatibility or quality needs, but complicate testing and capacity planning. You can run one Liquidsoap instance with two feeds, or maintain separate instances if isolation and operational boundaries matter more to you. Either way, keep the configuration for each channel explicit.
Install Icecast and secure its configuration
Install Icecast and Liquidsoap using packages intended for your VPS operating system. The documentation cited here explains the configuration concepts, not current commands for every distribution. Check the package and service instructions for the operating system you actually use rather than copying commands from a different release.
Configure Icecast's listening address and port, then replace the default source and administrator passwords before exposing it to the public internet. A source password is what a broadcaster uses to connect and publish a feed; administrative credentials control the server's management interface. Leaving defaults in place can let unauthorised users publish or change settings, a risk called out in the Liquidsoap Quickstart.
Keep credentials private and use different passwords where practical. Restrict administrative access according to the controls available on your host, and avoid including secrets in examples that you share publicly. If several people help operate the streams, agree who can change playlists and restart services before launch.
Icecast's configuration can apply settings globally or for a particular mountpoint. Start with the simplest configuration that meets your needs; add mount-specific rules only when you understand what differs between feeds. If you configure a fallback mount for a source interruption, verify that its format matches the stream it is meant to replace. A fallback may help with a source failure, but it cannot keep a VPS or network connection running through an outage.
Prepare two independent music playlists
Separate the files before configuring Liquidsoap. For example, put Hindi recordings in one directory and Punjabi recordings in another, or use two playlist files whose entries point to the appropriate audio. The important part is not the folder name: it is that each source reads only the intended collection, unless you deliberately choose to share selected tracks.
Check the files themselves before leaving a channel unattended. Confirm that they open, have a compatible format, and do not contain long silences or broken entries that interrupt playback. If the player uses metadata, inspect how titles and artist names appear; inconsistent tags can make a stream look untidy even when the audio plays correctly. Make sure that the order and rotation suit the channel rather than relying on a single test track.
Playlist independence gives you editorial control. You can change the Hindi rotation without changing Punjabi, and investigate a bad file in one collection without assuming the other is affected. Keep copies of the playlists and note any changes made during maintenance so that a restart does not silently revert the schedule.
Technical separation does not grant permission to broadcast a recording. Rights can depend on the recording, repertoire, territory and how you operate the service. Confirm requirements with the relevant rights holders or licensing bodies for the places where you intend to reach listeners. Neither Icecast nor Liquidsoap establishes that a particular music library is cleared for a particular use.
If your longer-term plan is a YouTube channel built around repeatable content, the practical concerns differ from an audio mountpoint. For example, our guide to keeping a 24/7 YouTube live stream supplied with fresh content discusses continuity on that platform rather than configuring Icecast.
Define two Liquidsoap sources
Liquidsoap provides playlist sources and can send their audio to Icecast. Its Quickstart demonstrates playlist sources and notes that one instance can handle more than one audio feed. Treat each language as its own source in the configuration: a Hindi playlist source and a Punjabi playlist source. Give each a clear name so that logs and later edits are easier to interpret.
A source's job is to provide audio; an output's job is to encode and deliver it. Keeping those roles in mind makes troubleshooting less confusing. If the Hindi mountpoint goes quiet, first establish whether the Hindi source is still playing, then check its output connection. Do not assume a working Punjabi feed proves the Hindi path is healthy.
The outline below is conceptual, not a paste-ready script. Liquidsoap syntax and available functions can vary by installed version, so check the documentation for that version before deploying. In broad terms, define a playlist source from the Hindi playlist, define another from the Punjabi playlist, then attach a separate Icecast output to each. The Liquidsoap documentation on streaming to Icecast describes output configuration and multiple feeds; because that page is development documentation, verify syntax against your installed release.
You can wrap a fallible playlist source with mksafe where appropriate, as shown in Liquidsoap's documentation, to provide safer behaviour if the source has a problem. That is one recovery measure, not a guarantee of continuous audio: it does not repair a missing file, a stopped process, a failed host or a lost network connection. Decide what listeners should hear when a playlist runs out or an input fails, then test that behaviour deliberately.
Connect each source to its own mountpoint
For each Icecast output, set the host, port, source credentials, encoding and mountpoint. The Hindi output should publish to /hindi, and the Punjabi output to /punjabi. Do not point both outputs at the same path if you want listeners to select between independent feeds.
Use simple paths without spaces or unusual characters. Follow Icecast's naming and format conventions for the codec and players you expect to support; some formats use an extension in the mount name. The output format and bitrate are choices to make for the audience and network, not numbers to guess from an unrelated guide. The Liquidsoap Icecast output documentation is useful for understanding the settings, but check its version context before reusing configuration examples.
A practical comparison is about administration and capacity, not a promise of performance:
| Choice | What it simplifies | What to consider |
|---|---|---|
| Same format and bitrate on both outputs | Consistent player support and easier configuration review | The streams remain separate, but listener traffic still accumulates across both |
| Different format or bitrate per output | Lets you tailor each feed to its listeners | You must test each path and account for the different traffic each can generate |
| One Liquidsoap instance with two outputs | One process and configuration to supervise | A process-level problem may affect both feeds |
| Separate Liquidsoap instances | Clearer process separation | More services, logs and restart behaviour to maintain |
When estimating bandwidth, consider the encoded bitrate of each output and the time listeners spend connected. Bits must be converted to bytes for data-transfer estimates, and protocol overhead also consumes capacity. Most importantly, count concurrent listeners on both paths, not just one. Liquidsoap's Quickstart makes the qualitative point that more listeners require more bandwidth; it does not establish a universal VPS size or a safe audience limit.
Test both listener URLs independently
Once both sources and outputs are running, test from outside the VPS. A typical listener URL is the host name or public IP, Icecast port and mountpoint path, for example http://your-host:port/hindi or http://your-host:port/punjabi. Substitute the actual host and port you configured. Icecast also describes playlist links such as .m3u for compatible players; test the URL format your audience will use.
Listen to each URL separately in a player that supports the selected format. Confirm that Hindi plays from the Hindi path and Punjabi from the Punjabi path. Check that metadata is sensible, playback is continuous during the test, and the player behaves as expected when you stop and restart the corresponding source. Do not test only from the VPS itself: a local connection can work while the public address, firewall or routing is wrong.
Use a short checklist for each feed: correct language and playlist, expected format, stable audio, visible listener connection, and useful response after a source interruption. If one mount works and the other fails, check that output's mount name, credentials and source status independently. Avoid changing both outputs at once during diagnosis, since that makes it harder to identify which change mattered.
An Icecast listener URL is for the audio service. It does not become a YouTube live destination merely because it is continuously available. If you are preparing a separate YouTube stream and need to plan its picture and encoding, the 24/7 YouTube encoder settings guide covers a different distribution setup.
Monitor the host and both outputs
A two-mountpoint design shares a host, so watch the shared resources as well as each feed. Check CPU and memory use, disk availability, network traffic and the service logs under normal listening conditions. Observe both outputs when listeners connect to both, because a quiet period on one mount can conceal a capacity problem that appears when audiences grow.
There is no documented VPS sizing benchmark in the sources for this article. Choose hosting based on measured use and the support you need, then leave room for ordinary variation rather than assuming the first test represents the busiest period. If traffic approaches the limits of your plan or the host becomes unstable, investigate the cause and consider a larger or different operating arrangement. Two mountpoints do not remove capacity constraints.
Plan who or what will notice a stopped process and what happens next. A service manager can be configured to restart processes, and monitoring can alert you when a process or mountpoint is unavailable; you still need to test those arrangements. Liquidsoap source safety and Icecast fallback mounts address particular source-level cases, not every point of failure. A 24/7 goal requires attention to the host, network, process recovery, files and monitoring together, without treating any one feature as an uptime guarantee.
Keep a small operating record: when each service started, whether both mounts were reachable, what changed, and any recurring errors. This helps distinguish a playlist issue from a network interruption or a resource problem. If you also run other continuous channels, compare the maintenance burden with approaches described in continuous OBS playlist setup; OBS is a different workflow and does not replace the Icecast design here.
For an audio-only Icecast pair, you remain responsible for the VPS, Liquidsoap configuration, monitoring and recovery. If the actual objective is a YouTube broadcast from an uploaded video, rather than listener-selectable audio mountpoints, StreamNeo removes the need to leave your own computer running by turning an uploaded video into a YouTube live stream, with the broadcast monitored and restarted if it drops. It is YouTube-only and does not configure or host these Icecast feeds.
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
Do two Icecast mountpoints make two YouTube channels?
No. They are two audio paths served by Icecast, and listeners open the path they want. YouTube channels and livestreams are separate platform objects with their own setup; the mountpoint design does not create or publish them.
Can one Liquidsoap instance send both feeds?
Yes. Liquidsoap documentation describes one instance streaming multiple audio feeds. Keep a separate playlist source and Icecast output for each language, and check the syntax for the version you have installed.
What happens if one playlist or source stops?
The other source and mountpoint can be configured independently, but you should test that assumption in your setup. Liquidsoap safety wrappers and Icecast fallback mounts can help with specific source failures when configured compatibly; neither prevents host, network or process outages.
How many listeners can one VPS support?
There is no universal figure supported by the documentation here. It depends on output bitrates, concurrent listeners on both mountpoints, host and network capacity, and other workloads, so measure your own use and plan accordingly.