search for: speex_read_bit

...with the speex buffer, but I imagine there's going to be a lot more work needed to get this where I'd like it to go. At the API level, It seems pretty easy to make the speex implementation become speex-independent. Instead of having speex_jitter_get call any particular speex_decode or speex_read_bits, etc functions, it could instead just return the "thing" it got, and a flag. I.e. #define JB_OK 0 #define JB_EMPTY 1 #define JB_NOFRAME 2 #define JB_DROP 3 JB_OK means here's the frame for the timestamp you asked for. JB_EMPTY means the jitterbuff...

...o be a lot more work needed to get this where I'd like > it to go. And where would you like it to go? ;-) > At the API level, It seems pretty easy to make the speex > implementation become speex-independent. Instead of having > speex_jitter_get call any particular speex_decode or speex_read_bits, > etc functions, it could instead just return the "thing" it got, and a > flag. I.e. It's not as simple as it may look -- otherwise that's what I would have done. These are some of the things that you can't do easily if you "just return the thing": - Allow...

Danny Chan wrote: >Hi Jean and Steve, > >Can you tell me whether the jitter filter / buffer is adaptive type, I >saw the description of speex_jitter.h say it is "adaptive", anyone of >the group has implemented it and confirm it. > > I believe it is adaptive, but no, I haven't used it, because it's coupled only to the speex codec. We're working on a

...ed that there's always situations that you haven't properly accounted for when designing one. >>At the API level, It seems pretty easy to make the speex >>implementation become speex-independent. Instead of having >>speex_jitter_get call any particular speex_decode or speex_read_bits, >>etc functions, it could instead just return the "thing" it got, and a >>flag. I.e. >> >> > >It's not as simple as it may look -- otherwise that's what I would have >done. These are some of the things that you can't do easily if you &q...