RTP problems with ICE

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Nanang Izzuddin wrote:
> 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.
Sorry, I didn't understand this 100%: are you saying that the pool used
in *pjmedia_conf_add_port* can't be the same for allocating
conf_port->mix_buf?
I don't know where conf_port->mix_buf is allocated, but I am using
pjsip_inv_session's pool in *pjmedia_conf_add_port*.
Where can I see which pool is being used to allocate conf_port->mix_buf?
Which pool should I use?

> - there is buffer overrun somewhere in your app.
I am new no C/C++, and so I'm no expert in buffer overruns... Do you
have any suggestion on how to detect a buffer overrun and how to prevent it?
Is this somehow related to the "Master/sound Underflow, buf_cnt=252,
will generate 1 frame" lines that appear in the log?

Many thanks
Pedro Gon?alves

>
> Regards,
> nanang
>
>
> 2008/7/9 Pedro Gon?alves <pedro.pandre at gmail.com 
> <mailto: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 <mailto: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 <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
>   





[Index of Archives]     [Asterisk Users]     [Asterisk App Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [Linux API]
  Powered by Linux