Icecast Streaming Media Server

[Anonymous]

We are having a problem with our Icecast streams, in that every so often on a regular interval, the stream pauses. The player stays connected, and the stream continues after a second, but it's very irritating to our listeners.

We have Ices (v 0.4) feeding content into three streams (two 64k-stereo, and one 32k-mono) into the Icecast server (v 2.3.1), on the same box (Debian Sarge).

Server Limits:
<clients>100</clients>
<sources>10</sources>
<threadpool>5</threadpool>
<queue-size>524288</queue-size>
<client-timeout>30</client-timeout>
<header-timeout>15</header-timeout>
<source-timeout>30</source-timeout>
<burst-on-connect>1</burst-on-connect>
<burst-size>131072</burst-size>

Big Blue Swing 64k-stereo
Big Blue Swing 32k-mono

When a WinAmp client connects into our 64k stream, 24 seconds later the stream hiccups. It pauses for about a second, and then continues on. Clients listening to the 32k stream hear this hiccup about 49 seconds into it. In both cases they will continue hiccuping at that same rate (every 24, or 49 seconds) as long as the client is connected.

Things I know;

• It doesn't matter where in the song the client connects in. It will always happen 24, or 49 seconds later.
  
• There are no pauses between songs.
  
• We have Shoutcast servers acting as relays from IceCast. They experience the same interval, but it's a greatly reduced pause. (almost not noticeable to the non-audiophiles)
  
• Supposedly different people on different networks aren't having this problem, but I haven't been able to verify that with identical equipment/software.
  
• Intelligent players that handle buffering better don't ever exhibit the pause.
  
• We were under the impression that Savvis had network issues with one of their routers that was causing this problem. We have since been told that router has been replaced, and shouldn't be seeing any problems.
  
• Our processor, and memory usage for the server all look good. The processor (AMD Athlon 64 3200+) is sitting at 80% idle most of the time. It's got 1GB of ram, and no swap in use.
  
• I don't know how long this has been an issue. It might have started in the last few months, it might have been going on since we moved to this server a year ago. My personal preference for a client (Jet Audio) buffers enough that I never notice a problem.
  

Questions:

• Has anyone seen this problem before?
  
• Everyone reading this, if you listen to our streams are you personally hearing the hiccup? If not, what does the traceroute to bigblueswing.com look like?
  
• Does anyone see any issues with the way I've got our server configured that would cause this problem?
  
• Any other thoughts before I pull all of my hair out of my head trying to figure this out?
  

Thanks for you time,
Shane Chambers

[karlH]

I didn't experience the problem here with vlc, maybe the issue is winamp specific because a 64k 44.1khz stereo mp3 stream is not something I would expect to work well (if at all). I'd make the 64k stream mono at least.

karl.

[Anonymous]

That really doesn't make a lot of sense to me, when compared to the other streams out there. 65k/Stereo is fairly common across the board. Even if it wasn't, under your hypothesis, our 32k/mono stream should work fine. Again, it's got the same problem, only delayed, which would lend itself to the assumption that a certain amount of data needs to be transmitted before the problem occurs.

I just tested VLC from my system as well. VLC falls into the category of smart enough to buffer enough of the stream to not hear the hiccup.

I wouldn't be so concerned about one player out of all the selections not functioning properly, but WinAmp is very popular, and holds a large percentage of in our logs.

{sigh/frustrated}

Shane

[karlH]

Can you point to many 64k MP3 stereo streams running at 44.1khz? All I'm suggesting there is that you may find it better to run in mono not stereo or a lower samplerate.

I would agree with you on the fact that if a glitch is happening on both streams then it is probably further up. As icecast doesn't parse or time the mp3 content then it cannot be that. The content sounds complete so it could be a timing issue with ices 0.4/lame <version>. Usually problems like this are down to the incoming files but as the glitch keeps reoccurring every N seconds then I'd check for errors in the ices log. It could be a resync or maybe the clock is getting shifted. Try the 32k stream on it's own (run a parallel test if you must) with a separate ices, see if it exhibits the same issue.

karl.

[Anonymous]