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

[Baldvin Hansson]

[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:

READ UDP
PUT IN JITTER
READ FROM JITTER
FEED TO SOUND CARD
REPEAT

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