Re: OpenSLES Deadlock?

[Glenn Kasten]

The "was locked by" message appears in system/media/.../src/locks.c (ICS and earlier) or frameworks/wilhelm/src/locks.c (Jellybean).  

It often, but not always, means you're destroying an audio player object that is still in use.

Re:  "not verified on ICS" it will be interesting to see if you see the same problems on ICS and Jellybean. That will help show whether this is an app bug or a platform bug that has since been fixed. However I'm not aware of any recent bug fixes in this area.

You didn't mention if you're using a multiprocessor or uniprocessor device. Which device(s) do you see the problem on? are there any devices where you don't see the problem? There are certain race conditions that are more likely to appear on multiprocessors, such as bugs related to cache coherency (lack of mutexes or memory barriers etc.)

Double-check use of mutexes, especially in callback handlers, and review the destroy sequence.

I know it's a lot to ask, but it you can try testing on your platform debug... this will allow you to add more debugging logs.

Can you post excerpts of relevant code here? For example, the callback handler(s) and destroy sequence are most important.  Object creation and parameter settings such as SetVolume etc. are unlikely to be the source of problem but it wouldn't hurt if you want to post that code also.

On Thursday, July 19, 2012 12:51:00 AM UTC-7, step_jac wrote:

Hello fellow NDK devs,

We are developing a game using NativeActivity, OpenGLES2 and OpenSLES. We are experiencing an occasional lockup on HoneyComb (not verified on ICS) but are unable to determine the source due to the debugger not displaying a full stack when interrupting the app.

A message prior to the lock seems to indicate this is an OpenSL issue.
"W/libOpenSLES(26155): system/media/wilhelm/src/android/AudioPlayer_to_android.cpp:1087: object 0xe5dfb0 was locked by 0x1a2508 at system/media/wilhelm/src/itf/IPlay.c:38"
however, none of the AudioPlayer_to_android.cpp sources we've found online contain this particular message.

In terms of Audio system infrastructure, we are using a custom implementation of XACT which we initially ported from DirectSound to openAL and now to OpenSLES. We are solely using the android buffer queue and PCM data either from raw source or CPU decoded OGG. All OpenSL operations happen on the Native Application thread except for buffer enqueuing for streaming audio. The application itself uses the NativeActivity and Android NDK provided glue (building against android9). We have since moved buffer enqueueing back to the native activity thread but the problem persists.

Anyone else dealt or resolved this? Any insight would be much appreciated.

Best regards,

Stephane

[Ian Ni-Lewis]

Thanks Stephane!

I did see the XACTEngineLock call protecting the queue, but it wasn't clear to me whether you were protecting all of the member variables--still isn't, actually, because I don't see a lock in the code snippet you sent.

One of the things that bit the original XACT team (of which I was temporarily a member--I was loaned from the Xbox team to implement XMA streaming in the XACT engine and tool) was the different behavior of integer writes on multiprocessor PowerPC compared to Intel. PowerPC and ARM have a relaxed memory model compared to Intel, so operations that appear atomic on Intel have unexpected side effects on the other processors. It's made me extra paranoid about shared class members. If your SetEvent() implementation has the same semantics as the Windows call (i.e. it acts as a write fence) *and* the function is effectively serialized by Event set/waits, then you're probably fine.

Anyway, sounds like the issue isn't in your code... but you might want to take one more pass over it just to be sure the threading is safe. As I'm sure you know, race conditions are often tricky and hard to repro. 

Meanwhile, based on the bug you referred, perhaps we need to do the same thing for libwilhelm. :-)

Thanks!

Ian

On Mon, Jul 30, 2012 at 10:51 PM, step_jac <stephan...@gmail.com> wrote:

Hi Glenn, Ian,

I believe I have resolved the issue at hand. It seems in some game sequences could result in Play-Stop-Play to be called relatively fast on a single audio player. This was the case when preparing and scheduling tracks for multi dialog cut-scenes. But in some cases, this would cause a stall. Seems similar to http://code.google.com/p/android/issues/detail?id=3197 though this particular case was more sporadic and difficult to isolate.

Thank you both for your insight and help.

Kind regards,

Stephane Jacoby

On Monday, 30 July 2012 11:16:49 UTC-7, step_jac wrote:

Hi Glenn,

We finally got a debug build of HC 3.2 up and running. Unfortunately, it did not yield more information on the issue.

Thanks for your response.
Best,

Stephane

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.

To view this discussion on the web visit https://groups.google.com/d/msg/android-ndk/-/Y3dp4AW7MJsJ.

To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

--
Ian Ni-Lewis

Developer Advocate
Android Developer Relations

[Glenn Kasten]

I'm returning late to this thread after an absence, glad to hear that progress has been made.

I did want to mention one more thing though about locks and the native-audio example code in the NDK ...

I originally wrote and tested that example code for Gingerbread release (2.3) where the lead device was a uniprocessor Nexus S.

In the next release Honeycomb (3.0), the lead device was an SMP Motorola Xoom.

As has previously been discussed on android-ndk, SMP on ARM has a memory coherency model

which differs from some other popular architectures, with the result that proper use of memory barriers on SMP ARM is more critical.

One easy way to get the barriers is to use pthread mutexes, which include them built-in in the right places

(there are other ways to insert the barriers, but that's a more advanced topic beyond the scope of this reply).

Be cautious with the example code as it has not yet been gone through with a fine-tooth comb

and updated for SMP memory coherency.  Use it as a rough guide for APIs, but please pay attention

to the memory barriers in your own code.  I do hope to update the example eventually for SMP,

but just haven't gotten to it yet.

To unsubscribe from this group, send email to android-ndk+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

[Ian Ni-Lewis]

Glenn is absolutely right, and properly mutex-protected code will not suffer from memory model weirdness.

The issues I'm talking about are with code that shares certain types of values (in particular values that are 32 bits or less and properly aligned) without protection, or with only atomics for synchronization. This is usually referred to as "lock free" code, and whether or not it is done intentionally, it is far more likely to work on a single processor system or an Intel processor than it is on an SMP ARM. 

Ian

To view this discussion on the web visit https://groups.google.com/d/msg/android-ndk/-/Rr5FZ1Za58wJ.

To post to this group, send email to andro...@googlegroups.com.

To unsubscribe from this group, send email to android-ndk...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.