AssetManager can improve Android file system read performance, but it is supported since v2.3.
There is a pull request for it.
I am not sure if we can give up v2.2 to enjoy the performance.
Any idea?
According to http://stats.unity3d.com/mobile/os.html v2.2 is installed only on 1.5% of devices. If throwing this version overboard will result in sufficient performance improvement I think it is essential to do so.
Any other idea?
I would suggest to ditch 2.2 too in order to move forward.
1.4 on Unity3D stats, and 4.0 on Android Dashboard (http://developer.android.com/about/dashboards/index.html) clearly shows it’s < 5% for sure and disappearing.
Setting the minimum required version to 2.3 will also allow us to use NativeActivity (http://developer.android.com/reference/android/app/NativeActivity.html)
Also OpenSL ES was introduced in 2.3 which allows Audio playback from native code without using jni.
@Andre, I think those are great points. NativeActivity and OpenSL (as well as increased performance) are a huge bonus. I’d say it’s definitely worth scrapping 2.2 support for those.
I also agree with everyone. We can move forward to v2.3 
I also agree, let’s move forward
Thank you.
We are releasing a new version these days.
So i think this PR will be merged in next version if it is right to be merged.
Thank you @minggo.
Everyone - please do review my pull request if you get a chance https://github.com/cocos2d/cocos2d-x/pull/2392
I am in the process of moving to use NativeActivity for the Android port. This work is in progress and I have opened and issue to track this (https://github.com/cocos2d/cocos2d-js/issues/21)
I have also filed an issue regarding the audio implementation (https://github.com/cocos2d/cocos2d-js/issues/20) While some code is in place to move to using Open SL I think this change will take longer … mostly because I have to determine the quality of Android Open SL implementations across devices. (I have heard of too many bug reports regarding the quality of audio support previously. Although I think this has changed in newer versions of Android.)
thanks,
Surith
OpenSL ES implementation on Android is mostly incomplete, true.
And the docs are wrong at some time (I remember some centibel stuff which was millidel, or the contrary).
When I first implemented it in R-TYPE in order to circumvent Galaxy S2 (GT-I9100) SoundPool bug, it was a pain.
What about releasing next version without those untested patches and get a chance to test them a lot in order to include them safely in the realease after ?
Beware of OpenSL ES only implementation.
It is NOT implemented on 2.3 “pseudo” devices such as Kindle Fire first generation and Barn & Noble Nook Color.
What we need is something like FMOD did, detect at runtime if OpenSL ES is available, use it if so, and if not, fallback to AudioTrack/JNI.
Romain, Thanks for your feedback.
As minggo mentioned he plans to merge the AssetManager patches for the next release, so it will not be in this release.
Regarding Open SL ES usage - please look at the ticket filed - https://github.com/cocos2d/cocos2d-js/issues/20
The main reason to rewrite the audio implementation is to improve performance by asynchronously loading samples… it is not yet determined whether it is better to move to Open SL or whether it is better to stay with the Android SDK Java API. I have seen too many bug reports about Android’s audio implementations and this is the reason why we will make these changes as carefully as possible. I’ll keep the issue and the forums updated with any results of testing. Any changes it will be in a separate fork in my repo so that it is available to everyone for testing before it is merged.
At least OpenSL should be an option that is available in an official release. The Samsung Galaxy S2 has some serious issues when trying to play sounds using the SoundPool API (simply crashes sooner or later) and MediaPlayer maybe to slow for sound effects in action games.
The same is true for OpenSL however, we had some issues with destroying an OpenSL player object that has streamed a sound before. The Destroy() call never returned, freeting the application.
Therefore I would recommend the following for Sound playback on android.
- Use MediaPlayer for music and sounds that aren’t played very often (intro jingles for example)
- Use OpenSL to play low-latency sound effects (use BufferQueue for playback). When OpenSL is not available fall back to SoundPool to play the sound.
- OpenSL library should be manually loaded using dlopen() and used if availlable. Actually the same could be done with the native AssetManager, so we would not even need to drop 2.2 for that.
So maybe we only need to drop 2.2 when we are making a change to use NativeActivity.
Do we know if Samsung has fixed their bugs with their latest updates for the Galaxy S2?
I have only tried it with the latest 2.3 build available (2.3.6 I think). However if Samsung still distributes their updates only via Kies I doubt that many people will get the update.
Still I would prefer using OpenSL with buffers over SoundPool as you simply have much more control over the lifecycle of the sound, you can check when it is playing, you can add callbacks when it has been finished etc…
Also we never had issues with using the buffered player so far.
@Andre thanks for the details.
@folec r
I think it is a good idea to use dlopen, then we don’t have to drop 2.2.
Does NativeActivity give us more benifits?
I’ll work on the native rendering code after this release… let’s decide once we have performance numbers and can quantify the benefits.