[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Linphone-developers] Thread safety problem with Speex process and p
Re: [Linphone-developers] Thread safety problem with Speex process and preprocess routines
Thu, 14 Apr 2011 15:56:22 -0600
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
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);
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?
Link Communications, Inc.
1035 Cerise Rd
Billings, MT 59101-7378
(406) 245-5002 ext 102
(406) 245-4889 (fax)