search for: jitter_buffer_tick

Hi. After changing my code to construct a JitterBufferPacket and passing that to speex_jitter_put, my program works with the new jitter buffer using the wrapper functions (speex_jitter_* instead of the new jitter_buffer_*). However, a lot of warning: did you forget to call jitter_buffer_tick() by any chance? is displayed. Looking at speex_jitter_get, the logic seems to be as follows: if there is another frame in the previously fetched packet, decode it and call jitter_buffer_tick else get a new packet and decode first frame. But when a new packet is fetched, jitter_buffer_tick isn&...

...ith the new jitter buffer using the > wrapper functions (speex_jitter_* instead of the new jitter_buffer_*). Oops, I forgot to make sure I keep the API stable for the old buffer. Any thoughts on the change (revert or continue as is)? > However, a lot of > warning: did you forget to call jitter_buffer_tick() by any chance? > is displayed. > > Looking at speex_jitter_get, the logic seems to be as follows: > > if there is another frame in the previously fetched packet, decode it and > call jitter_buffer_tick > > else get a new packet and decode first frame. > > But whe...

...there a better recommended strategy for handling one versus the other? Am I correct that calling jitter_buffer_update_delay might eventually cause one or more buffered packets to be skipped? And in any case, what are the implications of having auto_adjust change the delay on every call to jitter_buffer_tick versus speex_jitter_buffer.c's strategy of making it contingent upon the "activity level" of the last frame? Is this equivalent to shrinking the buffer using some form of silence detection? Thank you very much in advance. Zach --------------------------------------- Zachary...

...f (320 == maxLength) { JitterBufferPacket packet; packet.data = buffer; m_Mutex.Aquire(); ret = jitter_buffer_get(m_JitterBuffer, &packet, 0); if(ret != JITTER_BUFFER_OK) { ZeroMemory(packet.data, maxLength); } jitter_buffer_tick(m_JitterBuffer); jitter_buffer_update_delay(m_JitterBuffer, &packet, NULL); m_Mutex.Release(); } else { ZeroMemory(buffer, maxLength); } }

...er; >> >> m_Mutex.Aquire(); >> >> ret = jitter_buffer_get(m_JitterBuffer, &packet, 0); >> >> if(ret != JITTER_BUFFER_OK) >> { >> ZeroMemory(packet.data, maxLength); >> } >> >> jitter_buffer_tick(m_JitterBuffer); >> jitter_buffer_update_delay(m_JitterBuffer, &packet, NULL); >> m_Mutex.Release(); >> } >> else >> { >> ZeroMemory(buffer, maxLength); >> } >> } >> >> _________________________________...

...t packet; > packet.data = buffer; > > m_Mutex.Aquire(); > > ret = jitter_buffer_get(m_JitterBuffer, &packet, 0); > > if(ret != JITTER_BUFFER_OK) > { > ZeroMemory(packet.data, maxLength); > } > > jitter_buffer_tick(m_JitterBuffer); > jitter_buffer_update_delay(m_JitterBuffer, &packet, NULL); > m_Mutex.Release(); > } > else > { > ZeroMemory(buffer, maxLength); > } > } > > _______________________________________________ > Speex-dev mailing l...

...ssue, the two cases could be implemented differently. > Am I correct that calling jitter_buffer_update_delay might eventually > cause one or more buffered packets to be skipped? And in any case, > what are the implications of having auto_adjust change the delay on > every call to jitter_buffer_tick versus speex_jitter_buffer.c's > strategy of making it contingent upon the "activity level" of the last > frame? Is this equivalent to shrinking the buffer using some form of > silence detection? If you let the jitter manage the delay by itself, it will just insert/del...

...it would be better to change it so the API is same. I must say I really like the generalized jitter buffer though :) It's a cleaner and more flexible implementation and can more easily be adjusted to contain additional information with each packet. >> But when a new packet is fetched, jitter_buffer_tick isn't called, so if I >> only have one frame per packet, it will never be called. >> >> Is this a bug in speex_jitter_get, or am I doing something wrong? > > This is definitely a bug in speex_jitter_get() because it hasn't been > updated for changes in the "g...

....Aquire(); >>> >>> ret = jitter_buffer_get(m_JitterBuffer, &packet, 0); >>> >>> if(ret != JITTER_BUFFER_OK) >>> { >>> ZeroMemory(packet.data, maxLength); >>> } >>> >>> jitter_buffer_tick(m_JitterBuffer); >>> jitter_buffer_update_delay(m_JitterBuffer, &packet, NULL); >>> m_Mutex.Release(); >>> } >>> else >>> { >>> ZeroMemory(buffer, maxLength); >>> } >>> } >>> >&g...

...emote clock and how do you define those anyway? > > There's the "timestamp", which the remote side puts on frames, and > the local time, which is used for jb_put and jb_get. They're defined > in milliseconds. I think this is equivalent to what I'm doing with jitter_buffer_tick(), except that my approach doesn't require explicit knowledge of the local time (I don't care what the local time is, just how it's incremented). Also, I think milliseconds (which I used before) is bad because 1) RTP uses the sampling clock and 2) in many cases, it's not an integer....

...a+length))) == 0 ) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{ > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?length += BYTES_PER_FRAME; > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?samples -= SAMPLES_PER_FRAME; > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?--frames; > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?jitter_buffer_tick( jitter ); > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?lost_frames = 0; > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?} > > You can ignore the lost_frames. That just gets incremented if there isn't > data in the jitter buffer and once enough frames have been lost, it starts > buffering data (...

...omatically disable auto-adjustment */ @@ -743,12 +743,12 @@ } /** Get pointer timestamp of jitter buffer */ -int jitter_buffer_get_pointer_timestamp(JitterBuffer *jitter) +EXPORT int jitter_buffer_get_pointer_timestamp(JitterBuffer *jitter) { return jitter->pointer_timestamp; } -void jitter_buffer_tick(JitterBuffer *jitter) +EXPORT void jitter_buffer_tick(JitterBuffer *jitter) { /* Automatically-adjust the buffering delay if requested */ if (jitter->auto_adjust) @@ -764,7 +764,7 @@ jitter->buffered = 0; } -void jitter_buffer_remaining_span(JitterBuffer *jitter, spx_uint32_t...

...omatically disable auto-adjustment */ @@ -743,12 +743,12 @@ } /** Get pointer timestamp of jitter buffer */ -int jitter_buffer_get_pointer_timestamp(JitterBuffer *jitter) +EXPORT int jitter_buffer_get_pointer_timestamp(JitterBuffer *jitter) { return jitter->pointer_timestamp; } -void jitter_buffer_tick(JitterBuffer *jitter) +EXPORT void jitter_buffer_tick(JitterBuffer *jitter) { /* Automatically-adjust the buffering delay if requested */ if (jitter->auto_adjust) @@ -764,7 +764,7 @@ jitter->buffered = 0; } -void jitter_buffer_remaining_span(JitterBuffer *jitter, spx_uint32_t...

Alright noted, I changed me code so that the state is created in the constructor and destroyed in the destructor of the object. However I'm still getting the same issue although I'm sure that would have bit me sooner or later. The new code is as follows. virtual Enigma::u8* Encode(Enigma::u8* inputBuffer,size_t inputSize, size_t& outputSize) { short *in=(short*)inputBuffer;

...do you define those anyway? >> >> There's the "timestamp", which the remote side puts on frames, and >> the local time, which is used for jb_put and jb_get. They're defined >> in milliseconds. > > I think this is equivalent to what I'm doing with jitter_buffer_tick > (), > except that my approach doesn't require explicit knowledge of the > local > time (I don't care what the local time is, just how it's incremented). > Also, I think milliseconds (which I used before) is bad because 1) RTP > uses the sampling clock and 2) in ma...

...*)((char*)data+length))) == 0 ) { length += BYTES_PER_FRAME; samples -= SAMPLES_PER_FRAME; --frames; jitter_buffer_tick( jitter ); lost_frames = 0; } You can ignore the lost_frames. That just gets incremented if there isn't data in the jitter buffer and once enough frames have been lost, it starts buffering data (and so playing silenc...

> Yes. Jean-Marc has made the API more similar. > > Jean-Marc: Have you looked at the API we have for the > asterisk/iaxclient jitterbuffer? Just did. > It's pretty close to what you have now -- the major difference is that > your jb still assumes it can "own" the data passed in -- it copies it, > and it destroys it at will. With the API I put together,