Thorvald Natvig wrote:>> I'd like know about anyone using the current jitter buffer in Speex. I'm >> planning on changing it to make it more general and I'd like some >> feedback about how to make it better. Also, let me know if you're doing >> anything serious with it and want to make sure I don't break your stuff. >> >> Basically, I want to make the jitter buffer easier to use with other >> codecs and reduce the latency. This would require either changing the >> API or adding a new one (depending on the feedback I get and how many >> people use it). > > > I'm currently using the jitter buffer in Mumble, but if you want to > make changes go right ahead, I can just change the places where I've > plugged in the jitter buffer. > > If users are bandwidth-constrained, I provide an option for putting > several individual speex packets in one UDP packet. While I'm not > sure, I do believe the jitter buffer would probably benefit from > knowing that packets always come in pairs.I would think you might also do better if you interleaved packets when you did this: instead of sending packets like this: [0,1] [2,3] [4,5] [6,7], send them like this: [0,2] [1,3] [4,6] [5,7] In this way, if one packet is dropped you don't lose two consecutive voice frames. -SteveK
> I would think you might also do better if you interleaved packets when > you did this: instead of sending packets like this: [0,1] [2,3] [4,5] > [6,7], send them like this: [0,2] [1,3] [4,6] [5,7] In this way, if one > packet is dropped you don't lose two consecutive voice frames.No, but you make the latency even worse. I think 01, 23, 45, ... is still probably best. Jean-Marc
>> I would think you might also do better if you interleaved packets when >> you did this: instead of sending packets like this: [0,1] [2,3] [4,5] >> [6,7], send them like this: [0,2] [1,3] [4,6] [5,7] In this way, if one >> packet is dropped you don't lose two consecutive voice frames. > > No, but you make the latency even worse. I think 01, 23, 45, ... is > still probably best.hm, ram memory isnt get slowlyer if you try to send half of a packet and then start to send the next 2*half. (i. e. send the half block, start send after your pointer reaches the 2*half block) You have to write it the same schema as if you send it. By the way.. can someone of you send some good books for audio calculations or at least some good tutorials. Or if someone can give me a adress with some compress theoretics, with examples, it would be great. Yes i readen the sum formulas in the speex manual... but they are to complex without a professor that can explain it in words whitch I understand, and without the needs of a week.