AEQ Phoenix allows streaming with program sending

AEQ has a solution to distribute audio over the Internet using an external replication service provider, to which the audio can be sent, already encoded, using the Phoenix family audiocodec.

A cloud replication server is responsible for taking an encoded audio stream and sending it to multiple destinations over the Internet. The server that performs the replication can be outside, on the Internet, or located in the station's own facilities. The advantage of the first alternative is that the station can forget about the maintenance of said 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 said connection for the “ingestion” (audio input to the replicating server).

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). The audio encoders AEQ Phoenix have been tested and are compatible with various replication systems thanks to the diversity of coding algorithms available and because they implement (among others) the method of standard RTP transmission.

This solution has been tested alongside replication servers that support OPUS algorithm family like those offered by the Spanish company Cherry 21 (C21 Live Radio). This proposal offers several levels of service, depending mainly on the number of users that 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 users depends both on the encoding towards the ingest, which is carried out by the audio codec and sent only once (so bandwidth here is not a problem), and on the re-encoding that is done on the replication server, which will use an adjusted bitrate to not use an excessive data rate, since it is multiplied by the number of users. Cires21 offers us the option of using 64kbps or 128kbps, with MP3 encoding.

It should be noted that 64 kbps may be sufficient if you are sending voice or a mono signal, but if the transmission contains stereo music, it is recommended to contract at least 128 kbps.

Audiocodec settings

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 must be careful to deactivate auto-hangup 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 return traffic is received.

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 decoders. On the other hand, it is also possible to use a dedicated player program. In this 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 Cires 21 demo platform allows you to broadcast up to 6 different streams. Each entrypoint has a different assigned port.

Retardation

In any stream replication system over the Internet, delays occur, due in part to the reception, decoding, buffering, recoding and distribution of the streams through the Internet infrastructure, but above all to the presence of a large buffer on the receiving device.

They can be obtained end-to-end delays starting at 8 seconds. Using a player like VLC or similar, the buffers are somewhat larger, so delays of up to 30 seconds are common.

This inevitable delay must be taken into account when choosing a system of this type, since it could be excessive for, for example, live sports broadcasts, but it is not of any importance in broadcasts of music radio programs, social gatherings...

Redundancy

Cires 21 offers a 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 one will call a different destination specified by Cires 21.

You can also use a single Phoenix Venus 4 or Venus4+, each channel using a different Ethernet port. In this case, inputting the same audio into both channels is easier if you use Dante input.
Monitoring

Cires 21 offers Web access in which, once logged in with the credentials provided by them, we can have access to connection statistics, see the number of connected users...