[Speex-dev] What to do when speex_jitter_get(...) has no buffer to return

Jean-Marc Valin Jean-Marc.Valin at USherbrooke.ca
Wed Jun 8 12:39:03 PDT 2005

The thing you're forgetting is that normally, the write to the soundcard
is blocking and will block for the same time it will take to receive a
new packet. If you're using 20 ms frames, then you'll likely receive 50
packets per second and if you're timed on the soundcard, you'll call
speex_jitter_get about 50 times per second too. If there's a slight
difference in the sampling rate or the network delay changes, the jitter
buffer will compensate for that and maintain a low delay.

As for the speex_jitter_get_pointer_timestamp() function, you don't have
to use it if you don't need it. The idea is that it allows
synchronization of other stuff (e.g. image) with the audio.


Le mardi 07 juin 2005 à 23:38 +0000, Baldvin Hansson a écrit :
> [The following is perhaps a long question and even off-speex topic,]
> [but if anyone can at least point me in the right direction for    ]
> [alternate sources of information, I'd really appreciate it.       ]
> When speex_jitter_get(...) is called and there is no buffer/data to
> return, would I not want to know that there is no true data to play?
> If I turn around and queue 20ms of silence to play for the sound-card,
> the sound card will never be able to "catch-up" with the datastream when
> it starts to feed actual voice data?
> The above question may be a horrible manifestation of what I'm actually
> trying to ask (the question is very clear in about 3000 words in my
> head) but to perhaps explain better, this is what my app is doing now
> (with fairly good results when no data goes missing in transport:
> Network thread:
> 	1) Wait until UDP packet available then Read it
> 	2) Call PUT function to save to jitter buffer
> 	3) Trigger sound-card thread
> 	4) goto 1
> Sound-card thread:
> 	1) Wait until triggered by Network thread
> 	2) Call GET function to get data from jitter buffer
> 	3) Feed this data to the sound-card for playback
> 	4) goto 1
> A typical session would go:
> Now, with this implementation, when a network packet goes "missing", the
> trigger to the sound card thread is not called for one "cycle". This
> would mean that the sound card would never play the (hopefully)
> available queued packets in the jitter buffer.
> If I however let the sound card thread "run free", calling the
> speex_jitter_get(...) faster than the packets are coming in, I'll just
> be feeding the sound card with a ton of 20ms silent packets which it
> needs to finish playing before it can get to playing buffers that
> contain data decoded from the UDP stream.
> With my original question (way up at the top of this email), if I knew
> that there was no data returned from the jitter buffer, I could skip
> feeding it to the sound card and thus the sound card would be able to
> "catch up" on the playing of samples from the UDP stream received via
> the jitter buffer mechanism.
> Sincerely,
> Baldvin
> _______________________________________________
> Speex-dev mailing list
> Speex-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/speex-dev

Jean-Marc Valin <Jean-Marc.Valin at USherbrooke.ca>
Universite de Sherbrooke

More information about the Speex-dev mailing list