Icecast dev - Jan 2008 - Question about buffering with icecast protocol

Hi,

 

I?ve seen that shoutCAST sends data much faster than real time when you
connect (for a while I assume, otherwise you?d be travelling to the
future:). That?s useful for fast buffering.

 

With icecast I don?t get that behavior, stream downloads at real time. Is
there a way to buffer data faster than real time? Maybe a ?seek? feature? I
need that because I need to allocate a special large buffer for an app.
Thanks!

 

Regards

            Damian

 

 


No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.516 / Virus Database: 269.19.1/1220 - Release Date: 1/11/2008
6:09 PM
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/icecast-dev/attachments/20080114/38089b18/attachment.html

Dami?n Lezama wrote:
> 
> 
> Hi,
> 
>  
> 
> I?ve seen that shoutCAST sends data much faster than real time when you 
> connect (for a while I assume, otherwise you?d be travelling to the 
> future:). That?s useful for fast buffering.
> 
>  
> 
> With icecast I don?t get that behavior, stream downloads at real time. 
> Is there a way to buffer data faster than real time? Maybe a ?seek? 
> feature? I need that because I need to allocate a special large buffer 
> for an app. Thanks!
Look at the burst-size option. The default is 64kbytes which is fine for 
  most audio apps pre-buffering settings but you can alter it to 
something larger or smaller.  To make it similar to shoutcast you'd need 
to have a burst size of something like 1-2Meg (not sure of the exact 
figure).

karl.

Hi,

Shoutcast has, or at least used to have, a 1 mb buffer.  This means that it 
stores the last meg of the incoming stream and shoves it out to connecting 
clients.  This is annoying because you can't turn it off and you can't
(or
at least couldn't) change the size.  This meant about a 5-minute delay for 
16kbps streams which are not so common now but used to be very common 5 or 
6 years ago.

In Icecast, you can achieve this sort of behaviour with the various burst 
parameters.  The stock Icecast config has it set to burst 64k of data to 
connecting clients.  You can turn this off by setting the burst size to 0.

The burst size can also be set on a per mount basis I believe.

This raises a question I've been meaning to ask for awhile.  Is there any 
reason why we have both burst on connect and burst size?  Compatibility 
with older versions?  The burst size parameter would seem to be sufficient 
if setting it to 0 disables it.

Geoff.

OK, Thanks a lot Karl and Elf. It's clear to me now. Shoutcast gives you (by
default) a much larger burst and that's the difference I was seeing.

By the way: do you know sources for lists of stations? I see a "stream
directory" at icecast.org, but I don't know if it's available to
download (I
think using a program to dig the info from the web is not ethical, as least
without permission). Shoutcast has a nice directory but explicitly forbids
using that information.

I want to have a good station list in my program and I don't know how to get
it legally :(

Regards,
Damian


-----Mensaje original-----
De: Karl Heyes [mailto:karl@xiph.org] 
Enviado el: Monday, January 14, 2008 1:57 PM
Para: Dami?n Lezama
CC: icecast-dev@xiph.org
Asunto: Re: [Icecast-dev] Question about buffering with icecast protocol

Dami?n Lezama wrote:
> 
> 
> Hi,
> 
>  
> 
> I?ve seen that shoutCAST sends data much faster than real time when you 
> connect (for a while I assume, otherwise you?d be travelling to the 
> future:). That?s useful for fast buffering.
> 
>  
> 
> With icecast I don?t get that behavior, stream downloads at real time. 
> Is there a way to buffer data faster than real time? Maybe a ?seek? 
> feature? I need that because I need to allocate a special large buffer 
> for an app. Thanks!
Look at the burst-size option. The default is 64kbytes which is fine for 
  most audio apps pre-buffering settings but you can alter it to 
something larger or smaller.  To make it similar to shoutcast you'd need 
to have a burst size of something like 1-2Meg (not sure of the exact 
figure).

karl.


No virus found in this incoming message.
Checked by AVG Free Edition. 
Version: 7.5.516 / Virus Database: 269.19.2/1223 - Release Date: 1/13/2008
8:23 PM
 

No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.516 / Virus Database: 269.19.2/1223 - Release Date: 1/13/2008
8:23 PM

OK, Thanks a lot Karl, Elf, Geoff. It's clear to me now. Shoutcast gives you
a much larger burst than icecast (by default) and that's the difference I
was seeing.

By the way: do you know sources for lists of stations? I see a "stream
directory" at icecast.org, but I don't know if it's available to
download (I
think using a program to dig the info from the web is not ethical, as least
without permission). Shoutcast has a nice directory but explicitly forbids
using that information.

I want to have a good station list in my program and I don't know how to get
it legally :(

Regards,
Damian

No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.516 / Virus Database: 269.19.2/1223 - Release Date: 1/13/2008
8:23 PM

Geoff Shang wrote:
> 
> This raises a question I've been meaning to ask for awhile.  Is there 
> any reason why we have both burst on connect and burst size?  
> Compatibility with older versions?  The burst size parameter would seem 
> to be sufficient if setting it to 0 disables it.
The burst on connect was introduced as a setting in an earlier queuing 
implementation. As you have already mentioned, it was not that 
configurable so these days it's just an alias for burst-size of 64k if 
enabled and 0 if not.

karl.