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 --- >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.
Was wondering if you might be so kind as to send me the patches? Many thanks in advance, Ian Dickens ian@mitre.org On Sat, 21 Jul 2001, 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 > > > --- >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.
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@lns.com> To: <icecast@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 wenta> > 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 trackssound> > great. But sometimes when the tracks change, the new track will get > > regular half-a-second audible gaps - no studdering or repeats - justgaps.> > > > 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 ofdata,> > and I think if there are any gaps in the incoming stream, it messes itup.> > 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 intervalsin> > 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@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.
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@xiph.org'
containing only the word 'unsubscribe' in the body. No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.