> > It will decrease in a few tenth of seconds the time needed to send data, > but will increase complexity in tree locks.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). Mike <p><p>--- >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 04:29, Michael Smith shaped the electrons to shout:> Other than the headers, there is no deliberate burst at initial connect > (but there will be an option for this soon).You can try it (48 KB of startup buffers) at: http://mcrg.uib.es:8000/live.ogg and http://mcrg.uib.es:8000/high.ogg The only think I'm still not very convinced is that clients has to wait for at least 1 "source iteration" (and 2 in the worst case) in order to beging to receive any data at all. This is due to the algorith: while (source) wait for source read from source send to clients check new clients add buffers etc.. end I think the following will behave better for startups: while (source) wait for source check new clients add buffers read from source send to clients etc.. end It will decrease in a few tenth of seconds the time needed to send data, but will increase complexity in tree locks. <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 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.