More and more radio stations everyday broadcast their programs not only through radio waves but also by means of internet, and listeners are able to listen to them using an application or a simple Internet browser. The studio-generated audio must be consequently replicated in the network towards all the receivers.
This Application note intends to describe a solution to distribute audio through the Internet using an external replication service provider, where the audio program can be sent to, already encoded, using AEQ phoenix audio codecs.
Architecture
A cloud-based replication service takes an encoded audio stream and sends it to multiple destinations through the Internet.
The advantage of the second alternative is that the station doesn’t need to take care of the maintenance of the machine, and it doesn’t need to hire a large Internet connection with a lot of bandwidth. Besides, the stream is sent already encoded to the server’s “entry point”, further reducing the requirements of that connection for the stream feed (audio input to the replication server).At the studio, only a dedicated high-quality audio encoder is required, which could desirably have different kinds of available inputs (analogue, digital or even Dante/AES-67). AEQ Phoenix codecs have been tested with several replication services thanks to the wide variety of encoding algorithms they offer and because they implement the RTP transmission standard, among other modes.
That’s why we have placed a bet on testing compatibility with replication servers which support the OPUS family of encoding algorithms.
In particular, the solution offered by the company Cires 21 (C21 Live Radio), which supports OPUS ingests, has been evaluated. Various levels of service are offered, depending mainly on the number of users who can connect simultaneously and the bitrate of each connection (which determines its quality), although additional functions are also offered for each plan.
The quality perceived by the users depends both on the encoding of the audio feed (which the audio codec performs and is sent once, so the bandwidth requirements are not an issue here) and the re-encoding performed by the replication server, which will use a moderate bitrate so the total data amount is not excessive, as it needs to be multiplied by the number of listeners. For compatibility reasons, Cires 21 offers the option of using MP3 as the final encoding algorithm, with 64 or 128 kbps.
64 kbps can be more than enough if voice only or a mono signal is sent, but if we intend to transmit stereo music, our recommendation is to use at least 128 kbps.
Audiocodec Configuration
When working with Cires21, the stream input must be sent according to RTP Standard. In order to stablish an RTP stream, we can use a single-channel Phoenix Mercury audiocodec.
First, we need to define the proper encoding algorithm required to feed the server, for example: OPUS MUSIC 128kbps stereo.
We need to be aware that the auto-hang-up option (when RTP input is lost) must be de-activated in the codec
We only need to make the call to the entry point defined by Cires 21. Only the server IP address and port need to be specified, and these values are provided by Cires 21.
The codec channel status will always be CONNECTED_NO_DATA. This is correct, as no return traffic is received from the server.
Receiving the stream
In order to listen to the stream, users have two alternatives:
On one hand, it is possible to directly use a URL in order to listen to the stream using a Web browser (which must include the proper codecs).
On the other hand, it is also possible to use a compatible player application. In this case, an address is used to open the stream. Some examples of these players are VLC, FFplay, VideoJS or Shaka-Player. In all of them, an option is available to open a network location.
Cires21 demonstration platform allows us to send up to 6 different streams. Each entry point has a different port assigned.
Delay
Every internet-based stream replication system introduces significant delays. This delay is contributed by reception in the server, decoding, buffering, re-encoding and distribution through all the Internet backbone, but, mainly, by the required large buffers in the receiving end.
Using an internet browser, end-to-end delays starting in 8 seconds can be obtained. VLC players or similar tend to use larger buffers so delays up to 30 seconds are usual.
This unavoidable delay must be had into account when selecting a system of this kind, as it could be excessive for certain program types such as live sports transmissions, while it is not important for music or chats broadcasting.
Redundancy
Cires 21 offers an optional redundant-servers service. That is, two servers are offered which will create the same streams to the Internet, each one with its own encoded audio inlet. If one of them fails, the streams will automatically be generated by the other one, so the service is not interrupted. This transition is, however, not seamless.
We can have two separate internet accesses in the studio, and use two Phoenix Mercury audiocodecs, each one connected to an ISP. We must input the same audio source to both of them (in analogue or digital format). Each one will call to a different destination address, as specified by Cires 21.
This can also be implemented using a single Phoenix Venus 4 or Venus4+, each channel using a different Ethernet port to each ISP provider. In this case, feeding the same audio signal to both channels is required (which is particularly easy when using Dante input).
Monitoring
Cires 21 offers a web access where, once logged in using the credentials provided by them, we can have access to connection statistics, check the number of connected users, etc.
Read the full application note here.
Info: www.aeq.eu & CALPRO *
* Distributor for Hellas
Notes: Press Relase - AEQ - 07/12/2023
