[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Linphone-developers] Thread safety problem with Speex process and prepr
[Linphone-developers] Thread safety problem with Speex process and preprocess routines
Wed, 13 Apr 2011 16:14:10 -0600
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,
Link Communications, Inc.
1035 Cerise Rd
Billings, MT 59101-7378
(406) 245-5002 ext 102
(406) 245-4889 (fax)
- [Linphone-developers] Thread safety problem with Speex process and preprocess routines,
Steve Strobel <=