Threadpool in android shared library

#1

Hello Jules.

I am still working on creating an android shared library with juce code inside. No problems creating it, but when I create a threadpool object inside a library, I get a segmentation fault. I can create a threadpool inside an application, but just not from within a library. Do you know of any obvious reason why this won't work?

I cannot step into the library code from within the android debugger. But I've narrowed it down by creating a shared library that does only that: constructing a threadpool object. This is the stack I get at that point:

Thread [1] (Suspended: Signal 'SIGSEGV' received. Description: Segmentation fault.)    
    8 _JavaVM::AttachCurrentThread()  0x751c00dc    
    7 juce::ThreadLocalJNIEnvHolder::attachToCurrentThread()  0x752279d4    
    6 juce::ThreadLocalJNIEnvHolder::attach()  0x752275dc    
    5 <symbol is not available> 0x7522ad28    
    4 threadEntryProc()  0x7522ad94    
    3 __thread_entry()  0x4006d174    
    2 pthread_create()  0x4006d30c    
    1 <symbol is not available> 0x00000000    

While i don't know the ins and outs of it, it look like some JNI code is called here. Does that mean that the compiler instructions (JUCE_ANDROID_ACTIVITY_CLASSNAME and JUCE_ANDROID_ACTIVITY_CLASSPATH) are used here?

Regards,

yvan

 

#2

Yes, I ran into this as well... my use of JUCE in a specific android shared library has no need of any JNI stuff, so I made the following change:

In modules/juce_core/native/juce_posix_SharedCode.h I added the following condtionals inside the AndroidThreadScope struct.

            AndroidThreadScope()   { if (android.activity) threadLocalJNIEnvHolder.attach(); }

            ~AndroidThreadScope()  { if (android.activity) threadLocalJNIEnvHolder.detach(); }

 

 

 

#3

Thanks - I'll add some safety checks like that for you Dllers!

#4

Oh! That would be great.

Will this also help for android audio? The problem there are the JNI_CLASS _MEMBERS used to access AudioTrack. If there was a way to just disable audiotrack, that would fix it, i guess.

Btw, what's the logic for using audioTrack on android nowadays? Isn't openSL the best way to go for low-latency audio? And I haven't seen any recent devices that don't support openSL ES.

UPDATE:

I took another dive into the juce internals. The improvements for dll checking you mentioned above fixed part of my problem. But I still had trouble when opening a device. I ended up changing the OpenSLAudioIODevice constructor. I commented out this line:

AndroidAudioIODevice javaDevice (String::empty);

and set the inputLatency and outputLatency fixed to 50

After those changes I can play audio when using a shared library based on juce. I'd call that a succes :-) Now the only thing i'm still worried about is if those latency values are of any importance. 

regards,

yvan

#5

Reply self-revoked.