4
\$\begingroup\$

For example, suppose my code can determine that upstream bandwidth is unusually limited. And suppose I'm using a fully-connected mesh topology combined with a UDP-like protocol for voice chat. Is there an established way to reduce the risk of packet loss so that the voice playback will either be solid or muted, but not jittery or choppy? This must be a solved problem in the VoIP world, but I'm not sure where to look.

EDIT: To clarify my abuse of the term jitter: I mean, if two UDP voice packets arrive out of order, the audio would sound jittery in a colloquial sense (i.e. I mean packet jitter, not audio signal displacement). The choppy sound I'm referring to is related, where a UDP packet is lost instead of arriving late and causes a gap or jump in the audio.

When I refer to muting the playback, I don't mean as a function of source input to avoid background noise. I mean on the receiving end of the conversation, if there's high packet loss, just stop playback instead of playing choppy audio.

Improve this question
\$\endgroup\$
3
  • \$\begingroup\$ In the 'VoIP world', jitter control is a function of the specific codec employed. Buffers are used to 'pad' voice data to avoid jitter. Playback is attempted to be transmitted no matter what and never muted. Which codecs have you tried / implemented? As an afterthought, you could monitor the jitter buffers and 'mute' audio if the buffer level goes below a threshold. \$\endgroup\$
    – DrDeth
    Aug 15, 2010 at 21:34
  • \$\begingroup\$ I abused the term jitter, which led to confusion. Sorry. I updated the question to clarify. The API I'm coding to is pretty robust, so the codec end of things works fine. \$\endgroup\$
    – BRaffle
    Aug 16, 2010 at 14:00
  • \$\begingroup\$ After doing some more reading, I think understand what you're saying now with regard to using buffers to pad voice data and avoid jitter. That makes sense, thanks! It sounds effective but complicated to properly implement. \$\endgroup\$
    – BRaffle
    Aug 16, 2010 at 14:04

1 Answer 1

Reset to default
1
\$\begingroup\$

I'd recommend implementing the Real-time Transport Protocol (RTP), or something similar that suites your needs. It includes Quality of Service (QoS) monitoring with the RTP Control Protocol (RTCP) for minimizing "jittery" and "choppy" effects with audio streams.

Even if you don't need all the features of the protocol, it is worth investigating to see an example of how the issues you are experiencing are solved. However, you'll likely have to weigh the choppy/jittery effects against latency if the codec remains static. The consistency of the audio is improved by buffering and buffering takes time.

Improve this answer
\$\endgroup\$
1

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .