Yes I have some clue... It seems to have a relation with pjsua_player_set_pos --> pjmedia_wav_player_port_set_pos. This one does manipulate the fpos and then does again a fill_buffer(). The problem here is, that fport->data_left (which keeps track how much of the audio-chain is already readed) is not updated with any file position manipulation. So any update on file position after a port creation will decrease the data_left with buffer_size amount (4k). Having said this... I also think that the 16-bit PCM files do might have problems with this. But because our application is calling the set_pos only once, and 16-bit PCM is much bigger, the cut-off was not observed in our case case. I'm investigating it further, but still appreciate any input... With regards, Eize Slange -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20111020/d5daaf80/attachment.html>
