Icecast - Aug 2004 - Configuring icecast for lowest buffering/latency

Hi:

Icecast, at least the release version, doesnt' employ much if anything in
the way of buffering.  My understanding is that the development code has
some code to prebuffer and burst on connect, but my understanding is that
this isn't the default configuration.

The only sources of latancy will be from the streaming source (i.e.
simplecast in your case), and the HTTP client.  The client is likely to be
the greatest cause of latency.  Check to see if it has any buffer settings.

Geoff.

--- >8 ----
List archives:  http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to
'icecast-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

On Tuesday 23 March 2004 23:13, Matt Trim wrote:
> Hi,
>
> I'm using Icecast on a windows pc as a "gobetween" to output
from a
> streaming encoder, bounce it of an icecast server locally on the
> workstation and then being picked up from the local icecast server and
> relayed on again. (I'm using liveCaster from www.live.com as it allows
me
> to send the audio stream as UDP which is more efficient than HTTP streaming
> - unfortunately it does not accept audio directly from the windows app
> [Simplecast], but reads an http stream, which is why I need icecast in the
> middle as the glue to hold it together!)
>
> How can I configure the Icecast server to use as minimum buffering as
> possible so I can reduce the latency that the http streaming on the local
> box introduces?
Icecast always has minimal buffering.
>
> Is it as simple as setting <queue-size> to something very small like
1024
> or would I need a customer recompile of icecast server to set all the
> buffers to minimum settings?
queue-size adjusts the maximum queue size. icecast will always attempt to keep 
the queues empty or as close as possible.

The only thing you could consider modifying is the two uses of '4096' in
src/source.c:source_main(). Even there, however, I'd be surprised if you see
a significant change in overall latency.

Mike

--- >8 ----
List archives:  http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to
'icecast-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

Hi,

I'm using Icecast on a windows pc as a "gobetween" to output from
a
streaming encoder, bounce it of an icecast server locally on the workstation
and then being picked up from the local icecast server and relayed on again.
(I'm using liveCaster from www.live.com as it allows me to send the audio
stream as UDP which is more efficient than HTTP streaming - unfortunately it
does not accept audio directly from the windows app [Simplecast], but reads
an http stream, which is why I need icecast in the middle as the glue to
hold it together!)

How can I configure the Icecast server to use as minimum buffering as
possible so I can reduce the latency that the http streaming on the local
box introduces?

Is it as simple as setting <queue-size> to something very small like 1024
or
would I need a customer recompile of icecast server to set all the buffers
to minimum settings?

Cheers,

Matt

--- >8 ----
List archives:  http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to
'icecast-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

> How can I configure the Icecast server to use as minimum buffering as
> possible so I can reduce the latency that the http streaming on the local
> box introduces?
as far as I know, icecast and liveice have the smallest influence on the
delay in that chain. The biggest delay is produced by the client player's
buffer. Have your checked this out?

Why do you need such a low latency?

Why do you consider livecaster's stream being more efficient than the
HTTP-Stream? Actually, after the HTTP-Header there are just raw MP3-Data. In
comparision to that, livecaster puts these MP3-Data into an RTP-protokoll,
which produces more overhead than 'raw' http. And you may be faced
random
packet loss.

Or do you mean the network load being more efficient?

<p>Greets,
Enrico

--- >8 ----
List archives:  http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to
'icecast-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

On Wednesday 24 March 2004 03:53, Enrico Minack wrote:
> Why do you consider livecaster's stream being more efficient than the
> HTTP-Stream? Actually, after the HTTP-Header there are just raw MP3-Data.
> In comparision to that, livecaster puts these MP3-Data into an
> RTP-protokoll, which produces more overhead than 'raw' http. And
you may be
> faced random packet loss.
The original poster is correct. HTTP is very inefficient compared to RTP. 
There is no way in which RTP produces more overhead than HTTP - if you think 
it does, you don't understand the protocols. 

There are, of course, reasons to pick either protocol. RTP is more efficient 
(and can be used in multicast networks!), but you do have to be able to 
tolerate some packet loss. HTTP is much less efficient (and will generally 
have higher latency) but will correct for packet loss, and you also often 
have advantages with ease-of-use with things like getting through firewalls. 
Icecast is not a solution for all problems - only some :-)

Mike

--- >8 ----
List archives:  http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to
'icecast-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.