Resource usage of Centova Cast streams

Question:

How resource-intensive is Centova Cast?

Answer:

Centova Cast is simply a control panel for SHOUTcast DNAS or IceCast, and thus it consumes very little (practically negligible) system resources itself because it does not actually serve your radio stations itself. The actual streaming is handled by third-party software: SHOUTcast DNAS or IceCast for the server, and typically ices or sc_trans for the source, or "autoDJ".

It is these third-party applications (not Centova Cast itself) which will primarily contribute to the use of resources on your server, and these are described below.

Streaming Servers

System Requirements

The SHOUTcast DNAS documentation advertises its system requirements as being very modest:

  • 90Mhz or faster server
  • 14kB of memory for every listener you want to broadcast to (i.e. 1,000 listeners means you need 14 Megabytes of RAM), plus whatever your operating system needs for overhead, plus 1.5MB for the server's base requirements.

IceCast does not publish specific a specific set of minimum system requirements, but its resource usage will be similar to that of SHOUTcast DNAS.

The only other major requirement is bandwidth -- streaming radio involves a very significant amount of data transfer. The exact amount varies depending on the bitrate of each of your streams, the number of listeners tuned in to your streams, and the number of streams you host. The formula to calculate your maximum potential bandwidth consumption per stream is:

bandwidth-required = stream-bitrate-in-kbps x maximum-listeners

So for example, if you have a 128kbps stream with a 100 listener limit, you'll need 128 x 100 = 12800kbps = 12.8Mbps of bandwidth for this stream.

Summary

The server portion of the stream requires very little CPU time and memory. Virtually any modern server's CPU and memory capacity will be more than sufficient for hosting many streams, and you will likely encounter bandwidth limitations long before your streaming servers cause CPU load or memory exhaustion issues on your machine.

If you plan to use autoDJs, however, that's a different scenario altogether, and you should read the following section.

Streaming Sources / autoDJs

What is a streaming source?

A streaming source is a software program that feeds music to a streaming server. The streaming source is to Internet radio what the DJ studio is to terrestrial radio -- it takes the actual music and sends it to the server for broadcasting to listeners.

Client-Side ("Live") Sources

In many cases, the DJ will run his source software on his own personal computer. This allows him to do live broadcasts, realtime mixing, and so-on.

When a client-side, or "live" source is being used, no additional resources will be required on your server. This is the most efficient way to host a stream.

Server-Side Sources, or "autoDJs"

It's also possible to allow the DJ to upload his MP3 music directly to the server. In this case, a streaming source program on the server (sometimes referred to as an "Auto-DJ") reads the MP3 files and sends the music to SHOUTcast/IceCast automatically.

Streaming source software is particularly CPU-intensive, and thus using auto- DJ functionality on the server may cause your server's CPU usage to rise dramatically. No formal benchmarks are offered by streaming source software vendors to estimate capacity, but on older servers a single autoDJ can use up to 50% of the machine's CPU resources.

As a result, you may only be able to place a few autoDJ-enabled streams on a single machine. Many SHOUTcast hosts disable autoDJ functionality to avoid this bottleneck.

It is also possible (although often impractical) to use autoDJ functionality without the additional CPU requirements. If you do not require transcoding and/or crossfading effects -- i.e., if your DJs' MP3s have been pre-encoded at the correct bit rate and sample rate, which is unlikely -- it is possible to disable re-encoding to reduce the autoDJ's CPU usage to practically zero. More information about re-encoding is available in the following article:

Enabling/disabling server-side media re-encoding