[Icecast] Icecast Digest, Vol 111, Issue 5

Wed Aug 14 15:56:14 UTC 2013

Thanks for your answer, well I changed this parameters on icecast.xml and
the the delay reduce from 20s to 12s

        <burst-on-connect>0</burst-on-connect>
        <burst-size>4096</burst-size>

Well I was trying to reproduce mp3 and ogg but both have 12 s of delay. How
can I reduce to maybe 1 or 2 seconds.

2013/8/7 <icecast-request at xiph.org>

> Send Icecast mailing list submissions to
>         icecast at xiph.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://lists.xiph.org/mailman/listinfo/icecast
> or, via email, send a message with subject or body 'help' to
>         icecast-request at xiph.org
>
> You can reach the person managing the list at
>         icecast-owner at xiph.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Icecast digest..."
>
>
> Today's Topics:
>
>    1. Using freeswitch and Icecast (Jorge N??ez)
>    2. Re: Using freeswitch and Icecast (Basil Mohamed Gohar)
>    3. Re: Using freeswitch and Icecast (Thomas B. R?cker)
>    4. Re: Using freeswitch and Icecast (TheDarkener)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 6 Aug 2013 18:40:52 -0500
> From: Jorge N??ez <jorgefren12 at gmail.com>
> Subject: [Icecast] Using freeswitch and Icecast
> To: icecast at xiph.org
> Message-ID:
>         <CAOP4xcztX5h4kJ-ftxYfaK=
> HQgqbPMQgy4FKZbc-VXBqHVTrUA at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> 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
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.xiph.org/pipermail/icecast/attachments/20130806/619a6b24/attachment.html
>
> ------------------------------
>
> Message: 2
> Date: Wed, 07 Aug 2013 02:48:16 -0400
> From: Basil Mohamed Gohar <basilgohar at librevideo.org>
> Subject: Re: [Icecast] Using freeswitch and Icecast
> To: icecast at xiph.org
> Message-ID: <5201EDB0.9060301 at librevideo.org>
> Content-Type: text/plain; charset=ISO-8859-1
>
> 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.
>
> --
> Libre Video
> http://librevideo.org
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 07 Aug 2013 07:06:23 +0000
> From: "Thomas B. R?cker" <thomas at ruecker.fi>
> Subject: Re: [Icecast] Using freeswitch and Icecast
> To: icecast at xiph.org
> Message-ID: <5201F1EF.5030204 at ruecker.fi>
> Content-Type: text/plain; charset=ISO-8859-1
>
> 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
>
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 07 Aug 2013 09:06:00 -0700
> From: TheDarkener <thedarkener at logicalnetworking.net>
> Subject: Re: [Icecast] Using freeswitch and Icecast
> To: Icecast at xiph.org
> Message-ID: <52027068.7070802 at logicalnetworking.net>
> Content-Type: text/plain; charset=ISO-8859-1
>
> 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)
>
>
>
> ------------------------------
>
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
>
>
> End of Icecast Digest, Vol 111, Issue 5
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20130814/d1e240bd/attachment.htm>