[icecast] Alrighty.. ALMOST there! :)

[Tim Pozar]

One thing that has to be done for MP3 file streaming is to send
out a stream only as fast as the bit rate of the file or the
re-sampled bit-rate.  If you go too fast, the Icecast relay and player
will drop bytes in order to catch up.  If you go too slow you will
get pauses.

I wrote an MP3 file streaming perl script.  The program sends out
1 second of a stream and then waits for a second to pass on the
machine it is sending from with a...

while ()
{
# Streaming loop...

        # Find out what time it is...
        $seconds = time();

        ...read and send one second of an MP3 stream from the file...
        ...do various other error checking too such as "end of file" issues...

        # After we spent time doing the above, wait until the 
        # next second has happened...
        while($seconds == time()){
                # sleep for a fraction of a second so we don't 
                # eat CPU time looping at a fast rate.
                select(undef, undef, undef, 0.01);
        }
}

The timing is critical.  If it takes more than one second to read
the buffer in from the file and push it out to the client or Icecast
relay then, you will get audible gaps.  Also, if there is time to
open up the next MP3 file, then you will get a gap in your stream.

Originally I had a sleep(1) in my program and would get that problem
as I didn't count on the time the script read the file and sent it
out as being significant.  I played with the sleep() to roll it back
to about 0.9 seconds but still had the problem.  Doing the code I
did above, did the trick.

Tim

On Sat, Jul 21, 2001 at 12:49:43AM -0400, Dale Ghent wrote:
> So, a friend pointed me to the patch for sock.c:533, and that patch went a
> LONG way in fixing the streaming problems I've been experiencing (on
> solaris 8/sparc.) Thanks so much for that!
> 
> Now, I think that *sending* the stream is now squared away, but I think
> one problem remains on the receiving end of things.
> 
> I use the perl streamcast utility to stream my playlists, and tracks sound
> great. But sometimes when the tracks change, the new track will get
> regular half-a-second audible gaps - no studdering or repeats - just gaps.
> 
> Sometimes it'll persist through the next track... sometimes it clears up
> when the next track starts.
> 
> My hunch is that icecast wants/expects a constant incoming stream of data,
> and I think if there are any gaps in the incoming stream, it messes it up.
> It's plausible that the track change is what's causing thes very short
> gaps in the incoming stream data, and then persist at regular intervals in
> the outgoing stream to clients for the remainder of the track.
> 
> Any thoughts?
> 
> /dale


-- 
  Snail: Tim Pozar / LNS / 1978 45th Ave / San Francisco CA 94116 / USA
               POTS: +1 415 665 3790  Radio: KC6GNJ / KAE6247
"It's a damn poor mind that can only think of one way to spell a word."
                        - Andrew Jackson
"What is wanted is not the will to believe, but the will to find out,
which is the exact opposite." - Bertrand Russell, "Skeptical_Essays"

--- >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 at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.