[pjsip] Problem with PJMEDIA's play callback

Nanang Izzuddin nanang at pjsip.org
Fri Mar 20 12:32:34 EDT 2009


Hi,

Basically, it should be fine calling the play_cb() N times
consecutively (burst) as long as the supplier can catch up the
burstiness.

>From the log snippet, it seems that your app were using conference
bridge (or pjsua) and performed sound device loopback (connect port 0
to 0). The conference bridge do the mic-speaker synchronization using
delaybuf, where the frames from mic/input is buffered by delaybuf
before consumed by the speaker/output. The problem may be initiated by
this delaybuf, which by default it can only buffer max 6 frames
(specified by PJMEDIA_SOUND_BUFFER_COUNT macro), in other word it can
only handles 6 frames burst at best condition. So, if this is the
case, increasing the PJMEDIA_SOUND_BUFFER_COUNT to the maximum
possible burst level may solve the problem.

Regards,
nanang


On Fri, Mar 20, 2009 at 5:00 AM, Jurij Smakov <jurij at wooyd.org> wrote:
> Hi,
>
> I'm in the process of porting PJSIP to an ARM-based device, and I ran
> into a problem with sound playback, which I was not able to figure out
> so far. The device's sound API requires me to completely fill a
> fixed-sized playback buffer with samples, which I receive by calling
> the PJMEDIA's play_cb callback. The size of the buffer is larger than
> size of the frame which play_cb returns, so normally 6 or 7 calls to
> play_cb are required to fill the device's buffer. The problem is that
> if I do so many callback calls in a loop, I inevitably get a few log
> messages like that:
>
>  08:32:42.082   Master/sound  Underflow, buf_cnt=0, will generate 1 frame
>  08:32:42.083   Master/sound  Underflow, buf_cnt=0, will generate 1 frame
>  08:32:42.086   Master/sound  Underflow, buf_cnt=0, will generate 1 frame
>  08:32:42.088   Master/sound  Underflow, buf_cnt=0, will generate 1 frame
>  08:32:42.088   Master/sound  Underflow, buf_cnt=0, will generate 1 frame
>  08:32:42.091   Master/sound  Underflow, buf_cnt=0, will generate 1 frame
>  08:32:42.112   Master/sound  Underflow, buf_cnt=0, will generate 1 frame
>
> I assume that I'm asking for more data than PJMEDIA layer currently
> has, and it generates some frames in order to keep up with data
> requests. Not sure what algorithm is used to generate them, but it
> results in a pretty choppy sound, with a few interruptions per second.
> That's my analysis of the problem anyway, I could be completely wrong
> :-).
>
> What I would like to do it is somehow instruct the PJMEDIA layer to
> just wait for more sound samples to become available, instead of
> returning the generated frames, when it is out of it. However, I could
> not really find a mechanism to do it by looking at the code: the
> play_cb callback is non-blocking (as far as I can tell) and always
> returns PJ_SUCCESS, independently of whether the data it returns was
> real or generated. I've looked at some other sound drivers (like
> pasound.c), and it appears that they use pretty much the same
> algorithm, i.e. calling the play_cb callback multiple times to fill up
> the buffer. So, presumably, it should work somehow, so it's possible
> that I'm doing something wrong. Any ideas would be appreciated.
>
> Thanks.
> --
> Jurij Smakov                                           jurij at wooyd.org
> Key: http://www.wooyd.org/pgpkey/                      KeyID: C99E03CC
>
> _______________________________________________
> Visit our blog: http://blog.pjsip.org
>
> pjsip mailing list
> pjsip at lists.pjsip.org
> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>



More information about the pjsip mailing list