> David, > > > ...snip > > I think the proper solution is to make the queue limit a tunable > > parameter so that people can set it to an appropriate value for their > > individual circumstance. I think a reasonable value would be in the > > 2-6 frames range, but I can imagine that some people may be doing VoIP over > > an unstable Internet with wild swings in RTT that will require more > > buffering. > > BTW, I think the patch I submitted actually provides for a queue depth > > of 3 - two existing frames plus a third, so the delay will range from > > 40-60ms, depending on how things line up timing wise. > > Thanks for the wealth of info there. I'm going to turn this into a > tunable parameter for the next release. Some other experimentation has > shown that this may now be the root of all of the problems but is part > of the puzzle.
I hope you meant "may not". :-) -DG David G. Lawrence President Download Technologies, Inc. - http://www.downloadtech.com - (866) 399 8500 The FreeBSD Project - http://www.freebsd.org Pave the road of life with opportunities. _______________________________________________ --Bandwidth and Colocation Provided by http://www.api-digital.com-- Asterisk-BSD mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-bsd
