[Linphone-developers] Thread safety problem with Speex process and preprocess routines

[Steve Strobel]

Test setup:  Blackfin DSP (BF537) running uClinux and Linphone 
3.0.0.  I suspect that this problem would occur on any type of processor.

I think I have stumbled upon a problem where the thread that calls 
the Speex encoder can be crashed by another thread changing the codec 
settings.  Changing the codec settings causes the Speex preprocess 
routine enc_preprocess() to be called.  When the timing falls just 
right such that the speex_encode_int() is in the middle of encoding 
Speex frames, it can cause crashes deep inside the Speex encoder.

I am looking for advice for how to resolve this problem.  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.  In this case, I think the mutex would 
hold off execution of the preprocess function until the process 
function was done and it was safe to apply the codec changes.  I 
suppose there would need to be a mutex for each RTP session.  I am 
not sure what the best way to implement this would be (I haven't used 
mutexes in Linux before).  Would a spinlock be better?  Could one of 
them be added to an existing data structure that is already specific 
to each RTP session?

An option for solving this problem at the application level would be 
to disconnect the ticker, wait until all encoding was done (no good 
way to determine that), apply the changes, and reconnect the 
ticker.  That seems really ugly and would cause gaps in the audio streams.

Another possibility is that I am doing something when changing codecs 
that doesn't need to be done.  I have a big routine that watches a 
file written by another application for configuration changes and 
applies them.  I could provide source if needed.

FWIW:  I have a test configuration that crashes consistently on 
startup with this problem.  It is encoding 500mS of Speex in each 
packet, which takes long enough that the codec change received soon 
after startup hits it every time.  I can change the timing and hide 
the problem, but I think the same thing could happen any time the 
codec is changed while it is running, so I would rather fix it at the root.

Thanks for any suggestions,
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