A lower-bitrate, audio-only stream can reduce the amount of data sent to listeners, but it does not automatically lower every part of your bill. To find out whether it helps, separate the feed you send into the streaming service from the repeated traffic that service sends to listeners, then compare those costs with the audio quality and device support you need.
For a relaxation station, test the actual music and ambience before changing format, bitrate or channel count. A smaller VPS may not suit a pipeline that must decode and re-encode audio, and a cheaper transfer allowance is no bargain if listener delivery costs more elsewhere.
Map the source feed and listener-delivery legs
An always-on audio service has two distinct traffic legs. First, a source or generator sends one feed to a media server. The server then distributes the stream to each connected listener. Liquidsoap describes this generator-to-server-to-player arrangement in its internet radio toolchain overview.
The source feed continues whether you have no listeners or many. Its rate depends on the encoded stream and any protocol overhead, but the number of listeners does not multiply that single incoming feed. Listener delivery is different: in a typical unicast setup, the server sends a separate stream to each listener, so more listeners and longer listening sessions increase outbound traffic.
That distinction tells you where to look first. If your VPS bill is mostly its fixed monthly charge, reducing the listener stream rate may not change that charge. If outbound transfer is metered or your plan has a small allowance, audio settings can affect the delivery portion. If the stream is relayed through another service, its own billing rules may matter too.
Do not confuse a stream sent to YouTube with a listener radio service. This article concerns direct audio delivery to players, such as a web player, app or compatible device. If your goal is to loop video to YouTube, the feed, encoding requirements and cost model differ; see this guide to transferring playlist videos to a VPS for an FFmpeg YouTube stream.
Identify which service handles each leg
Write down the path from audio file to listener before pricing anything. A simple arrangement might be: audio files on a VPS, a generator that reads and encodes them, a media server that accepts the source feed, then a player on a listener’s device. In some setups the generator and media server share a machine; in others a separate relay or delivery service sits between the origin and the audience.
For every step, identify the billable resource. The VPS may charge a base fee and include some outbound transfer, with additional transfer billed separately. A separate streaming provider may charge for connections, transfer, storage or another unit. A CDN or network partner may have its own terms. The fact that a provider offers a bandwidth discount or includes transfer on one plan does not show that every service from that provider is free to deliver.
Cloudflare’s documentation, for example, describes how charges accrue across its services and says bandwidth is included in its plans in the context covered there; its Bandwidth Alliance page describes partner-specific transfer arrangements. These are reasons to read the terms for the exact service and partner in your route, not assumptions to apply to any audio server.
Draw the route, then mark where each byte enters and leaves a paid service. If a source feed goes from your VPS to a remote media server, that transfer may be billed on the VPS side. Listener delivery may be billed by the media server provider, the VPS, or another delivery layer. Ask each provider what traffic direction its allowance covers and what happens when you exceed it.
Understand what audio-only encoding changes
An audio-only stream does not carry a video track. That can mean less data than a video stream, but the exact result depends on the audio codec, bitrate, channel count and how the original material is processed. It is not a guarantee that your total monthly cost will fall: the fixed VPS fee, listener count, transfer terms and any separate service charges still apply.
Bitrate and channel count are direct encoding controls. A lower bitrate sends fewer audio bits per second, while mono carries one audio channel rather than two for stereo. For relaxation music, stereo may be part of the experience: rain, waves or spatial ambience can sound flatter when collapsed to mono. Try it with representative tracks, not only speech or a short test tone.
Liquidsoap’s encoding formats documentation says MP3 has broad compatibility, while Opus and Vorbis are supported by modern browsers and can offer good quality at lower bitrates. “Modern browsers” does not settle whether your audience’s particular smart speakers, older phones, apps or embedded players can decode them. A format that saves traffic but fails on a listener’s device is not a useful saving.
Liquidsoap’s transcoding cookbook includes a 32 kbps mono MP3 example alongside a 128 kbps MP3 output. Treat those as documentation examples, not a universal bitrate recommendation for music. Compare your current stream with a lower-bitrate version and listen for harshness, swishy cymbals, softened detail or audible compression in quiet passages. Also compare stereo and mono where the content allows it.
Encoding has a cost of its own. Liquidsoap notes that encoding and decoding are CPU-intensive, so changing formats can require more processing even while reducing traffic. Avoid needless conversions: if the source is already in the format you intend to deliver, do not decode and re-encode simply because a sample configuration does so. When conversion is necessary, measure the real pipeline under steady playback and during playlist transitions before choosing a smaller VPS tier.
Check listener-device compatibility
Your intended audience may listen through a browser tab, a phone app, a smart speaker or a radio-style player built into another site. Those clients do not necessarily accept the same codecs, containers or streaming protocols. Check the actual software and devices people use rather than assuming that support in one desktop browser proves support everywhere.
Start with the compatibility-oriented option your current audience already uses, then test any alternative codec on real target devices. Keep the player and stream URL in the test; a codec can be supported in principle but still fail because of how the player handles the stream or its metadata. Confirm that reconnecting works after a device locks, changes network or resumes from sleep if those are normal listening conditions.
If your audience uses a mix of old and new devices, you may decide that one broadly compatible stream is simpler than maintaining multiple outputs. Multiple versions can increase processing and operational complexity, even if one version is more efficient for some listeners. If you do serve separate versions, include each output’s CPU use and delivery traffic in the comparison.
A radio station and a YouTube loop are also different listening paths. If you are using YouTube as the destination rather than serving direct audio players, review the video-loop requirements and the limits of the chosen setup separately. A guide to streaming a college radio station to YouTube around the clock may help clarify that distinction, but it does not replace checking the audio service’s own compatibility.
Estimate traffic with your own assumptions
Use your actual encoded bitrate and expected listening hours to estimate the listener-delivery leg. For a rough first pass, bitrate in bits per second multiplied by listening seconds gives the payload bits; divide by eight to express bytes. Add allowance for container and protocol overhead rather than treating the payload calculation as an invoice prediction. The source-feed leg is calculated separately because it is a single continuing feed, not one copy per listener.
For example, set up a worksheet with the encoded rate you are testing, the number of concurrent listeners you expect, how long they listen, and any overhead assumption you can support from measurements or provider documentation. Do not fill those cells with a generic audience figure. If you have no concurrency history, make clearly labelled low, typical and busy scenarios from your own channel observations, then replace them with measured data after the stream has run.
A simple comparison should keep the assumptions visible:
| Input or charge | What to record | Why it matters |
|---|---|---|
| Encoded audio rate | The rate of the delivered stream you actually tested | Sets the payload per listener-hour |
| Listener use | Concurrent audience and listening duration in your scenarios | Multiplies the repeated delivery leg |
| Source feed | Rate and hours sent to the media server | Continues even when nobody is listening |
| Transfer allowance | Included amount and applicable overage terms | Determines whether estimated traffic changes the bill |
| Processing | CPU use during steady playback and transitions | May constrain how small a VPS can be |
| Delivery route | Each provider between source and player | Shows where transfer and separate service charges arise |
This model is deliberately not a single traffic total. A figure without an assumed bitrate, listener-hours, overhead and billing boundary can mislead you. Once you have those inputs, compare estimated transfer with the exact included allowance and overage rules for your current plans. Keep geography in view too: delivery from one origin to listeners far away may affect the service choice or route, but do not assume a particular provider’s geographic pricing without checking its terms.
Review VPS and delivery costs separately
Separate the fixed VPS price from transfer and from any additional delivery service. A machine with a lower monthly sticker price can cost more overall if its included egress is smaller or overage is dearer. Conversely, a plan with more transfer included may not be worthwhile if your measured listener traffic remains low. Compare the total for your own scenarios, not a provider headline.
Check CPU and memory as operational constraints, not just line items. If the VPS reads files, mixes tracks, resamples and encodes, it performs more work than a server that relays an already prepared stream. Encoding and decoding can be CPU-heavy; reducing the server size before measuring the complete chain can lead to missed audio, unstable playback or the need to move back to a larger plan. No universal CPU figure or VPS size follows from the example configurations.
Also account for recovery. A 24/7 channel needs a plan for what happens if the process exits, the host restarts or the network drops. Automatic restart and monitoring may be part of your software setup or a managed service; either way, include the time and cost of maintaining it. A lower bill is not a saving if you have to spend each night repairing a stream.
Compare providers using the same assumptions: source location, listener geography, likely listener-hours, transfer allowance, overage, CPU requirements and recovery needs. Check current official plan pages before buying because prices and terms change. Cloudflare Stream is a useful caution against comparing superficially similar labels: its pricing page describes video delivery billed by minutes, with bandwidth included for video delivery. That page is not evidence that the product is a suitable or cheaper replacement for an audio-only radio service.
If the recurring pain is having to leave your own computer running or restart a failed broadcast manually, StreamNeo removes that particular task for a YouTube stream by letting you upload a video file and run the broadcast with your computer switched off. It is YouTube-only, so it is not an audio radio delivery service and does not answer the separate question of serving audio listeners directly.
Test playback before changing the setup
Make one change at a time. Save the current encoder and player settings, then make a test version with a different bitrate, channel count or codec. If you change several things together, a failure or quality change is harder to diagnose. Test the passages that matter: quiet introductions, long sustained tones, rain or water textures, and any music with cymbals or wide stereo movement.
Listen on headphones and speakers, but also check the devices your audience actually uses. Confirm that playback starts, continues, reconnects and recovers after a player is interrupted. Listen long enough to notice whether a stream sounds tiring or loses detail. A short successful start only shows that the format can begin playing; it does not establish that the complete overnight workflow is dependable.
Measure the encoder’s CPU during the normal loop and during transitions, especially if files differ in format or sample rate. Watch for clipping, silence, skipped sections, failed reconnects and log errors. Then compare the delivery rate and provider traffic counters where available. Counters may include overhead or other workloads, so reconcile them with your usage assumptions rather than treating them as a pure audio measurement.
Keep the old setup available until the new one has passed a meaningful test period for your use. If compatibility is mixed, keep the old output for listeners who need it or choose the broadly supported format. If the proposed change saves listener traffic but raises CPU use or requires another service, revisit the full monthly comparison. You are looking for a workable balance, not the lowest bitrate in isolation.
For another 24/7 operational perspective, see the guide to choosing an affordable Indian VPS for a YouTube playlist stream. Its context is a YouTube playlist, so use it to frame questions about VPS allowances and recovery rather than as a direct audio radio price comparison.
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
Will audio-only encoding always lower my VPS bill?
No. It can reduce the amount of data delivered to listeners, but your VPS base fee may stay the same, and processing or separate delivery charges can affect the total. Check which part of your current bill is tied to outbound traffic before changing settings.
What bitrate should I use for a relaxation stream?
There is no universal rate that preserves the quality of every music and ambience library across all devices. Test a lower rate against your current stream, listen to representative material and verify that the codec works for your actual players. Liquidsoap’s documented 32 kbps mono MP3 is an example configuration, not a general recommendation.
Does mono make sense for ambient music?
It may lower the amount of audio sent, but it also removes stereo separation. If listeners rely on wide rain, water or instrumental textures, compare the mono and stereo versions on ordinary listening equipment before deciding.
Can I move to a smaller VPS after changing the codec?
Only after measuring the real processing workload. Encoding and decoding consume CPU, so a lower-bitrate output does not by itself prove that a smaller machine can handle your generator, transitions and recovery needs. Test first and keep a way to restore the previous setup.