[Icecast] Using freeswitch and Icecast

["Thomas B. Rücker"]

what-he-said

On 08/07/2013 06:48 AM, Basil Mohamed Gohar wrote:
> On 08/06/2013 07:40 PM, Jorge Núñez wrote:
>> Hi I am trying to use icecast to broadcast a realtime conference from
>> freeswitch. But I am having a delay like 20 seconds then I reduced it to
>> 12s. But I don't know if somebody can help me how to reduce it as lower
>> as possible.
>>
>> Thanks
>>
>> Jorge
> Jorge, first I'd like to know what you did to reduce the delay from 20
> to 12 seconds.
>
> Secondly, the delay can also be related to the following two issues:
>
> 1. The audio codec being used
> 2. The amount of buffering on the client side
>
> Using Ogg Vorbis for the audio, for example, will incur some delay, but
> that wouldn't explain 12 seconds.  More than likely, a good portion of
> the delay is related to buffering on the client side.
>
> VLC media player allows you to set the buffering on the client side, you
> may consider trying that and experimenting with different settings to
> see how little delay you can get by reducing buffering.  But keep in
> mind, a smaller buffer exposes your client to more network-related
> transmission errors, which may result in Icecast dropping your client
> altogether or the sound coming through with stuttering.
>
> The fact of the matter is that while Icecast can be used for
> broadcasting live audio, it's a very simple protocol that does not have
> any mechanism to ensure that all clients are receiving the audio at the
> same time.  The audio is being broadcast as basically an HTTP download
> without a Content-Length header.  It's up to the client (i.e.,
> application) to present it to the user with or without delay, depending
> on configuration as I mentioned above.

In addition, why would you require the broadcast to be as low latency as
the conversation itself?
Even professional broadcasting will have a delay of anywhere between a
couple hundred miliseconds and several seconds.

If you need real time interaction or want to have people dial in, then
those people should use the VoIP bidirectional channel and not the
broadcast. That's how call-in shows on the radio do it too.

Also while you can get the latency into the 1-2s range with Icecast,
this will come at the cost of stability and increased configuration
complexity across the whole chain, including the listener (especially
the listener side software, as those tend to have the largest buffers).
Icecast is simply not a low latency solution, let alone real-time. If
you are looking for sub-second latency, Icecast is the wrong tool or you
need to accommodate how broadcasting works in your workflow.

Cheers

Thomas