Hi, 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). Jean-Marc
> 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. Also, it would be beneficial if a "minimum safety" could be set, below which the jitter buffer would not adapt (ie: always maintain at least 40ms of buffer). Some users have requested this. .. And equally important; during discontignous transmission, in which there may be small communication pauses (of either 3 seconds or several minutes), it would be beneficial if the jitter buffer remembered it's current estimates instead of resetting to the default. But I must say that it really does work well at the moment, at least from the "minimizing latency" point of view :)
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
Oh, I forgot to mention one thing. I currently append a few bits of custom information to each speex packet which I fetch out with things like speex_bits_unpack_unsigned(&sjJitter.current_packet, 1); It would be very usefull if the jitter buffer didn't actually decode the packet, but instead returned a pointer to it (or NULL if you should play silence and -1 if you should repeat the last packet again). If you're making a more generic API, it would also be beneficial if packet loss (and late transmissions) statistics could be fetched somehow.