On Monday 10 February 2003 13:25, Michael Smith shaped the electrons to shout:> If it takes this long, then there's something else wrong. It should be > well under a tenth of a second (and probably closer to 1/100).No, nothing wrong, at least darkice is doing very badly. With darkice as encoder at about 30 kbps, there are about 3 buffers per second, which mean that in the worst case, a client must wait 2/3 seconds in order to start receiving. In the best case in 1/3 seconds. That means the improvements is among 0.66 and 0.33 seconds (ish). <p><p> -- ricardo galli GPG id C8114D34 --- >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.
On Monday 10 February 2003 23:32, Ricardo Galli wrote:> On Monday 10 February 2003 13:25, Michael Smith shaped the electrons to > > shout: > > If it takes this long, then there's something else wrong. It should be > > well under a tenth of a second (and probably closer to 1/100). > > No, nothing wrong, at least darkice is doing very badly. > > With darkice as encoder at about 30 kbps, there are about 3 buffers per > second, which mean that in the worst case, a client must wait 2/3 seconds > in order to start receiving. In the best case in 1/3 seconds. > > That means the improvements is among 0.66 and 0.33 seconds (ish).Ugh. Yes, if the source client behaves like that, then your worst case is pretty bad. However, this change only improves the worst case to 1/3 of a second (in your example), you certainly don't improve this to 0. Note that worst case (example: streaming digital silence with a naive source client like darkice (and ices in some modes)) is much much worse than this even with your proposed modification - possibly several seconds. This can't be changed as easily, though. Sensible source behaviour improves this significantly. 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.
On Monday 10 February 2003 13:52, Michael Smith shaped the electrons to shout:> Ugh. Yes, if the source client behaves like that, then your worst case > is pretty bad. However, this change only improves the worst case to 1/3 > of a second (in your example), you certainly don't improve this to 0.Ugh again... with your comments I'm realising that darkice doesn't behave as every source, which basically means that the hardcoded max size in buffers of the clients' queue must be changed asap to size in bytes in order not to disconnect clients when the source is sending small buffers. I saw this behaviour with ices and MP3, the average size of the buffers is about 300-400 bytes, which means a startbuffer of few kilobytes is greater that 25. If you are going to apply my three previous pending patches, I can sending you a patch to change the control of queues size to KB instead (and also configurable). I already did it, but I put it on stand-by until you apply the previous patches. Regards, -- ricardo galli GPG id C8114D34 --- >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.