Problem with PJMEDIA's play callback

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Asterisk Users]     [Asterisk App Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [Linux API]
  Powered by Linux