[Speex-dev] Prebuffering best practices

[Jean-Marc Valin]

I strongly suggest you start by reading the Speex manual (you can skip
the technical parts about CELP). If you still ask questions, then post
them.

	Jean-Marc

Le mardi 14 juin 2005 à 22:30 -0700, David Barrett a écrit :
> Ok, this is a silly question, but what does the jitter buffer do?  I'm 
> really new to audio, so please bear with me.
> 
>  From what I gather (primarily from the list archive), the jitter buffer 
> is a wrapper around the Speex decoder.  I give it the packets I receive, 
> in whatever order I receive them, and then it gives me back a clean 
> stream of audio samples.  But what I don't entirely understand is how 
> this is different from just working with the decoder directly.
> 
> Right now, I dump my RTP packets direct into the Speex decoder, and then 
> queue the output for playback.  This works reasonably well.
> 
> However, it doesn't accomodate dropped packets well.  If I drop samples 
> 10-20, I'll just queue 0-10 and then 20-30 immediately after, which 
> isn't great.  I think I read the jitter buffer will fabricate a fake 
> replacement for the missing samples 10-20, and thus improving quality of 
> playback.  Is this correct?
> 
> But what else does it do?  I see mention of "clock skew", but I don't 
> know what that means in this context.  What am I missing?  Most 
> importantly, what does it have to do with jitter, and how can I use it 
> to solve my problems?  Specifically:
> 
> 1) Assuming lossless, in-order, but highly irregular delivery of packets 
> (as I'm witnessing), what advantage does the jitter buffer offer over 
> going straight to the Speex decoder?
> 
> 2) Assuming samples arrive at an average rate of 22KHz, but arrive in a 
> highly irregular fashion, is there any way to ensure regular playback 
> other than to just wait some "prebuffer" duration before beginning 
> playback?  How do I pick the smallest prebuffer duration to accomodate a 
> given connection's jitter?
> 
> 3) Assuming I want to deliver samples at a rate of 22KHz, what's the 
> best graularity at which to encode and broadcast?  Granted, I need to 
> stay beneath the MTU.  But should I be going for the largest granularity 
> that fits under the MTU, or should I be going for the smallest 
> granularity that my CPU can churn out?
> 
> 
> Thanks!
> 
> -david
> 
> 
> Jean-Marc Valin wrote:
> > Have you looked at the Speex (adaptive) jitter buffer? See
> > speex_jitter.h
> > 
> > 	Jean-Marc
> >  
> > Le mardi 14 juin 2005 à 17:50 -0700, David Barrett a écrit :
> > 
> >>What is the best way to pick a prebuffering length for a streaming audio 
> >>application using UDP transport?
> >>
> >>I'm using Speex in a VoIP application with RTP transport, currently with 
> >>a fixed 500ms prebuffer on the playback side.  However, I'd like 
> >>something a bit more adaptive to accomodate high-jitter connections.
> >>
> >>For example, in one test configuration there is a very low average 
> >>round-trip latency (50ms), but it spikes all over the place (sometimes 
> >>10ms, sometimes 500ms).  Thus I can't make my prebuffer duration 
> >>proportional to latency, but somehow proportional to "jitter".  But I'm 
> >>not sure the best way to quantify this, nor how to tranform that into a 
> >>reasonable prebuffer length.
> >>
> >>Thus I'm curious what experience you've had in this area, and what you 
> >>can recommend as a good way to adaptively compute a prebuffer duration. 
> >>  Thanks!
> >>
> >>-david
> >>_______________________________________________
> >>Speex-dev mailing list
> >>Speex-dev at xiph.org
> >>http://lists.xiph.org/mailman/listinfo/speex-dev
> >>
> _______________________________________________
> 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>
Université de Sherbrooke