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 >
