[icecast-dev] Streaming with ices2/linux

[Melanie]

Hi,

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

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