Streaming with Shoutcast/Winamp delay question

[cgriggs]

You guys that are streaming your scanner online with the Winamp/Shoutcast setup, do you experience delays? For instance you are listening to your stream and you might hear the time as being 7:45 and you notice the time is 7:47 or 7:48 when you hear this transmission. The delay may or may not be this severe but it isat least a good 30 secods for me. This is only an example but I think I am having this problem. Thanks

 

[Al42]

It's not a problem, it's how Shoutcast and Icecast work. Or, it's a problem, but something only the people who write the server code can fix.

 

[wmbio]

Your upload speed and your ISP can also contribute to the delay, 30 seconds to 1 minute is normal using these programs. I assist with administation of this site in Western Maryland.
http://acmscanner.no-ip.org/

enjoy
Wmbio

 

[cgriggs]

Good, I had a hunch that was normal. Thanks for the replies.

 

[nexus]

Shoutcast has a horrible lag. 30 to 60 seconds after the actual transmission. I switched to Icecast for my server and that alone brought the lag down to about 5 seconds. You should try using icecast. You'll notice a huge improvement.

 

[w2lie]

if you encode with windows media, your shooting yourself in the foot too.
I've played with Windows M.E. and the lag was a minimum of 45sec.

I average about a 5 second delay with my current setup. I use Simplecast + Icecast, encoded at MP3 legacy

 

[flyingwolf]

Unfortunatly there isnt much you can do about the lag on internet radio, it canbe anywhere form a few seconds in the best case, to a minute or more in the worst case, this is actually by design, you need a buffer for those split seconds when your not getitng the perfect signal, or it cuts out for a moment.

So until the internet can be made 100% stable, we are going to have buffers, and therefore lag.

Oh and Liquid_Squelch when your ready to switch over to SAM for some automation let me know, I can send you a coupon for the software, and if you have been waiting with anticipation for SAM4, its almost ready, (psst, I have it and I LOVE the new features Louis put in).

 

[Dubbin]

So until the internet can be made 100% stable

WHAT????????? The internet isn't 100% stable?????????????? BUT BUT AOL says it is :lol:

 

[tspainiv]

if you encode with windows media, your shooting yourself in the foot too.
I've played with Windows M.E. and the lag was a minimum of 45sec.

I average about a 5 second delay with my current setup. I use Simplecast + Icecast, encoded at MP3 legacy

I encode with Windows M. E. and my delay is only about 10 seconds...that's for an audio and video feed.

 

[flyingwolf]

I belive that WME can actually have the buffer set.

And those thinkgs you shouldnt touch in the shoutcast INI file that says "dont touch these unless you now what your doing" have allot to do with the buffer time.

 

[mike_s104]

Your upload speed and your ISP can also contribute to the delay, 30 seconds to 1 minute is normal using these programs. I assist with administation of this site in Western Maryland.
http://acmscanner.no-ip.org/

enjoy
Wmbio

not always the case. it's the buffer that ShoultCast uses. it does the same thing if you on the local network where the ShoutCast server is conencted to. if you think the upload speed is too slow for the server to stream, then set the encoding lower and use mono.

 

[kb2vxa]

All of that plus the dispatcher's clock is seldom accurate. Having an "atomic" clock on the wall and the computer synced to NIST as well I have noted as much as several minutes discrepancies.

 

[motomeso]

I would have to agree that Shoutcast has a high delay time compared to Icecast and is the reason I switched. The funny thing is if I relay a shoutcast feed as I often do during Hurricane season the delay isn't present when listening through the Icecast relayed feed.

 

[flyingwolf]

The funny thing is if I relay a shoutcast feed as I often do during Hurricane season the delay isn't present when listening through the Icecast relayed feed.

Thats impossible, the buffer is in SHOUTcast itself, so the buffer would be present before you picked up the stream to re stream it, so unless IceCast happens to be sending it at faster then real time it would still have that buffer.

And remember, the reason IceCast appears to have less of a buffer is that it does have less of a buffer, and therefore higher chances of dropouts on the listener.