[icecast] Alrighty.. ALMOST there! :)

Tue Jul 24 08:59:37 UTC 2001

Dear friend,

Well, i have been worknig on linux for the past 5 years now. I know how tar
and gunzip work. I think the problem could be with the downloaded files and
not the gz file on icecast srever. Anyways, i have setup a shoutcast server
and it works geat but i dont like it cuz it cant be cuztomized since its
always a binary. I asked the guys at shoutcast for the source code but they
turned out to be real possesive about it. There are some difficultiues that
i am facing with icecast bigtime. I downloaded this binary win win9x OS and
its ok. But the admin is preety hectic. What are the main things  that need
to me setup for an ice cast server . Ok, you have the server but are you
able to broadcast with SHOTcast DNAS plugin? There are so many things
mentioned here. Which prog is the best for straming? What does ices has to
do with it since icecast is a total package. What I think overall is that
ICEcast lacks proper documentation and someone has to do something about it.
The forum is preety empty too. Its us who have to improve this and make it
the best streamer ever.

Regards,

------------------------------------------
Asif M. Baloch
Portal Manager Hilinks.com
Product Manager BaliNet
Product Manager e-Fax
e-Tech Group of Companies
Karachi, Pakistan.
Tel: 111-88-99-88
-------------------------------------------
$ To understand the program, you have to become both the machine and the
program $
----- Original Message -----
From: Tim Pozar <pozar at lns.com>
To: <icecast at xiph.org>
Sent: Monday, July 23, 2001 11:06 PM
Subject: Re: [icecast] Alrighty.. ALMOST there! :)

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

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