[pjsip] wav_player.c calls EOF callback twice
Jens Jorgensen
jbj1 at ultraemail.net
Thu Mar 11 17:43:44 CST 2010
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
More information about the pjsip
mailing list