[icecast-dev] Streaming with ices2/linux

Melanie melanie at t-data.com
Fri Nov 7 02:27:27 PST 2003


On 2003.11.07 05:06 Michael Smith wrote:
> ices2 assumes some client-side buffering: this is generally reasonable,
> all
> the clients I know of perform some buffering. Under this assumption, you
> needn't adhere precisely to the restrictions you describe here - and ices2
> does not.

There is no point to client side buffering - I do not have underruns.

> This is the normal case. There's also a threshold - if no audio has been
> sent
> for some period of time (currently 2 seconds - it should be made
> configurable). (this is for live input only, of course). I added this to
> solve precisely the problem you describe - I'm not sure why it isn't
> working
> for you, unless you're trying to use a client which doesn't buffer at all.

Thanks for the pointer. I investigated and found that ices works as 
advertised. The problem is a client one... The buffer in XMMS is measured 
in bytes, not playtime. When receiving blocks with few bytes but many 
samples, the assumption that a certain number of bytes means a certain 
number of samples doesn't hold true anymore. XMMS thinks it's an underrun 
and stops playback until it's input buffer fills above a certain threshold 
Then, when it starts playback again, playback takes longer than expected 
and XMMS falls behind.

There is no solution for this problem that could be implemented in 
icecast/ices, AFAICT, other than making the encoder less efficient - not a 
prime choice in my book.

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

More information about the Icecast-dev mailing list