SHOUTcast 1.8.0 and buffering

core · 7th January 2001, 15:04

Generally speaking the 1.8.0 is a solid release. I haven't encountered any problems or issues with the server whatsoever.

However, I have noticed that there is a MAJOR lag between the time the signal is streamed and the time the listener hears it at the other end. Pre-1.8, I observed a lag of no more than about 45 seconds. With this new version, that number easily goes as high as 2 minutes. (FYI, the buffer position for my test listener varies between 137000 and 153000 -- a lot more than the reported average of 128000)

Was this an anticipated result of the better synched title updates? (Speaking of which... those title updates are VERY reliable and work very well!)

This buffering issue is not a problem for me... I was just curious to seee if it was something that was expected.

Tumu · 8th January 2001, 05:33

As they state on the shoutcast.com main page, the internal buffer (I presume this means the source stream buffer) was upped to 1 Meg, which would create additional "lag" for listeners. Those buffer counts for individual listeners are independent (but they might be just pointers and lengths to the source buffer) from the source buffer.

-Tumu, Nectarine Demoscene radio

core · 8th January 2001, 11:08

I suppose I just don't fully understand the whole buffering process. Would you happen to know if there's a FAQ or a web site with an explanation about buffering?

Regards,

wedgemusic · 8th January 2001, 16:12

The best place for FAQs, explanations, how-to, etc is http://www.shoutclub.com .

engineering · 10th January 2001, 13:29

In a nut-shell.....

The 1.8.0 server has a increased 'buffer'

The server 'hoards' data sent to it to ensure that the encoder can fill it back up (if there is a sudden drop in connectivity between source and server) before the server runs out of data to send to clients (Listeners).

A Crappy analogy is thus :

Consider the Source/encoder being a 'Tap'
The server being a 'watering can' and the Internet/L.A.N whaterver connection between the Source and the server being a hose pipe.

Once the can is filled up, it can continue to pour water from the spout continuously, even if someone treads on the hose pipe - the bigger the can, the more tolerant it is.

Shit! Enough analogys!

Do you get it?

core · 14th January 2001, 01:02

Yes.... that answers my question...

Thank you!

10th January 2001, 13:29	#5
engineering Senior Member Join Date: Aug 2000 Location: Sussex, England Posts: 145	Buffers In a nut-shell..... The 1.8.0 server has a increased 'buffer' The server 'hoards' data sent to it to ensure that the encoder can fill it back up (if there is a sudden drop in connectivity between source and server) before the server runs out of data to send to clients (Listeners). A Crappy analogy is thus : Consider the Source/encoder being a 'Tap' The server being a 'watering can' and the Internet/L.A.N whaterver connection between the Source and the server being a hose pipe. Once the can is filled up, it can continue to pour water from the spout continuously, even if someone treads on the hose pipe - the bigger the can, the more tolerant it is. Shit! Enough analogys! Do you get it?

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

7th January 2001, 15:04	#1
core Junior Member Join Date: Jan 2001 Posts: 45	Generally speaking the 1.8.0 is a solid release. I haven't encountered any problems or issues with the server whatsoever. However, I have noticed that there is a MAJOR lag between the time the signal is streamed and the time the listener hears it at the other end. Pre-1.8, I observed a lag of no more than about 45 seconds. With this new version, that number easily goes as high as 2 minutes. (FYI, the buffer position for my test listener varies between 137000 and 153000 -- a lot more than the reported average of 128000) Was this an anticipated result of the better synched title updates? (Speaking of which... those title updates are VERY reliable and work very well!) This buffering issue is not a problem for me... I was just curious to seee if it was something that was expected.

8th January 2001, 05:33	#2
Tumu Junior Member Join Date: Jan 2001 Location: Finland Posts: 10	As they state on the shoutcast.com main page, the internal buffer (I presume this means the source stream buffer) was upped to 1 Meg, which would create additional "lag" for listeners. Those buffer counts for individual listeners are independent (but they might be just pointers and lengths to the source buffer) from the source buffer. -Tumu, Nectarine Demoscene radio

8th January 2001, 11:08	#3
core Junior Member Join Date: Jan 2001 Posts: 45	I suppose I just don't fully understand the whole buffering process. Would you happen to know if there's a FAQ or a web site with an explanation about buffering? Regards,

8th January 2001, 16:12	#4
wedgemusic Senior Member Join Date: Nov 2000 Posts: 176	The best place for FAQs, explanations, how-to, etc is http://www.shoutclub.com .

14th January 2001, 01:02	#6
core Junior Member Join Date: Jan 2001 Posts: 45	Yes.... that answers my question... Thank you!