[icecast] Problem with ices on OpenBSD 2.9 w/ Icecast 1.3.10

[Nick Ludlam]

From: "Brendan Cully" <brendan at icecast.org>
> On Tuesday, 10 July 2001 at 16:50, Nick Ludlam wrote:
> > From: "Brendan Cully" <brendan at icecast.org>
> > > Sorry Nick, I lost your last mail. One last thing, did you make clean
> > > && make? The dependencies are not generated properly for ices, so even
> > > if libshout got rebuilt it might not have been relinked.
> > 
> > There's no other libshout on the system. Have rebuilt from scratch and it still
> > exhibits the timing problems.
> 
> To confirm that this is the problem, stream a track from ices. ices
> should take the same amount of time to stream that track as the track
> is long. When it isn't sleeping properly, it finishes sending the
> track to icecast much earlier.
> 
> If ices takes two minutes to send a two-minute mp3, you are having a
> different problem.

Hurray! I found the problem, and it lies with icecast. If I set sleep_ratio
to 0, I get no problems with icecast reading data from the socket. I spent
a while working out that after a certain length of time, ices started falling over
when the thread reading the socket in icecast wasn't waking up in time
so send() in ices started blocking.

Going through the icecast source, wouldn't it make sense to select() on the
source data socket instead of just sleeping for an arbitrary amount of time?
Since ices is controling when it sends data, you can just read as necessary
at the icecast end. I'm not really happy running icecast with sleep_ratio at
0 as this is prohibitively cpu-intensive. I guess this doesn't crop up when
running on Linux as the scheduler is different.

Nick

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