[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

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]