>What size packets are you running. Remember that time between packets >is based on packet size and transmit rate. Have a look at the t_ipi >code or the CCID3/TFRC spec but basically time between packets is >size/speed. So you would get 25 msec on a 40 kb link if running 1000 >byte packets. If you are getting some variation on smaller packets you >could quite easily get 25 msec.
Most of the packets are small - less than 100 bytes. Also note that this delay occurs while waiting for the AUDIO. This only happens AFTER the application knows there is no pending network data. It's as if the incoming packets causes the kernel to do so much processing, than the application is preventing from handling the /dev/audio in time. What is the worst case time DCCP takes to process incoming packets? It seems - at first glance - to be taking longer that 16 milliseconds at times. This is a subtle problem. I'm not sure how to write a simple test case for it. >This is a large part of the reason for the proposed VoIP CCID which >specifies 10 msec between packets. This may well suit your needs >better... I'd love to test an implementation of it. - To unsubscribe from this list: send the line "unsubscribe dccp" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
