Hi, this issue is a bit tricky. The problem with: > send.tv_usec = 1000000ul*(rem/rate);
is that it would imply a high error in send.tv_usec; for rem == 89900 and rate == 90000, 89.9 milliseconds would be reduced to 0 microseconds. if we instead use: > send.tv_usec = 1000000ul*rem / rate; for a rem > ~4290, 1000000ul*rem a 32 bits value would overflow. So to avoid using 64 bits arithmetics 'send.tv_usec = (1000ul*rem) / (rate/1000ul);' is used on the assumption that rate is multiple of 1000. This assures that overflow will not occur for rates < 4290000 as well. For standard RTP clock rates it holds, but you are right there is the risk for a division-by-zero. The lowest clock rate I'm used to see is 8khz and the highest 90khz, but if there are applications using lower bit rates, we could look for a compromise like 'send.tv_usec = (10000ul*rem) / (rate/100ul);' :) -that would allow rates of up to 429000 and will work for rates multiple of 100. On Tue, May 24, 2005 at 01:56:57AM +0200, Jonas Schwertfeger wrote: > Line 241 in outqueue.cpp produces division-by-zero exceptions for RTP > clock rates < 1000 because "(rate/1000ul)" evaluates to 0 for rates < > 1000. I modified the original line > > send.tv_usec = (1000ul*rem) / (rate/1000ul); > > to > > send.tv_usec = 1000000ul*(rem/rate); > > which fixes the bug. If you ever need clock rates below 1000 you'll have > to fix this bug manually until it is fixed by the ccRTP maintainers in a > future release. > > Regards > Jonas > > > _______________________________________________ > Ccrtp-devel mailing list > [email protected] > http://lists.gnu.org/mailman/listinfo/ccrtp-devel _______________________________________________ Ccrtp-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/ccrtp-devel
