While we are talking default values for options and features in the config file, It seems like an appropriate time to bring up again, a discussion we have been having regarding the default value for burst-on-connect, a new feature of icecast which was created to eliminate the large startup times reported by many listeners of icecast streams. The question is whether to enable this by default or not in the "base" config. It is my belief that most users are using the stock base config (changing things like listen port and password) and not really bothering to look at other options. There are alot of options in the config file, and I believe most users just take the high road and mostly ignore them. So to me, this means, if we turn off burst-on-connect by default, it will rarely get used...users have a tendency to not seek out new options, and features unless they are told about them, and very few actually read the documentation (I don't mean to offend anyone here who really is diligent about reading docs, but anyone who hangs out in #icecast would know that reading docs does not to be users' strong point :)). So I'd advocate enabling this by default so that it will actually get used.... The downside of enabling this is it adds a small amount of latency between the source client and the end-user listener. I did a small testing using a 128kbps MP3 and Vorbis stream and using Winamp 5 with default client buffering values. When burst-on-connect was disabled, I saw a latency b/w the source and listener to be about 1.5 seconds. By this I mean that if a clip was played on the source client, that clip was heard by the listener 1.5 seconds later.. When burst-on-connect was enabled (changing nothing else), this latency grew to 3 seconds. So my feelings on the matter are that I think that more users would consider it better to have their stream served faster overall on startup than having an additional latency between the source and the end-user. Thus, I'd advocate it's setting to be enabled by default. any other thoughts/opinions ? Any thoughts from users is most welcome. oddsock <p>--- >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-dev-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.
Being the lurker that I am on this list, but an avid icecast user and tester, I say that the enable by default option of bursting is a good idea. I will now become invisible again. --Stauf On Sun, May 16, 2004 at 11:11:06PM -0500, oddsock wrote:> While we are talking default values for options and features in the config > file, It seems like an appropriate time to bring up again, a discussion we > have been having regarding the default value for burst-on-connect, a new > feature of icecast which was created to eliminate the large startup times > reported by many listeners of icecast streams. > > The question is whether to enable this by default or not in the "base" > config. It is my belief that most users are using the stock base config > (changing things like listen port and password) and not really bothering to > look at other options. There are alot of options in the config file, and I > believe most users just take the high road and mostly ignore them. So to > me, this means, if we turn off burst-on-connect by default, it will rarely > get used...users have a tendency to not seek out new options, and features > unless they are told about them, and very few actually read the > documentation (I don't mean to offend anyone here who really is diligent > about reading docs, but anyone who hangs out in #icecast would know that > reading docs does not to be users' strong point :)). So I'd advocate > enabling this by default so that it will actually get used.... > > The downside of enabling this is it adds a small amount of latency between > the source client and the end-user listener. I did a small testing using a > 128kbps MP3 and Vorbis stream and using Winamp 5 with default client > buffering values. When burst-on-connect was disabled, I saw a latency b/w > the source and listener to be about 1.5 seconds. By this I mean that if a > clip was played on the source client, that clip was heard by the listener > 1.5 seconds later.. When burst-on-connect was enabled (changing nothing > else), this latency grew to 3 seconds. > > So my feelings on the matter are that I think that more users would > consider it better to have their stream served faster overall on startup > than having an additional latency between the source and the > end-user. Thus, I'd advocate it's setting to be enabled by default. > > any other thoughts/opinions ? Any thoughts from users is most welcome. > > oddsock > > > --- >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-dev-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.--- >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-dev-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.
> Firstly, I'm one of those people who thoroughly reads through a config file > before firing up the server, so the final decision won't affect me much > from a server admin point of view. From the point of view of a listener, > I'd be happy enough for burst on connect to be the default, providing the > buffer isn't too big. I'd also like to see it be configurable, as if it's > measured in bytes, the amount of latency will depend on the bit rate. I am > constantly frustrated at shoutcast's 1 meg buffer, which runs to several > minutes at 16kbps for example.Since we know the bitrate of the stream, is there a reason to have the buffer size config parameter be in bytes? I should probably be in tenths of a second or some such more appropriate unit. Let the code do the math, instead of the humans. jack. --- >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-dev-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.
> The question is whether to enable this by default or not in the "base" > config.Burst with a reasonable buffer size should be enabled by default. The people doing latency sensitive broadcasting are far, far fewer than those who would benefit from this change. jack. --- >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-dev-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: Firstly, I'm one of those people who thoroughly reads through a config file before firing up the server, so the final decision won't affect me much from a server admin point of view. From the point of view of a listener, I'd be happy enough for burst on connect to be the default, providing the buffer isn't too big. I'd also like to see it be configurable, as if it's measured in bytes, the amount of latency will depend on the bit rate. I am constantly frustrated at shoutcast's 1 meg buffer, which runs to several minutes at 16kbps for example. 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-dev-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.
At 09:56 AM 5/17/2004, you wrote:>Hi: > >Firstly, I'm one of those people who thoroughly reads through a config file >before firing up the server, so the final decision won't affect me much >from a server admin point of view. From the point of view of a listener, >I'd be happy enough for burst on connect to be the default, providing the >buffer isn't too big. I'd also like to see it be configurable, as if it's >measured in bytes, the amount of latency will depend on the bit rate. I am >constantly frustrated at shoutcast's 1 meg buffer, which runs to several >minutes at 16kbps for example.yes, this is exactly the case..it is completely configurable. It's actually based off the client queue size (<queue-size> param in the config) since the source buffer size and the client queue size are really in lock step with each other. In this case, the source buffer size is defined as 50% of the client queue size. This is because when the client first connects, if burst-on-connect is enabled, the source will take the entire source buffer and send it to the client. The source buffer must be less than the client buffer, otherwise icecast could fill the entire client queue in one shot and cause the client to be terminated due to lagging (icecast currently determines lagging by detecting when the client queue buffer fills up). Anyway, this is a long way of saying, yes, it is configurable and build that way because the hard-coded/unchangeable 1MB buffer in Shoutcast is extremely frustrating. oddsock>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-dev-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.<p>--- >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-dev-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.