Hi Pedro,
Looking into this stack trace:
MyApp.exe!pj_bzero(void * dst=0xfeeefeee, unsigned int size=1600) Line
601 + 0xf bytes C
MyApp.exe!get_frame(pjmedia_port * this_port=0x03713d20, pjmedia_frame
* frame=0x0712f784) Line 1720 + 0x16 bytes C
The location seems to be in get_frame() of conference.c, so the 'dst' of
pj_bzero (whose value==0xfeeefeee) should be 'conf_port->mix_buf'. Since
accessing conf_port in conference bridge is always guarded by mutex, the
reasons of conf_port->mix_buf having invalid value (0xfeeefeee) are:
- early release of pool. e.g: pool that is used for calling
pjmedia_conf_add_port, this pool is used for allocating conf_port->mix_buf.
- there is buffer overrun somewhere in your app.
Regards,
nanang
2008/7/9 Pedro Gon?alves <pedro.pandre at gmail.com>:
> Benny Prijono wrote:
>
> On Tue, Jul 8, 2008 at 11:37 AM, Pedro Gon?alves <pedro.pandre at gmail.com>
> wrote:
>
>>
>> Sorry for the previous short description.
>> The complete stack trace is:
>>
>> MyApp.exe!pj_bzero(void * dst=0xfeeefeee, unsigned int size=1600)
>> Line 601 + 0xf bytes C
>> MyApp.exe!get_frame(pjmedia_port * this_port=0x03713d20,
>> pjmedia_frame * frame=0x0712f784) Line 1720 + 0x16 bytes C
>> MyApp.exe!pjmedia_port_get_frame(pjmedia_port * port=0x03713d20,
>> pjmedia_frame * frame=0x0712f784) Line 67 + 0x12 bytes C
>> > MyApp.exe!play_cb(void * user_data=0x0583d9e8, unsigned int
>> timestamp=331600, void * output=0x016ad6f0, unsigned int size=800) Line 130
>> + 0xd bytes C
>> MyApp.exe!PaPlayerCallback(const void * input=0x00000000, void *
>> output=0x016ad6f0, unsigned long frameCount=400, const
>> PaStreamCallbackTimeInfo * timeInfo=0x0712fd08, unsigned long statusFlags=0,
>> void * userData=0x05888824) Line 263 + 0x2a bytes C
>> MyApp.exe!AdaptingOutputOnlyProcess(PaUtilBufferProcessor *
>> bp=0x016ad5a0, int * streamCallbackResult=0x0712fda4,
>> PaUtilChannelDescriptor * hostOutputChannels=0x016a27e8, unsigned long
>> framesToProcess=128) Line 1060 + 0x33 bytes C
>> MyApp.exe!PaUtil_EndBufferProcessing(PaUtilBufferProcessor *
>> bp=0x016ad5a0, int * streamCallbackResult=0x0712fda4) Line 1582 + 0x1b
>> bytes C
>> MyApp.exe!Pa_TimeSlice(PaWinDsStream * stream=0x016ad550) Line 2106
>> + 0x10 bytes C
>> MyApp.exe!Pa_TimerCallback(unsigned int uID=16, unsigned int uMsg=0,
>> unsigned long dwUser=23778640, unsigned long dw1=0, unsigned long dw2=0)
>> Line 2209 + 0x9 bytes C
>>
>>
>> Any idea why this happens?
>> I was checking the functions in the stack and I saw that sound_port.c's
>> play_cb has the following comment:
>> /* We're risking accessing the port without holding any mutex.
>> * It's possible that port is disconnected then destroyed while
>> * we're trying to access it.
>> * But in the name of performance, we'll try this approach until
>> * someone complains when it crashes.
>> */
>> I don't know if this is related to the problem I am having
>>
>>
> You need to be careful with the sequence to destroy the media port while
> it's connected to the sound device. There are plenty of samples (playfile,
> playsine, recfile, resampleplay, etc.) on how to do it.
>
> Cheers
> Benny
>
>
> The problem is that I'm using a conference bridge, so those examples
> aren't of much help in this case :S
>
> When the call state moves to PJSIP_INV_STATE_DISCONNECTED, I am using the
> following code:
>
> if (my_media_conference_slot>0) {
> pjmedia_conf_disconnect_port(my_conference_bridge,
> my_media_conference_slot, 0);
> pjmedia_conf_disconnect_port(my_conference_bridge, 0,
> my_media_conference_slot);
> pjmedia_conf_remove_port(my_conference_bridge,
> my_media_conference_slot);
> }
>
> if (my_snd_player != NULL) {
> pjmedia_snd_port_disconnect(my_snd_player);
> pj_thread_sleep(100);
> pjmedia_snd_port_destroy(my_snd_player);
> }
>
> (NOTE: I don't know exactly why pjmedia_conf_disconnect_port is being
> called twice with those parameters, I've inherited that code)
> Is this the correct way to close sound ports?
>
>
> BTW, in the logs I find a lot of "Underflow" messages; is it expectable /
> desirable?
> example:
> 11:03:14.711 strm058E7994 Jitter buffer empty (prefetch=28)
> 11:03:14.742 Master/sound Underflow, buf_cnt=252, will generate 1 frame
> 11:03:14.808 Master/sound Underflow, buf_cnt=252, will generate 1 frame
> 11:03:14.841 Master/sound Underflow, buf_cnt=252, will generate 1 frame
> 11:03:14.896 Master/sound Underflow, buf_cnt=252, will generate 1 frame
> 11:03:14.933 Master/sound Underflow, buf_cnt=252, will generate 1 frame
> 11:03:14.978 aec058CB7D8 AEC info: queue is full, frame discarded
> [count=6, seq=352]
> 11:03:15.021 aec058CB7D8 AEC reset, delay=173, prefetch=2
> 11:03:15.065 Master/sound Underflow, buf_cnt=252, will generate 1 frame
> 11:03:15.117 strm058E7994 Jitter buffer empty (prefetch=28)
> 11:03:15.175 Master/sound Underflow, buf_cnt=252, will generate 1 frame
> 11:03:15.214 Master/sound Underflow, buf_cnt=252, will generate 1 frame
> 11:03:15.242 Master/sound Underflow, buf_cnt=252, will generate 1 frame
> 11:03:15.314 Master/sound Underflow, buf_cnt=252, will generate 1 frame
> 11:03:15.364 Master/sound Underflow, buf_cnt=252, will generate 1 frame
> 11:03:15.398 aec058CB7D8 AEC info: queue is full, frame discarded
> [count=6, seq=358]
> 11:03:15.453 aec058CB7D8 AEC reset, delay=179, prefetch=2
> 11:03:15.490 aec058CB7D8 AEC Info: prefetching (first seq=358)
> 11:03:15.574 aec0592EAE8 AEC Info: prefetching (first seq=198)
> 11:03:15.626 strm058E7994 Jitter buffer empty (prefetch=28)
> 11:03:15.670 Master/sound Underflow, buf_cnt=252, will generate 1 frame
> 11:03:15.700 strm058E7994 Jitter buffer empty (prefetch=28)
> 11:03:15.723 aec0592EAE8 AEC info: queue is full, frame discarded
> [count=6, seq=205]
> 11:03:15.748 aec0592EAE8 AEC reset, delay=110, prefetch=2
> 11:03:15.786 Master/sound Underflow, buf_cnt=252, will generate 1 frame
> 11:03:15.848 Master/sound Underflow, buf_cnt=252, will generate 1 frame
>
>
> Cheers
> Pedro Gon?alves
>
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20080710/f27b2394/attachment.html
