| french | english |
 |
|
| Sign in | |
| 21-11-11 / 22:48 : Android : audio latency problem (cjed) |
| Android faces a high performance problem (very high audio latency, see also here) that prevents from using it to develop software samples players and effects units). Some gain can be achieved by customizing kernel's settings (differ from all hardware vendors) however it can't match the required low buffers, and Google still didn't provide any solution in Android 4's SDK : The WHOLE audio architecture is a joke. http://www.netmite.com/android/mydroid/development/pdk/docs/audio_sub_system.html It's one of the worst over-engineered pieces of software i have ever seen in my life. I believe that most people who had the unpleasant experience to look at the sources will agree: the amount of layers and complexity added above the linux sound system is ridicolous. Whats the point? You don't gain any extra functionality. Security? Priority handling (Phone calls)??? If that is Googles concern then the solution is at best amateurish and doesn't really work (i have killed/locked the audio system several times - by accident - with my audio tests). The "standard" way to do audio I/O would be to use interrupts which access ring buffers in a locking-free way - this idea is at least 20 years old. What makes this even more worse is that Google: - doesn't care/understand the problem - doesn't respond to this issue - ignores a huge market (games, music apps, ...) - provides wrong solutions - a configuration option (android.hardware.audio.low_latency) is not enough. - defining 45ms as low latency? are you serious? shows again lack of knowledge. 5-10ms would be low-latency. - OpenSL ES !? Again, a new (very complex) layer above AudioTrack without solving fundamental issues - great :( you only get rid of the Java layer. In addition the hardware buffers on some devices (afaik Qualcomm at least) are huge and are required to filled before any audio output can be started. This prevents low-latency audio on some devices. Finally the scheduling frequency (20 ms or so) of Android further limits the minimum size of any buffers. IK Multimedia may have found some trick, however the workaround won't be available before months (and may be restricted to their applications), and couldn't circumvent Google OS design limitations : high number of layers, lack of skills in audio management principles, use of JNI). Recent graphical performance tests with Google Nexus 2 (3 times slower than iPhone 4S) also confirm that Google does not have experience beyond javascript, while Apple have had a long time with assembly and kernel development. |
| Comments |
| Write a comment |