[speex-dev] Speex settings and jitter
tgrand at canvaslink.com
Tue May 20 13:28:11 PDT 2003
[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
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
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?
<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
> > -----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.
More information about the Speex-dev