Yeah, I did this same patch but the thing is Benny already indicated he didn't want to re-enable this code going forward so this fix isn't maintainable. (No matter how sensible it might seem to me! ;-) ) I guess maybe there's a use case where the "device" is not a wav player and could return EOF but then later return an audio frame?). David Clark wrote: > It's not right and left the way it is if the application is slow to > call player destory the notifications of EOF can be so rapid they eat > the cpu and nothing else happens. > Solution is easy. conference.c around line 1863 you see a read_port > function call. Then you see a small block of code benny commented > out. That will > disable the port if !PJ_SUCCESS is returned. Put that back in. > > Worked for me. > > > At 06:21 PM 3/8/2010, Ryan Littrell wrote: >> Yes, thanks for your reply. I think the original author wrote this >> callback to an earlier pjsip version that had a different behavior >> back then. I have since mimicked the behavior of the --play-wav's >> callback behavior (destory player, and use PJ_UNUSED_ARG(media_port); >> PJ_UNUSED_ARG(args); ) >> >> Not sure if this is entirely correct and bug free... we will see.. >> >> Ryan >> >> On Mon, Mar 8, 2010 at 4:01 PM, Jens Jorgensen <jbj1 at ultraemail.net >> <mailto:jbj1 at ultraemail.net>> wrote: >> >> Yes, it seems this is a feature :-) I believe the correct thing >> to do is >> in fact to destroy the player inside your callback. I'm not sure why >> this causes a crash for you, this is what I do in my code (using >> pjproject svn rev 3087) and it is working fine. See Benny's helpful >> reply to me on this same topic here: >> >> http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/2009-October/009069.html >> >> >> (Did you RTF list archives ;-) ?) >> >> Incidentally, I solved your problem a different way (ie. within the >> callback you need the call id and the player id) but maybe this >> indicates that having this context is generally useful and could be >> added to the code base. >> >> Ryan Littrell wrote: >> > I'm using a local build sipek sdk and pjsip trunks. I noticed >> in the >> > log the wav player calls the EOF callback twice. In the second >> call, >> > the free(args) fails. Any thoughts? >> > >> > Log: >> > >> > 01:13:36.849 pjsipDll_playW Wav Play, status 0 >> > 01:13:36.922 strm06B1F80C Start talksprut.. >> > 01:13:45.029 strm06B1F80C Starting silence >> > 01:13:45.429 strm06B1F80C Start talksprut.. >> > 01:13:45.433 strm06B1F80C Starting silence >> > 01:13:45.629 wav_player.c File port >> > D:\Projects\WindowsFormsApplication1\bin\Debug\0.wav EOF >> > 01:13:45.632 pjsipDll_playW on_wavplayerEof_callback, media_port: >> > 112313596 >> > 01:13:45.633 pjsipDll_playW End of Wav File, media_port: >> 112313596 >> > 01:13:45.671 wav_player.c File port >> > D:\Projects\WindowsFormsApplication1\bin\Debug\0.wav EOF >> > 01:13:45.672 pjsipDll_playW on_wavplayerEof_callback, media_port: >> > 112313596 >> > >> > >> > EOF Code: >> > >> > static PJ_DEF(pj_status_t) on_wavplayerEof_callback(pjmedia_port* >> > media_port, void* args) >> > { >> > PJ_LOG(3,(THIS_FILE, "on_wavplayerEof_callback, media_port: >> > %d", media_port)); >> > pj_status_t status; >> > wavplayerEof_Data* WavePlayerData = >> ((wavplayerEof_Data*) args); >> > >> > // Read info from args >> > pjsua_call_id call_id = WavePlayerData->callId; >> > pjsua_player_id player_id = WavePlayerData->playerId; >> > >> > //Destroy the Wav Player >> > //status = pjsua_player_destroy(player_id); // ! >> Problem if >> > Destroying Here : cash at the end of callback, for most of wavs >> files >> > >> > // Free the memory allocated for the args >> > free(args); >> > >> > PJ_LOG(3,(THIS_FILE, "End of Wav File, media_port: %d", >> > media_port)); >> > // Invoke the Callback for C# managed code >> > if (cb_wavplayerEnded != 0) >> > (*cb_wavplayerEnded)(call_id, player_id); >> > >> > if (status == PJ_SUCCESS) // Player correctly Destroyed >> > return -1; // Don't return >> > PJ_SUCCESS, to prevent crash when returning from callback after >> Player >> > Destruction >> > >> > return PJ_SUCCESS; // Else, return PJ_SUCCESS >> > >> > } //// -> goes back to the function wich has invoke the >> callback >> > : fill_buffer() in pjmedia\src\pjmedia\wav_player.c >> > ///// CRASH HERE WITH MOST OF WAV FILES, if player has >> been >> > destroyed above //// >> > >> ------------------------------------------------------------------------ >> > >> > _______________________________________________ >> > Visit our blog: http://blog.pjsip.org >> > >> > pjsip mailing list >> > pjsip at lists.pjsip.org <mailto:pjsip at lists.pjsip.org> >> > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >> > >> >> >> -- >> Jens B. Jorgensen >> jbj1 at ultraemail.net <mailto:jbj1 at ultraemail.net> >> >> >> _______________________________________________ >> Visit our blog: http://blog.pjsip.org >> >> pjsip mailing list >> pjsip at lists.pjsip.org <mailto:pjsip at lists.pjsip.org> >> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >> >> >> _______________________________________________ >> 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 > ------------------------------------------------------------------------ > > _______________________________________________ > 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 > -- Jens B. Jorgensen jbj1 at ultraemail.net
