Why does openSL destroy function block forever on some devices?

[Jake]

When I try to destroy an openSL recorder object as part of a tear down where I'm shutting down the mic the destroy function blocks forever.

This happens on Nexus 7 (KitKat) and some other KitKat devices (kernel 3.4.0)

When I run the same exact code on my SGH-i897 KitKat which has a different kernel version (3.0.101) the destroy function never blocks.

Is this a known issue?

      SLuint32 state = SL_RECORDSTATE_RECORDING;
   
      (*thisChannel->recorderRecord)->SetRecordState(thisChannel->recorderRecord, SL_RECORDSTATE_STOPPED);
   
      while (state != SL_RECORDSTATE_STOPPED)
      {
         (*thisChannel->recorderRecord)->GetRecordState(thisChannel->recorderRecord, &state);
         retries++;
         if (retries > 20)
         {
            bSuccess = 0;
            break;
         }
      }
    
      if (bSuccess == 0)
      {
         return -1;
      }


      /* Clear buffer queue */
      (*thisChannel->recorderBufferQueue)->Clear(thisChannel->recorderBufferQueue);
      /* THIS DESTROY FUNCTION BLOCKS FOREVER */
      (*thisChannel->recorderObject)->Destroy(thisChannel->recorderObject);
      thisChannel->recorderObject        = NULL;


NOTE: recorderObject is of type SLObjectItf

[Brendon Costa]

On 22 April 2014 08:53, Jake <mjame...@gmail.com> wrote:

I run the same exact code on my SGH-i897 KitKat which has a different

From what I recall in my own development using OpenSL on android this is a bug related to opening the input (recorder) multiple times (which was just brought up on this list recently).

I don't know if it is tracked, but if two apps open the input stream at the same time only one is successful. The failure case behavior varies between devices.

On some devices the open returns an error on failure (In this case calling destroy crashes), and on other devices it returns as a success but fails to actually produce any audio. When the audio thread is not running (because the open failed but didn't return an error), on some devices it turns out the destroy call will block until the audio thread runs once (which is never going to happen).

[Brendon Costa]

I forgot to mention what I have done to work around the issue as best I could.

Basically I have found that most apps use the audio focus to manage output and input audio together. In most scenarios I have found using audio focus to manage if you are "permitted" to open the input is sufficient. It still fails occasionally and I don't believe there is anything we can do about it until these bugs are resolved in android.

There are some apps that still don't work correctly. For example Skype, will request audio focus and ignore if it looses it so Skype will keep the input audio open even after you take audio focus. But most apps actually obey the audio focus. 

[Jake]

Hi Brendon

Thank you for your reply.

In this case there are no other applications requesting the microphone.

This is a case where I start my application, open up the microphone and close it after a little while.

The close fails as the destroy API function hangs forever.

I don't have any problems with getting audio. That's not the problem. The problem in my case is that the destroy hangs.

Keep in mind I'm doing all this at the native level through openSL.

However, there are also things going on (out-of-sync) at the Java level (AudioManager.SetMode and Audio Focus stuff).

Is it possible that my Java code which (also) interfaces with the audio subsystem is causing problems for my native code ?

[Brendon Costa]

On 22 April 2014 10:27, Jake <mjame...@gmail.com> wrote:

ith the a

Try rebooting your phone. I recall a few times I managed to get my phone into a bad state where it would fail continually until it was rebooted (does not happen any more).

Its now been a while since I looked at this. But I do recall seeing similar bugs with Destroy() blocking forever. What I mentioned was one of the causes I can remember, but it is possible there were others I cant remember specifically now. 

I am also using setMode() and audio focus from Java for a VoIP use case. However I had need of stereo rendering of the VoIP with user selection of where the audio is sent to in app and that caused me great headaches which may not affect your use case (I had to vary mode, route, recording preset, and stream type with different values per device to achieve everything I needed, it is a nightmare)

In case it does make a difference my current order of operations that has been working for a few months now and tested on a number of devices ranges is (excluding what I did for bluetooth support):

* Obtain audio focus (Java)

* Set mode (java)

* Create/realize input (setting recording preset)

* Create/realize output (setting stream type)

* Set route (java)

* Start input

* Start output

* Reset mode 

* Stop input

* Stop output

* Destroy input

* Destroy output

[Eric Wing]

On 4/21/14, Brendon Costa <brendon...@gmail.com> wrote:
> On 22 April 2014 08:53, Jake <mjame...@gmail.com> wrote:
>
>> I run the same exact code on my SGH-i897 KitKat which has a different
>

I think I've encountered this same bug. I think it is a general
destroy problem and I've seen it on multiple versions of Android on
multiple devices, and it's a general SL engine problem, not just
limited to the microphone.

The bug seems to happen sometimes, but not always. But I did manage to
find a way to trigger it pretty often. In my sound engine, I am using
OpenSL ES to decode audio formats. I have a separate engine for
decoding and playback (because I go through OpenAL Soft for playback
and it has its own private OpenSL engine instance). When I open and
close a file very frequently (which means an engine gets created and
destroyed), I can usually trigger this bug after about 10 attempts.

I probably should have filed a formal bug, but I never got around to
it. (And nobody ever upgrades the OS on Android so I figure I'm stuck
with this bug forever regardless.)

I have a really evil hack right now that basically does all this on a
background thread and I kill the thread if I detect it is taking too
long. There is a resource leak if this happens, so there is a finite
limit of how many times I can do this in a run of an app (I think it
is ballpark 50). But it is better than the deadlock.

You can see my code. It is in ALmixer, found in this branch.
https://bitbucket.org/ewing/almixer_androidopensles

In Isolated/OpenSLES_Android.c, there is a #define named:
SOUNDDECODER_OPENSLES_ANDROID_USE_DESTROY_DEADLOCK_WORKAROUND

You'll find the related stuff there.

Thanks,
Eric
--
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/

[Jake]

I debugged the issue some more and here is the problem:

The microphone callback might not have returned when the destroy is initiated.

Using mutexes to circumvent that problem doesn't seem to help..

Any suggestions ???




I/MYAPP( 4364): [OpenSLChannelCallbackMic] Processing Exit
I/MYAPP( 4364): [OpenSLChannelCallbackMic] Processing Entry
I/MYAPP( 4364): [OpenSLChannelCallbackMic] Processing Exit
I/MYAPP( 4364): [OpenSLChannelCallbackSpk] Processing Entry
I/MYAPP( 4364): [OpenSLChannelCallbackSpk] Processing EXIT
I/MYAPP( 4364): [OpenSLChannelCallbackSpk] Processing Entry
I/MYAPP( 4364): [OpenSLChannelCallbackSpk] Processing EXIT
I/MYAPP( 4364): [OpenSLChannelCallbackMic] Processing Entry
I/MYAPP( 4364): [OpenSLChannelCallbackMic] Processing Exit
I/MYAPP( 4364): [OpenSLChannelCallbackMic] Processing Entry
I/MYAPP( 4364): [OpenSLChannelCallbackMic] Processing Exit
I/MYAPP( 4364): [OpenSLChannelCallbackSpk] Processing Entry
I/MYAPP( 4364): [OpenSLChannelCallbackSpk] Processing EXIT
I/MYAPP( 4364): [OpenSLChannelCallbackSpk] Processing Entry
I/MYAPP( 4364): [OpenSLChannelCallbackSpk] Processing EXIT
I/MYAPP( 4364): [OpenSLChannelCallbackMic] Processing Entry
I/MYAPP( 4364): [OpenSLChannelCallbackMic] Processing Exit
I/MYAPP( 4364): [OpenSLChannelCallbackMic] Processing Entry           <----------------- Microphone callback entry
I/MYAPP( 4364): [OpenSLChannelCallbackMic] Processing Exit            <----------------- Microphone callback exit
I/MYAPP( 4364): [OpenSLChannelCallbackSpk] Processing Entry
I/MYAPP( 4364): [OpenSLChannelCallbackSpk] Processing EXIT
I/MYAPP( 4364): [OpenSLChannelSpeakerStop] Called
I/MYAPP( 4364): [OpenSLChannelCloseSpkPath] Called
I/MYAPP( 4364): [OpenSLChannelCloseSpkPath] Waiting for speaker to stop...
I/MYAPP( 4364): [OpenSLChannelCloseSpkPath] Speaker stopped!
I/MYAPP( 4364): [OpenSLChannelCloseSpkPath] Result: OK
I/MYAPP( 4364): [OpenSLChannelSpeakerStop] Result: OK
I/MYAPP( 4364): [OpenSLChannelMicrophoneStop] Called               <------------ Here the mic shutdown is initiated
I/MYAPP( 4364): [OpenSLChannelCloseMicPath] Called
I/MYAPP( 4364): [OpenSLChannelCallbackMic] Processing Entry        <----------------- Microphone callback entry

The mic callback was called and it now has a very short amount of time to finish before 'destroy' is called.

D/AudioStreamInALSA(  168): standby
D/AudioStreamInALSA(  168): standby
D/ALSADevice(  168): standby: handle 0xb74932b0 h 0x0
V/ALSADevice(  168): standby handle h 0xb748c930
D/alsa_ucm(  168): snd_use_case_set(): uc_mgr 0xb73e3d58 identifier _dismod value Capture Music
D/alsa_ucm(  168): Set mixer controls for Capture Music enable 0
D/alsa_ucm(  168): Setting mixer control: MultiMedia1 Mixer SLIM_0_TX, value: 0
V/ALSADevice(  168): use case is HiFi Lowlatency
V/ALSADevice(  168): Number of modifiers 0
V/ALSADevice(  168): usecase_type is 1
D/alsa_ucm(  168): snd_use_case_set(): uc_mgr 0xb73e3d58 identifier _disdev value Line3
D/alsa_ucm(  168): Set mixer controls for Line3 enable 0
D/alsa_ucm(  168): Setting mixer control: SLIM TX7 MUX, value: ZERO
D/alsa_ucm(  168): Setting mixer control: DEC6 MUX, value: ZERO
D/alsa_ucm(  168): Setting mixer control: DEC6 Volume, value: 0
D/alsa_ucm(  168): Setting mixer control: MICBIAS4 CAPLESS Switch, value: 0
D/AudioStreamInALSA(  168): Checking for musbRecordingState 0
V/AudioHardwareALSA(  168): closeUsbRecordingIfNothingActive, musbRecordingState: 0
D/AudioHardwareALSA(  168): Closing USB Recording Session as no stream is active
D/AudioUsbALSA(  168): exitRecordingThread
D/AudioUsbALSA(  168): write to fd
D/AudioUsbALSA(  168): closeDevice handle 0x0
D/AudioUsbALSA(  168): closeDevice handle 0x0

No indication above that the microphone callback has returned!!!! So we'll hang on the following mic destroy!

I/MYAPP( 4364): Changing state of mic to paused...
I/MYAPP( 4364): Changing state of mic to stopped...
I/MYAPP( 4364): [OpenSLChannelCloseMicPath] Clear mic recorder buffer queue
I/MYAPP( 4364): [OpenSLChannelCloseMicPath] Destroying mic recorder object        <-------- HANGS
D/ALSADevice(  168): standby: handle 0xb7477ae0 h 0x0
V/ALSADevice(  168): standby handle h 0xb7493170
D/alsa_ucm(  168): snd_use_case_set(): uc_mgr 0xb73e3d58 identifier _verb value Inactive
D/alsa_ucm(  168): Set mixer controls for HiFi Lowlatency enable 0
D/alsa_ucm(  168): Setting mixer control: SLIMBUS_0_RX Audio Mixer MultiMedia5, value: 0
V/ALSADevice(  168): Number of modifiers 0
V/ALSADevice(  168): usecase_type is 0
D/alsa_ucm(  168): snd_use_case_set(): uc_mgr 0xb73e3d58 identifier _disdev value Line3
D/alsa_ucm(  168): disdev: device Line3 not enabled, no need to disable
D/alsa_ucm(  168): snd_use_case_set(): uc_mgr 0xb73e3d58 identifier _disdev value Speaker
D/alsa_ucm(  168): Set mixer controls for Speaker enable 0
D/alsa_ucm(  168): Setting mixer control: RX3 MIX1 INP1, value: ZERO
D/alsa_ucm(  168): Setting mixer control: RX5 MIX1 INP1, value: ZERO
D/alsa_ucm(  168): Setting mixer control: RX4 DSM MUX, value: CIC_OUT
D/alsa_ucm(  168): Setting mixer control: RX6 DSM MUX, value: CIC_OUT
D/alsa_ucm(  168): Setting mixer control: LINEOUT1 Volume, value: 0
D/alsa_ucm(  168): Setting mixer control: LINEOUT2 Volume, value: 0
D/alsa_ucm(  168): Setting mixer control: LINEOUT3 Volume, value: 0
D/alsa_ucm(  168): Setting mixer control: LINEOUT4 Volume, value: 0
V/AudioHardwareALSA(  168): closeUsbPlaybackIfNothingActive, musbPlaybackState: 0
D/AudioUsbALSA(  168): exitPlaybackThread, mproxypfdPlayback: -1
D/AudioUsbALSA(  168): closeDevice handle 0x0
D/AudioUsbALSA(  168): closeDevice handle 0x0

[Glenn Kasten]

Sorry I'm coming to this thread late.

Jake, I think you may have hit on the issue, it sounds like a race condition in the platform implementation.

Have you or anyone else filed a bug on this yet at https://code.google.com/p/android/issues/ ?

If you have, please add a bug ID number here.

Otherwise let me know and I'll log a new bug.

I think I know of a possible way to fix this in the platform implementation, 

but I would first need a test case showing the bug so I can verify a fail -> pass transition.

Does anyone on the thread have a short non-confidential snippet of code that reliably fails, that you could share?

(I have personally never seen this failure that I recall)

Of course even if we do find a platform fix, a workaround will be helpful for apps running on earlier releases without the fix.

Does adding an explicit stop, followed by sleep, followed by destroy help?

[EE_George]

Dear all,

I have encountered the problem exactly as Eric described. For most of the time, the bug occurs when open and close file frequently. My observation is the same as Eric, it is likely to fail around 10 attempts but varies from devices. There is a chance for the bug to occur when closing audio file normally without opening it frequently. 

Another thing I wish to mention is that I was trying to solve this problem by creating another thread to do the destroy job and the main thread waits for that thread for 2 seconds. If the destroy-object thread fail to finish its job, main thread just continue to do its work. I was using boost:conditional variable timed-wait method to implement it. However, if the destroy thread hangs, the main thread will hang as well.

Currently, I believe creating a daemon thread is the only way to solve the problem. However, this will consume more battery and cause memory leak. 

I know the bug looks like race condition but I tend to believe it is an android bug since I have been looking into this bug for around one week and tried my best to avoid race condition.

I am sorry that my code is confidential.

Regards,

George. 

[Glenn Kasten]

See also https://groups.google.com/forum/#!topic/android-porting/AfyY8tf-ofw

I think I might have a platform fix, but I need a test case to confirm.

Does anyone have a simple test sequence that demonstrates the bug, that you could share here please?

Thanks

[Eric Wing]

On 5/15/14, Glenn Kasten <gka...@android.com> wrote:
> See also
> https://groups.google.com/forum/#!topic/android-porting/AfyY8tf-ofw
> I think I might have a platform fix, but I need a test case to confirm.
> Does anyone have a simple test sequence that demonstrates the bug, that you
>
> could share here please?
> Thanks

Hi Glenn,
As I mentioned earlier, the quick playing/stopping/unloading/loading
process made it really easy for me to reproduce.

This Titanium/Platino based program is what I used to originally
diagnose/reproduce the program:
https://github.com/Lanica/Platform-platino/blob/master/platino/Audio/Jukebox/Resources/ui/handheld/ApplicationWindow.js

The ALmixer work around is compiled into the library. I think it
prints a warning to the log
when I detect the hang and kill the thread.


If don't want to go through the Titanium/JavaScript layer, you could
re-create this program directly in C with ALmixer. This ALmixer
Android hello world program has most of the boiler plate you need (it
already wired up a native button with JNI).
https://bitbucket.org/ewing/hello-android-almixer

I did everything possible to make getting started with those programs
as easy as possible on Android, but it still makes me cringe. This is
probably as painless as its going to get. If you actually building
these, you might start seeing first hand the pain 3rd party library
developers have been complaining about with Android and the NDK for
years.

[Jake]

>> Glenn:

>I think I might have a platform fix, but I need a test case to confirm.

>Does anyone have a simple test sequence that demonstrates the bug, that you could share here please?

>Thanks

I might be able to post a snippet which reproduces the issue consistently.

Give me some time and I'll post it.

Btw: Is there a planned update of the NDK in the pipeline?

[Glenn Kasten]

See https://groups.google.com/forum/#!topic/android-ndk/G7dLKAGGL28

Sorry I can't comment on schedules

[Glenn Kasten]

Oops I meant to see https://android-review.googlesource.com/#/c/105606/

[Jake]

> See https://groups.google.com/forum/#!topic/android-ndk/G7dLKAGGL28

According to the ticket it looks like a fix has been reviewed and checked in??

Is the fix available? And if so, is it part of the latest NDK release?

[Glenn Kasten]

A source change that should fix this problem is available in AOSP at https://android-review.googlesource.com/#/c/105606/

The change was not in NDK per se, but rather in a platform library.

I am unable to say when there will be an updated platform binary release that contains this change.

[Jake]

>A source change that should fix this problem is available in AOSP at https://android-review.googlesource.com/#/c/105606/

>The change was not in NDK per se, but rather in a platform library.

>I am unable to say when there will be an updated platform binary release that contains this change.

So the source change affects a platform library? Which library exactly?

And who builds and releases this library?

What is the platform library part of? The OS? SDK? NDK? Kernel?

[mic _]

>Which library exactly?

Looks like libwilhelm.

>And who builds and releases this library?

I don't know how Android updates work nowadays, but back when I worked on Android for an OEM it would've been the OEM that prepared an update for interested operators, which the operator in turn could provide to its customers.

/Michael

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-ndk...@googlegroups.com.
To post to this group, send email to andro...@googlegroups.com.
Visit this group at http://groups.google.com/group/android-ndk.
For more options, visit https://groups.google.com/d/optout.

[Jake]

> A source change that should fix this problem is available in AOSP at https://android-review.googlesource.com/#/c/105606/

>The change was not in NDK per se, but rather in a platform library.

>I am unable to say when there will be an updated platform binary release that contains this change.

I can confirm that the source change fixes the issue. The source change affects the following libraries:

libOpenMAXAL
libOpenSLES
libwilhelm

I verified the fix by having my Android phone's system/lib folder patched (3 above libraries were written to
the system/lib folder on my phone) and then building a new apk
where the updated libOpenSLES library is linked in (replaced the ARM openSL and openMaxAL libraries in Android-19 with
the updated libraries).

[alex zheng]

Hi, I meet  a similar problem when I destroy an AuidoPlayer(URI player) sometimes.

the logcat show as follow:

  W/libOpenSLES( 8593): frameworks/wilhelm/src/android/AudioPlayer_to_android.cpp:410: pthread 0x7775c738 (tid 27014) sees object 0x77905710 was locked by pthread 0x6a54a608 (tid       8737) at frameworks/wilhelm/src/itf/IObject.c:411

Is it a known issue  too?

在 2014年9月18日星期四 UTC+8上午8:21:17，Jake写道：

[Glenn Kasten]

Which Android device and platform version are you using?

(please include full text at bottom of your Settings / About device)

Also, what format of data are you playing ... for example is it WAV, MP3, AAC, etc?

Are you using any unusual options?

[alex zheng]

I create the URI player use the config as follows. My APP frequently "create -> play -> destroy" the URI player with WAV files, then sometimes it occurs a dead lock when destroy the player.

are there any notice I should pay attention to when I destory the player? or are there something wrong in the config as follows?

// configure audio source

// (requires the INTERNET permission depending on the uri parameter)

SLDataLocator_URI loc_uri = {SL_DATALOCATOR_URI, (SLchar *)uri};

SLDataFormat_MIME format_mime = {SL_DATAFORMAT_MIME, NULL, SL_CONTAINERTYPE_UNSPECIFIED};

SLDataSource audioSrc = {&loc_uri, &format_mime};

// configure audio sink

SLDataLocator_OutputMix loc_outmix = {SL_DATALOCATOR_OUTPUTMIX, outputMixObject};

SLDataSink audioSnk = {&loc_outmix, NULL};

// create audio player

const SLInterfaceID ids[4] = {SL_IID_ANDROIDCONFIGURATION, SL_IID_SEEK, SL_IID_MUTESOLO, SL_IID_VOLUME};

const SLboolean req[4] = {SL_BOOLEAN_TRUE, SL_BOOLEAN_TRUE, SL_BOOLEAN_TRUE, SL_BOOLEAN_TRUE};

result = (*engineEngine)->CreateAudioPlayer(engineEngine, uriPlayerObjectP, &audioSrc,

&audioSnk, 4, ids, req);

// note that an invalid URI is not detected here, but during prepare/prefetch on Android,

// or possibly during Realize on other platforms

assert(SL_RESULT_SUCCESS == result);

(void)result;

// CreateAudioPlayer and specify SL_IID_ANDROIDCONFIGURATION

// in the required interface ID array. Do not realize player yet.

SLAndroidConfigurationItf uriPlayerConfig;

result = (**uriPlayerObjectP)->GetInterface(*uriPlayerObjectP, SL_IID_ANDROIDCONFIGURATION, &uriPlayerConfig);

assert(SL_RESULT_SUCCESS == result);

result = (*uriPlayerConfig)->SetConfiguration(uriPlayerConfig, SL_ANDROID_KEY_STREAM_TYPE, &streamType, sizeof(SLint32));

assert(SL_RESULT_SUCCESS == result);

// realize the player

result = (**uriPlayerObjectP)->Realize(*uriPlayerObjectP, SL_BOOLEAN_FALSE);

// this will always succeed on Android, but we check result for portability to other platforms

if (SL_RESULT_SUCCESS != result) {

(**uriPlayerObjectP)->Destroy(*uriPlayerObjectP);

*uriPlayerObjectP = NULL;

return -1;

}

// get the play interface

result = (**uriPlayerObjectP)->GetInterface(*uriPlayerObjectP, SL_IID_PLAY, uriPlayerPlayP);

assert(SL_RESULT_SUCCESS == result);

(void)result;

// register callback on the buffer queue

result = (**uriPlayerPlayP)->RegisterCallback(*uriPlayerPlayP, _uriPlayerCallback, (void *)uriPlayerP);

result = (**uriPlayerPlayP)->SetCallbackEventsMask(*uriPlayerPlayP, SL_PLAYEVENT_HEADATEND); 

assert(SL_RESULT_SUCCESS == result);

(void)result;

// get the seek interface

result = (**uriPlayerObjectP)->GetInterface(*uriPlayerObjectP, SL_IID_SEEK, uriPlayerSeekP);

assert(SL_RESULT_SUCCESS == result);

(void)result;

// get the mute/solo interface

result = (**uriPlayerObjectP)->GetInterface(*uriPlayerObjectP, SL_IID_MUTESOLO, uriPlayerMuteSoloP);

assert(SL_RESULT_SUCCESS == result);

(void)result;

// get the volume interface

result = (**uriPlayerObjectP)->GetInterface(*uriPlayerObjectP, SL_IID_VOLUME, uriPlayerVolumeP);

assert(SL_RESULT_SUCCESS == result);

(void)result;

 

Thank you !

在 2015年4月14日星期二 UTC+8上午8:46:13，Glenn Kasten写道：

[Glenn Kasten]

Alex,

Thank you for the answers to the questions in the second paragraph

of my post.  But I still will need answers for the questions in the first paragraph:

   Which Android device and platform version are you using?

   (please include full text at bottom of your Settings / About device)

This will help me to investigate the issue.

Thank you,

Glenn

[alex zheng]

Glenn: 

    sorry, I miss the point of your question.

    My device run Android 4.4.2 system with a Allwiner A31 CPU, 

    and it have update the patch here(https://android-review.googlesource.com/#/c/105606/) to fix the recorder deadlock issue.

    (Actually the recorder still occurs a deadlock sometimes when I destroy it, and I don't know why orz.... My app now does not destroy the recorder to avoid this problem.

     Then I found the URI player sometime also deadlock too... and I think it is maybe a unfixed issue).

在 2015年4月14日星期二 UTC+8下午10:24:43，Glenn Kasten写道：

[Glenn Kasten]

Thank you, Alex. Unfortunately I do not have a device like that here to try.
Are you able to reproduce the problem on any Nexus family devices?
If so, please say which Nexus model, and the build number / version number.
Thanks

> --
> You received this message because you are subscribed to a topic in the
> Google Groups "android-ndk" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/android-ndk/G7dLKAGGL28/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to

[alex zheng]

Hey, Glenn: 

I have no nexus series devices right now.. 

But I made a test case here(https://github.com/alexIsACoder/openSL_test_case.git) to reproduce the problem base on NDK native-audio samples.

I run the test on an device with android 4.4.2 system, and the device deadlocked when run this test about ten minites. and I think it may easy to reproduce the problem on nexus device use this test.

Details: 

the device occurs a deadlock when doing this operation (run two special wav files):

#define sl_FILE_WAV1 "/sdcard/sound/no_answer.wav" // last about 3 seconds
#define sl_FILE_WAV2 "/sdcard/sound/calling.wav"
int audio_player_play(char* file)
{
sl_uriPlayer_set_play(SL_PLAYSTATE_PAUSED);
sl_uriPlayer_destroy();               //deadlock here ！！！！！！！！
sl_uriPlayer_create(file);
sl_uriPlayer_set_play(SL_PLAYSTATE_PLAYING);
}

 

void audio_player_test()
{
int state = SL_PLAYSTATE_STOPPED;
int i = 0;
int j = 0;
sl_create_engine();
while(1)
{
audio_player_play(sl_FILE_WAV1);
usleep((2880+ i) * 1000);
for(j = 0; j < i * 1000; j++);
audio_player_play(sl_FILE_WAV2);   //deadlock here, sometimes.
usleep(300 * 1000);
if (i == 200)
i = 0;
i += 5;
}
}

and it seems that this configs cause this problem, are there something wrong when I use this config?

SLAndroidConfigurationItf uriPlayerConfig;
SLint32 streamType = SL_ANDROID_STREAM_MEDIA;
result = (*uriPlayerObject)->GetInterface(uriPlayerObject, SL_IID_ANDROIDCONFIGURATION, &uriPlayerConfig);

assert(SL_RESULT_SUCCESS == result);
result = (*uriPlayerConfig)->SetConfiguration(uriPlayerConfig, SL_ANDROID_KEY_STREAM_TYPE, &streamType, sizeof(SLint32));
assert(SL_RESULT_SUCCESS == result);

在 2015年4月15日星期三 UTC+8上午8:18:04，Glenn Kasten写道：

[WB]

Just to chime in on this issue.  We have fought with this hanging issue on the OpenSL destroy.  Varies from device to device, and I haven't found what exactly leads to the issue.

But, we did implement a hack to work around the problem, though it certainly has some risks.

We create a thread to do the actual destroy, and the parent waits a short amount of time for the destroy to complete.  If the thread (destroy) fails to complete in a timely fashion, then the thread is terminated.  I do worry that the app and the OpenSL layer could be left if a bad state after that, but the app seems to be able to carry on after this happens, and can use audio properly next time it's opened.

Chris

On Monday, 21 April 2014 18:53:13 UTC-4, Jake wrote:

When I try to destroy an openSL recorder object as part of a tear down where I'm shutting down the mic the destroy function blocks forever.

This happens on Nexus 7 (KitKat) and some other KitKat devices (kernel 3.4.0)

When I run the same exact code on my SGH-i897 KitKat which has a different kernel version (3.0.101) the destroy function never blocks.

Is this a known issue?

      SLuint32 state = SL_RECORDSTATE_RECORDING;
   
      (*thisChannel->recorderRecord)->SetRecordState(thisChannel->recorderRecord, SL_RECORDSTATE_STOPPED);
   
      while (state != SL_RECORDSTATE_STOPPED)
      {
         (*thisChannel->recorderRecord)->GetRecordState(thisChannel->recorderRecord, &state);
         retries++;
         if (retries > 20)
         {
            bSuccess = 0;
            break;
         }
      }
    
      if (bSuccess == 0)
      {
         return -1;
      }


      /* Clear buffer queue */
      (*thisChannel->recorderBufferQueue)->Clear(thisChannel->recorderBufferQueue);
      /* THIS DESTROY FUNCTION BLOCKS FOREVER */
      (*thisChannel->recorderObject)->Destroy(thisChannel->recorderObject);
      thisChannel->recorderObject        = NULL;


NOTE: recorderObject is of type SLObjectItf