[Top][All Lists]
[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