Changes between Version 2 and Version 3 of audio-check-sound-device-jitter


Ignore:
Timestamp:
Dec 6, 2006 1:19:39 PM (14 years ago)
Author:
bennylp
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • audio-check-sound-device-jitter

    v2 v3  
    1313Some problems with sound device: 
    1414 
    15  1. '''Jitter''': 
    16   Common problem with most sound device is the jitter. Where for example PJMEDIA expects audio frames to be delivered at exactly 20ms interval, the sound device (or driver) may deliver it at 10ms, 10ms, 30ms, 30ms, etc. Normally the total number of frames delivered will match the clock rate (i.e. there's no lost frames), but it's just that these frames are not delivered in timely manner. 
    17  1. '''Burst''': 
    18   A worsening problem with the jitter is bursting, where the sound device (or driver) delivers the audio frame in burst and then followed by silent period, and burst again. If the sound device is open in full-duplex mode, this would normally cause the recorder callback to be called in burst of several calls, then followed by burst call to the playback callback, and back to burst call to the recorder callback, and so on. 
    19  1. '''Underflows''' and '''Overflows''': 
    20   Another problem with audio application is underflows and overflows, where application is not processing the audio frames quickly enough. 
    21  1. '''Clock drifting''': 
    22   A not so common problem with some sound device is clock drifting, where the sound device is not delivering audio samples at the exact clock rate. For example, when the sound device is opened at 8KHz, the sound device may deliver a little less or more than 8000 samples per second. 
     15=== Jitter === 
     16Common problem with most sound device is the jitter. Where for example PJMEDIA expects audio frames to be delivered at exactly 20ms interval, the sound device (or driver) may deliver it at 10ms, 10ms, 30ms, 30ms, etc. Normally the total number of frames delivered will match the clock rate (i.e. there's no lost frames), but it's just that these frames are not delivered in timely manner. 
     17 
     18An audio jitter in the capture direction will cause outgoing RTP packet to be delivered in uneven time. This shouldn't cause too much problem because remote should be able to accomodate the jitter. 
     19 
     20An audio jitter in playback direction shouldn't cause any problem, AFAIK. 
     21 
     22 
     23=== Burst === 
     24A worsening problem with the jitter is bursting, where the sound device (or driver) delivers the audio frame in burst and then followed by silent period, and burst again. If the sound device is open in full-duplex mode, this would normally cause the recorder callback to be called in burst of several calls, then followed by burst call to the playback callback, and back to burst call to the recorder callback, and so on. 
     25 
     26PJMEDIA should be capable of handling audio burst to some level. For example, the conference bridge is able to accomodate up to eight frame burst. 
     27 
     28 
     29=== Underflows Overflows === 
     30Another problem with audio application is underflows and overflows, where application is not processing the audio frames quickly enough. When underflow or overflow occurs in the playback direction, you would hear a click sound in the speaker. 
     31 
     32The PortAudio audio abstraction in PJMEDIA prints the number of underflow/overflow when the sound device is closed. With pjsua, you need to set the log level to 5 ('''{{{--app-log-level 5}}}'''), and when the application exits the underflow/overflow statistic will be printed to console/log. 
     33 
     34 
     35=== Clock drifting === 
     36A not so common problem with some sound device is clock drifting, where the sound device is not delivering audio samples at the exact clock rate. For example, when the sound device is opened at 8KHz, the sound device may deliver a little less or more than 8000 samples per second. 
    2337 
    2438 
     
    6074}}} 
    6175 
     76The output above shows that there are jitters from both playback and capture streams, but there is no clock drifts. From experience, a 32ms jitter should be okay as PJMEDIA should be able to accomodate this. But if you have higher jitter value and experience audio problems, then perhaps it would be worth to consult the mailing list and see what others think about the result. 
    6277 
     78