Checking the Quality of the Sound Device (moved)

Moved to ​https://docs.pjsip.org/en/latest/specific-guides/audio-troubleshooting/checks/dev_quality.html

In the worst case, some of the audio problems may come from the sound device itself, causing problems such as:

• audio stutters,
• audio break-ups.

It may not be the sound device itself that causing the problem, but could be the operating system driver for the device. For example, on Linux, the ALSA driver tends to have a very good quality while using OSS driver for the same device would give a less satisfactory result.

It is also observed from the mailing list discussions that many embedded Linux device with on-board sound adapter give a bad audio quality with OSS driver, although normally it would play a WAV file fine. We conclude that these sound adapter (or the driver) is not really designed for streaming, bidirectional communication like audio call, but rather for trivial tasks like playing a file to the speaker.

Sound Device Problems

Some problems with sound device:

Jitter

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.

An 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.

An audio jitter in playback direction shouldn't cause any problem, AFAIK.

Burst

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.

PJMEDIA should be capable of handling audio burst to some level. For example, the conference bridge is able to accomodate up to eight frame burst.

Underflows Overflows

Another 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.

The 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.

Clock drifting

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.

Testing the Sound Device

You can use sndtest sample to test the performance of the sound device/driver in your platform. The sndtest binary should be placed in pjsip-apps/bin/samples directory after the samples project is successfully built.

To run the sndtest application to test the default sound device:

 $ ./sndtest

The test will run for few seconds, and at the end it will display output similar to the snippet below:

 13:06:18.652      sndtest.c Found 8 devices:
 13:06:18.672      sndtest.c  0: Primary Sound Capture Driver (capture=2, playback=0)
 13:06:18.682      sndtest.c  1: Crystal SoundFusion(tm) (capture=2, playback=0)
 13:06:18.692      sndtest.c  2: Primary Sound Driver (capture=0, playback=2)
 13:06:18.702      sndtest.c  3: Crystal SoundFusion(tm) (capture=0, playback=2)
 13:06:18.712      sndtest.c  4: Microsoft Sound Mapper - Input (capture=2, playback=0)
 13:06:18.722      sndtest.c  5: Crystal SoundFusion(tm) (capture=2, playback=0)
 13:06:18.732      sndtest.c  6: Microsoft Sound Mapper - Output (capture=0, playback=2)
 13:06:18.742      sndtest.c  7: Crystal SoundFusion(tm) (capture=0, playback=2)
 13:06:18.752      sndtest.c Testing Primary Sound Capture Driver
 13:06:19.002      sndtest.c  Please wait while test is in progress (~11 secs)..
 13:06:30.078      sndtest.c  Dumping results:
 13:06:30.088      sndtest.c   Parameters: clock rate=8000Hz, 80 samples/frame
 13:06:30.088      sndtest.c   Playback stream report:
 13:06:30.098      sndtest.c    Duration: 10s.120
 13:06:30.098      sndtest.c    Frame interval: min=0.006ms, max=32.475ms
 13:06:30.108      sndtest.c    Jitter: min=9.990ms, avg=23.530ms, max=32.467ms
 13:06:30.108      sndtest.c   Capture stream report:
 13:06:30.118      sndtest.c    Duration: 9s.990
 13:06:30.118      sndtest.c    Frame interval: min=0.006ms, max=32.480ms
 13:06:30.128      sndtest.c    Jitter: min=9.722ms, avg=23.706ms, max=32.472ms
 13:06:30.128      sndtest.c   Checking for clock drifts:
 13:06:30.138      sndtest.c    No clock drifts is detected
 13:06:30.138      sndtest.c  Test completed with some warnings

The 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.