On Thursday 06 November 2003 11:53, Melanie wrote:> Hi, > > I have observed a problem when streaming with ices2. When only silence is > transmitted, like pauses in an interview, the bitrate drops to 0. This > happens even when a minimum bitrate is set. > Now, assume there is a half block of audio ready. Now the level drops to > silence, or near silence, possibly because the person is thinking about an > answer for a while. > This will cause the partial block to not be transmitted in time for the > client to produce continuos audio. Also, the client can, if this happens > more often, incur some very serious lag over time. > > What needs to be done, IMHO, is to guarantee that data is sent at least as > fast as the playback of the data will take. So, if there is silence, > smaller blocks must be sent, because a length of music and an equal length > of silence will be encoded in a different number of bytes. Each block of > data being collected, waiting for transmission, neds a deadline attached to > it which is the time between the sending of the last block and the time it > would finish playing. So, if a block is sent that encodes 2 seconds of > audio, the next block must be sent no more than 2 seconds later. Even if > it's only the few bytes needed to tell the client to play another 2 seconds > of silence.Melanie, 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.> > I haven't read the code, but it appears that blocks are sent when a certain > byte count is reached. This is fine for continuous audio, but if there is > silence involved, it's just not enough.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.> > A functioning minimum bitrate would also solve this problem, at the cost of > bandwidth, but that's not available either. The minimum bitrate parameter > is seemingly ignored, even though the ices2 startup messges do print it > out, meaning it's recognized from the config file.Minimum bitrate just forces a minimum on what the encoder will select to encode - it will not deliberately insert padding when there is no additional data to encode, but is not actually ignored. Not sure why this isn't working for you, anyway - perhaps you could investigate? The threshold-sending is done in src/encode.c:encode_dataout(). Mike --- >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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Hi, I have observed a problem when streaming with ices2. When only silence is transmitted, like pauses in an interview, the bitrate drops to 0. This happens even when a minimum bitrate is set. Now, assume there is a half block of audio ready. Now the level drops to silence, or near silence, possibly because the person is thinking about an answer for a while. This will cause the partial block to not be transmitted in time for the client to produce continuos audio. Also, the client can, if this happens more often, incur some very serious lag over time. What needs to be done, IMHO, is to guarantee that data is sent at least as fast as the playback of the data will take. So, if there is silence, smaller blocks must be sent, because a length of music and an equal length of silence will be encoded in a different number of bytes. Each block of data being collected, waiting for transmission, neds a deadline attached to it which is the time between the sending of the last block and the time it would finish playing. So, if a block is sent that encodes 2 seconds of audio, the next block must be sent no more than 2 seconds later. Even if it's only the few bytes needed to tell the client to play another 2 seconds of silence. I haven't read the code, but it appears that blocks are sent when a certain byte count is reached. This is fine for continuous audio, but if there is silence involved, it's just not enough. A functioning minimum bitrate would also solve this problem, at the cost of bandwidth, but that's not available either. The minimum bitrate parameter is seemingly ignored, even though the ices2 startup messges do print it out, meaning it's recognized from the config file. This becomes a major annoyance when anything other than continuous music is sent, even with normal talk, lag time can build up and bits of disjoint audio are heard at the beginning of a sentence. This is probably the tail of the last sentence, encoded and buffered, but not sent out until there is more audio to send. 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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.