[Icecast] Using freeswitch and Icecast

[TheDarkener]

All of that being said, using ogg/opus seems like it should be more
geared toward what you're trying to do - though what everyone above has
said still stands, regardless of codec.


On 08/07/2013 12:06 AM, "Thomas B. Rücker" wrote:
> 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
>
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast

-- 
Jordan (PGP: 0xDA470FF8)