Icecast - Aug 2004 - buffer size from source to ice/shoutcast

Hello,

I've built my own source for ICE/SHOUTcast, and it works pretty well except
for one thing. After tuning into the server and listening for an 60-90 minutes
you may hear a song skip ahead 30-90 seconds. I think I know why this is
happening but I'mnot sure how to fix it.

I think this is happening because my source is sending a little bit too much
data to ICE/SHOUTcast. My formula for sending data is pretty simple and goes
like this:

buffersize = bitrate * 1024 / 8
send buffer
wait 1 second
repeat

So..broadcasting at 128kbs means I send a buffer of 16384 bytes per second.

Is this the correct way to calculate how many bytes to send ICEcast or is there
a better way? Am I disregarding anyting liek network overhead?

I've run my source from several computers, all had the same problem. I also
ran it on the same box as shout/ice just to eliminate any network issues. Same
results...

The SHOUTcase DSP plugin and other sources I have tested don't seem to have
this problem.

What is the proper way to calculate how much data, and how often you should send
data to SHOUT/ICEcast?

<p>Thanks for your time.

Brandon

<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-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.

Brandon wrote:
> Hello,
>  
> I've built my own source for ICE/SHOUTcast, and it works pretty well 
> except for one thing. After tuning into the server and listening for 
> an 60-90 minutes you may hear a song skip ahead 30-90 seconds. I think 
> I know why this is happening but I'mnot sure how to fix it.
>  
> I think this is happening because my source is sending a little bit 
> too much data to ICE/SHOUTcast. My formula for sending data is pretty 
> simple and goes like this:
>  
> buffersize = bitrate * 1024 / 8
> send buffer
> wait 1 second
> repeat
>  
> So..broadcasting at 128kbs means I send a buffer of 16384 bytes per 
> second.
>  
Well you have to realise the kilobit definition used with mp3 is 1kbit = 
1000bits/sec (Microsoft uses 1kbit=1024bits for it's media formats 
incidently).

But your algorithm will suffer because sending the data will take a 
non-negligible time -
better algorithm is

tart = time();
sent = 0;
while(1){
      sent += send_chunk();
      delta = time() - start;
      my_bitrate = sent *8 / delta;
       if(my_bitrate> target_bitrate){
            sleep(1); /* (or any short time)*/
       }
}

you maybe want to reset the sent/start parameters periodicly.

Scott Manley

--- >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-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.

Very good.......very very good. The answer was so obvious too...thanks for
the help.

I understand the what you are doing. You are constantly checking the time
because you are throttling the data incase you send it too fast. If you send
it too slow..noproblem...just send it faster., and then throttle back when
you've sent too much.

All I have done so far was base my buffer on an even 1K instead of 1024 and
its already improved greatly.

On a side note my, there is a little red light on Winamp..itsto the left of
the elapsedtime. It lights up when the server its connected stops sending it
data. Minelights up at random intervals. Do you think that is because my
source may be bursting the data to SHOUTcast? Just wondering because I'm
using some TCP Socket libraries, and who knows what they may be doing behind
the scenes. Its no big deal, I was just wondering why it woudl do
that.....the stream plays fine regadless.

<p>All I did so far was
----- Original Message -----
From: "Scott Manley" <djsnm@djsnm.com>
To: <icecast@xiph.org>
Sent: Friday, November 15, 2002 7:26 PM
Subject: Re: [icecast] buffer size from source to ice/shoutcast

<p>> Brandon wrote:
>
> > Hello,
> >
> > I've built my own source for ICE/SHOUTcast, and it works pretty
well
> > except for one thing. After tuning into the server and listening for
> > an 60-90 minutes you may hear a song skip ahead 30-90 seconds. I think
> > I know why this is happening but I'mnot sure how to fix it.
> >
> > I think this is happening because my source is sending a little bit
> > too much data to ICE/SHOUTcast. My formula for sending data is pretty
> > simple and goes like this:
> >
> > buffersize = bitrate * 1024 / 8
> > send buffer
> > wait 1 second
> > repeat
> >
> > So..broadcasting at 128kbs means I send a buffer of 16384 bytes per
> > second.
> >
>
> Well you have to realise the kilobit definition used with mp3 is 1kbit >
1000bits/sec (Microsoft uses 1kbit=1024bits for it's media formats
> incidently).
>
> But your algorithm will suffer because sending the data will take a
> non-negligible time -
> better algorithm is
>
> start = time();
> sent = 0;
> while(1){
>       sent += send_chunk();
>       delta = time() - start;
>       my_bitrate = sent *8 / delta;
>        if(my_bitrate> target_bitrate){
>             sleep(1); /* (or any short time)*/
>        }
> }
>
> you maybe want to reset the sent/start parameters periodicly.
>
> Scott Manley
>
> --- >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-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-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.