Hi, I've received reports of the following assertion failure: ../src/pjmedia/wav_player.c:554: file_get_frame: Assertion `fport->fmt_tag == PJMEDIA_WAVE_FMT_TAG_ULAW || fport->fmt_tag == PJMEDIA_WAVE_FMT_TAG_ALAW' failed file_get_frame seems to be called within the context of the soundcard thread (which makes sense). What I think is happening is that I'm calling pjmedia_port_destroy() on the port and pjsip_endpt_release_pool() on the pool containing it while the soundcard thread is in this function. My questions are: 1) Is this possible? 2) If so, what can I do to prevent this? Ruud Klaver AG Projects

Hi, I think it is very possible since wav player is not thread-safe (on purpose), so application needs to make sure that there is no access to wav player before destroying it, e.g: disconnect it from sound port, or remove the wav player port from conference. Regards, nanang On Wed, Apr 1, 2009 at 8:02 PM, Ruud Klaver <ruud@ag-projects.com> wrote: > Hi, > > I've received reports of the following assertion failure: > ../src/pjmedia/wav_player.c:554: > file_get_frame: Assertion `fport->fmt_tag == PJMEDIA_WAVE_FMT_TAG_ULAW > || fport->fmt_tag == PJMEDIA_WAVE_FMT_TAG_ALAW' > failed > > file_get_frame seems to be called within the context of the soundcard thread > (which makes sense). What I think is happening is that I'm calling > pjmedia_port_destroy() on the port and pjsip_endpt_release_pool() on the > pool  containing it while the soundcard thread is in this function. > > My questions are: > 1) Is this possible? > 2) If so, what can I do to prevent this? > > Ruud Klaver > AG Projects > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip@lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >

HI Nanang, Thanks for the reply. I was thinking about how to provide protection for it in my application, but I'm not sure how. I AM first disconnecting the sound port from all other ports on the conference and then removing it from the conference bridge before destroying the port. But in the meantime, the sound card thread may still be in the file_get_frame() function. There is no means to synchronize that it it got out of that function. The only thing I could do is set a timer to destroy the port a little later, but that doesn't sound like a real solution, as that still does not provide any sort of guarantee. Ruud Klaver AG Projects On 03 Apr 2009, at 15:56, Nanang Izzuddin wrote: > Hi, > > I think it is very possible since wav player is not thread-safe (on > purpose), so application needs to make sure that there is no access to > wav player before destroying it, e.g: disconnect it from sound port, > or remove the wav player port from conference. > > Regards, > nanang > > > On Wed, Apr 1, 2009 at 8:02 PM, Ruud Klaver <ruud@ag-projects.com> > wrote: >> Hi, >> >> I've received reports of the following assertion failure: >> ../src/pjmedia/wav_player.c:554: >> file_get_frame: Assertion `fport->fmt_tag == >> PJMEDIA_WAVE_FMT_TAG_ULAW >> || fport->fmt_tag == PJMEDIA_WAVE_FMT_TAG_ALAW' >> failed >> >> file_get_frame seems to be called within the context of the >> soundcard thread >> (which makes sense). What I think is happening is that I'm calling >> pjmedia_port_destroy() on the port and pjsip_endpt_release_pool() >> on the >> pool containing it while the soundcard thread is in this function. >> >> My questions are: >> 1) Is this possible? >> 2) If so, what can I do to prevent this? >> >> Ruud Klaver >> AG Projects >> >> _______________________________________________ >> Visit our blog: http://blog.pjsip.org >> >> pjsip mailing list >> pjsip@lists.pjsip.org >> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >> > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip@lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org

Hi, If your app is using conf bridge, then the scenario should be safe. Conf bridge already provides protection (with mutex) on conf ports accesses, so sound thread(s) and app thread (that does disconnecting/removing conf ports) should be safely synchronized. (Btw, while checking the code, I just found a bug in conf_switch.c regarding accessing port without mutex in its put_frame(), however I don't really think this is related to this problem). Regards, nanang On Fri, Apr 3, 2009 at 10:10 PM, Ruud Klaver <ruud@ag-projects.com> wrote: > HI Nanang, > > Thanks for the reply. > > I was thinking about how to provide protection for it in my application, but > I'm not sure how. I AM first disconnecting the sound port from all other > ports on the conference and then removing it from the conference bridge > before destroying the port. But in the meantime, the sound card thread may > still be in the file_get_frame() function. There is no means to synchronize > that it it got out of that function. The only thing I could do is set a > timer to destroy the port a little later, but that doesn't sound like a real > solution, as that still does not provide any sort of guarantee. > > Ruud Klaver > AG Projects > > On 03 Apr 2009, at 15:56, Nanang Izzuddin wrote: > >> Hi, >> >> I think it is very possible since wav player is not thread-safe (on >> purpose), so application needs to make sure that there is no access to >> wav player before destroying it, e.g: disconnect it from sound port, >> or remove the wav player port from conference. >> >> Regards, >> nanang >> >> >> On Wed, Apr 1, 2009 at 8:02 PM, Ruud Klaver <ruud@ag-projects.com> wrote: >>> >>> Hi, >>> >>> I've received reports of the following assertion failure: >>> ../src/pjmedia/wav_player.c:554: >>> file_get_frame: Assertion `fport->fmt_tag == PJMEDIA_WAVE_FMT_TAG_ULAW >>> || fport->fmt_tag == PJMEDIA_WAVE_FMT_TAG_ALAW' >>> failed >>> >>> file_get_frame seems to be called within the context of the soundcard >>> thread >>> (which makes sense). What I think is happening is that I'm calling >>> pjmedia_port_destroy() on the port and pjsip_endpt_release_pool() on the >>> pool  containing it while the soundcard thread is in this function. >>> >>> My questions are: >>> 1) Is this possible? >>> 2) If so, what can I do to prevent this? >>> >>> Ruud Klaver >>> AG Projects >>> >>> _______________________________________________ >>> Visit our blog: http://blog.pjsip.org >>> >>> pjsip mailing list >>> pjsip@lists.pjsip.org >>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >>> >> >> _______________________________________________ >> Visit our blog: http://blog.pjsip.org >> >> pjsip mailing list >> pjsip@lists.pjsip.org >> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip@lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >