Learn about the recommendations for installing an Internet streaming solution with program delivery, in this case, through Audiocodecs AEQ Phoenix
AEQ
Every day more radio stations broadcast their programs, not only through the radio waves, but also through the Internet and listeners, using an app or a simple browser, can listen to them. The audio generated in the studio must therefore be replicated on the network to all recipients.
AEQ has developed an application guide in this regard, which aims to describe a solution for distributing audio over the Internet using an external replication service provider, to which the audio, already encoded, can be sent using AEQ audiocodecs from the Phoenix family.
Architecture
A cloud replication server is responsible for taking an encoded audio stream and sending it to multiple destinations over the Internet.
The server performing the replication can be offshore, on the Internet, or located on the station's own premises. The advantage of the first alternative is that the station can forget about the maintenance of the machine and does not need to contract an Internet connection with high bandwidth. In addition, the stream is already sent encoded to the "entrypoint" which further reduces the requirements of that connection for "ingest" (audio input to the server that replicates).
In the studio, you will only need a dedicated high-quality audio encoder with different types of input available (analog, digital or even Dante/AES-67). AEQ Phoenix audio encoders have been tested and are compatible with various replication systems thanks to the diversity of encoding algorithms available and the fact that they implement (among others) the standard RTP transmission method.
We have opted to check compatibility with replication servers that support the OPUS family of algorithms.
In particular, the solution offered by the company Cires 21 (C21 Live Radio) has been evaluated. Various levels of service are offered, mainly depending on the number of users that can connect simultaneously and the bitrate of each connection (which determines its quality), although additional features are also offered for each plan.
The quality perceived by users depends both on the encoding towards the ingest, which performs the audio codec and is sent only once (so bandwidth is not an issue here), and on the recoding that is done on the replication server, which will use an adjusted bitrate so as not to use an excessive data rate, as it is multiplied by the number of users. Cires21 offers us the option of using 64kbps or 128kbps, with MP3 encoding.
64 kbps may be enough if voice or a mono signal is sent, but if the stream contains stereo music, it is recommended to sign up for at least 128kbps.
Configuring the Audiocodec
In the case of Cires 21, the ingestion must be carried out according to the standard RTP protocol. To establish an RTP stream, we can use a single-channel Phoenix Mercury audiocodec.
First of all, it is necessary to define the appropriate encoding, e.g. OPUS MUSIC 128kbps stereo. You have to be careful to deactivate the auto-hang due to the absence of RTP, you just have to make the call to the Entrypoint defined by Cires 21.
It is only necessary to indicate the IP address and port through which we will reach the server, which are provided by Cires 21. The status of the equipment will always say CONNECTED_NO_DATA. This is correct because no traffic is received back.
Reception
To listen to the stream, users can have two alternatives:
On the one hand, it is possible to directly use a URL to listen to the stream using a web browser, which will include the appropriate set-top boxes.
On the other hand, it is also possible to use a dedicated player program. In such a case, an address will be used to open the stream. Several examples of these players are VLC, FFplay, VideoJS, or Shaka-Player. In them there is an option to open network location.
The Cires21 demo platform allows you to broadcast up to 6 different streams. Each entrypoint has a different port assigned to it.
Delay
Delays occur in any system of replication of streams over the Internet, due in part to receiving, decoding, buffering, reencoding and distribution through the Internet infrastructure of the streams, but mainly due to the presence of a large buffer in the receiving device
End-to-end delays can be obtained as early as 8 seconds. Using a player like VLC or similar, the buffers are somewhat larger, so delays of up to 30 seconds are common.
This unavoidable delay should be taken into account when choosing such a system, as it could be excessive for e.g. live sports broadcasts, but is of no importance in broadcasts of music radio programmes, talk shows, etc.
Redundancy
Cires 21 offers an optional redundant server service. That is, it can offer two servers that will generate the same streams to the Internet, each with its own encoded audio intake. If one of them fails, streams will automatically be generated with the other, so that the service is not interrupted.
We can have two separate internet accesses in the studio, and use two Phoenix Mercury audiocodecs, each connected to one access. We will introduce the same audio (analog or digital), on both channels. Each will call a different destination specified by Cires 21.
A single Phoenix Venus 4 or Venus4+ can also be used, each channel using a different Ethernet port. In this case, introducing the same audio on both channels is easier if Dante input is used.
Monitoring
Cires 21 offers web access in which, once you have logged in with the credentials provided by them, you can access connection statistics, see the number of connected users, etc.
