[speex-dev] Speex settings and jitter

[Tom Grandgent]

[Just curious, and seizing the opportunity to communicate with 
other folks who are doing the same kind of thing I am...]

How are you measuring the latency?  I tried measuring it with my 
program (also Win32-based, also using DirectSound[Capture]) and came 
up with around 130ms.  To measure it, I placed the mic near a 
speaker to get feedback going, had my program connect to itself 
(local loopback), and made a sound into the mic.  The whole while 
I'd have CoolEdit recording from the mic.  So the sound would go:

Sound -> captured via mic -> transmitted (to itself) -> played via 
speaker -> captured via mic (quieter)

I measured the start-to-start time between the original sound and the 
"echoed" sound as indicated in CoolEdit and found it to be around 130ms.  
I'm not totally sure if this process results in a correct latency 
measurement, but I think it's ok...  I'm curious to know what you're 
doing.

My program is set up to use Speex in wideband mode, transmitting at 
a rate of 25 packets per second (two Speex frames per packet).  
Incoming packets are placed into a queue, and a playback thread 
receives notifications from DirectSound at an interval matching the 
amount of sound in a packet (40ms in this case).  When a notification 
is received, the playback thread attempts to remove a packet from the 
queue and copy it into the playback buffer ahead of the notified 
area.

Note that playback notifications on a secondary buffer are only 
reliable if you create the buffer as a software buffer!  I have 
witnessed the Audigy drivers screwing up notifications for buffers 
created in hardware.  Getting newer drivers helped but did not 
completely solve the problem.  My SB Live! Platinum, on the other 
hand, seems to work just fine...

Anyway, to handle jitter, the queue removal behavior is like this: 
If the playback buffering thread finds that the incoming packet queue 
is empty, it waits for at least two packets to be present in the queue 
before continuing to withdraw from it.  (In the meantime it inserts 
silence, though I'm going to change this to have Speex fabricate the 
missing data.)  When it successfully withdraws a packet from the 
queue, it will continue withdrawing until there is less than two 
packets in the queue.

The goal is to minimize latency but permit some amount of jitter by 
maintaining a "reserve" of one packet to draw upon in the event of 
delay or loss.  This seems to work well and is easily adjustable to 
more than one packet, if need be...

And as for the capture thread, it sleeps for 5ms and then looks at 
the location of the read cursor.  If there's enough new audio, it 
copies it out, encodes it, and transmits it.  Otherwise it goes back 
to sleep.  I was going to change this to use notifications but 
haven't yet since it's been working so well...  Are you saying that 
notifications aren't implemented for DirectSoundCapture buffers?

Tom

<p>John Hayes (jhayes at thereinc.com) wrote:
> 
> Right - and I deal with that on the receiver end based on an approximation
> of sender's and receiver's responsiveness - the minimum latency I've been
> able to get into the system is about 150 ms. Of that, jitter buffering is
> about 40-100ms. I'd love to figure out how to get that down without killing
> myself on thread switching or Win32 kernel calls, but ms has to actually
> implement the DSBCAPS_CTRLPOSITIONNOTIFY capability in direct sound capture
> ....
> 
> John
> 
> > -----Original Message-----
> > From: owner-speex-dev at xiph.org [mailto:owner-speex-dev at xiph.org]On
> > Behalf Of Allen Drennan
> > Sent: Tuesday, May 20, 2003 11:18 AM
> > To: speex-dev at xiph.org
> > Subject: RE: [speex-dev] Speex settings and jitter
> >
> >
> > In my experience most of the jitter related issues are because people are
> > using too small of audio buffer sizes that match the framing size
> > of Speex -
> > particularly in Windows.  This isn't a problem with Speex, but as a
> > programmer you should collect and append a few frames to match the size of
> > your output audio frame buffer before attempting to play the sound.
> > ...
--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'speex-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.