[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: Steve Strobel
Subject: Re: [Linphone-developers] Thread safety problem with Speex process and preprocess routines
Date: 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 
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);

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 Strobel
Link Communications, Inc.
1035 Cerise Rd
Billings, MT 59101-7378
(406) 245-5002 ext 102
(406) 245-4889 (fax)

reply via email to

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