linphone-developers
[Top][All Lists]
Advanced

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

Re: [Linphone-developers] Thread safety problem with Speex process and p


From: Simon Morlat
Subject: Re: [Linphone-developers] Thread safety problem with Speex process and preprocess routines
Date: Fri, 15 Apr 2011 11:57:10 +0200

Hi, 

The codec replacement function you are talking there is invoked from the
Ticker thread when the received RTP payload type doesn't match the
currently in place decoder.
I suppose you have modified it to do the same with the encoder, but
unfortunately this cannot work.
My suggestion is to really ms_ticker_detach() the graph, perform the
change and then ms_ticker_attach() again.
THis is safe. This can lead to a small interruption in the audio stream
however.


Simon


Le jeudi 14 avril 2011 à 15:56 -0600, Steve Strobel a écrit :
> At 10:12 AM 4/14/2011, you wrote:
> >At 04:14 PM 4/13/2011, Steve wrote:
> >>[snip] The most straightforward and robust solution seems to me to make the 
> >>preprocess and process routines (and probably the postprocess too) all 
> >>acquire the same mutex.  [snip]  Could one of them be added to an existing 
> >>data structure that is already specific to each RTP session?
> >
> >I should have used grep before posting the above;  I didn't realize that 
> >mediastreamer was already using mutexes in so many places.  I guess my task 
> >now is to find which (probably existing) mutex is intended to protect 
> >whichever data is causing my problem and make sure that it is locked during 
> >the critical section.  Any hints where to start looking?
> 
> I have narrowed it down some more.  The problem occurs when audio is being 
> Speex encoded in the ticker's thread while the thread that started the ticker 
> does the following to change the codec settings (generally in response to 
> some user input):
> 
>   MSFilter *encoder=ms_filter_create_encoder( codec_setup.codec_name );
>   if ( encoder != NULL )
>   {
>     [snip] set some other encoder options here
> 
>     // unlink the old encoder and link in the new one
>     ms_filter_unlink(stream->soundread, 0, stream->encoder, 0);
>     ms_filter_unlink(stream->encoder,0,stream->rtpsend,0);
>     ms_filter_postprocess(stream->encoder);
>     ms_filter_destroy(stream->encoder);
>     stream->encoder=encoder;
>     ms_filter_link(stream->soundread,0,stream->encoder,0);
>     ms_filter_link(stream->encoder,0,stream->rtpsend,0);
>     rtp_session_set_send_payload_type(stream->session,
>       get_payload_type_from_codec_name(codec_setup.codec_name));
>     ms_filter_preprocess(stream->encoder,stream->ticker);
>   }
> 
> If I comment the call to rtp_session_set_send_payload_type() it quits 
> crashing, at least with this test configuration.  Is changing the payload 
> type while it is encoding in another thread a valid thing to do?  
> 
> Steve
> 
> 
> 
> ---
> Steve Strobel
> Link Communications, Inc.
> 1035 Cerise Rd
> Billings, MT 59101-7378
> (406) 245-5002 ext 102
> (406) 245-4889 (fax)
> WWW: http://www.link-comm.com
> MailTo:address@hidden
> 
> 
> _______________________________________________
> Linphone-developers mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/linphone-developers





reply via email to

[Prev in Thread] Current Thread [Next in Thread]