Greets... Wow.. good thread and discussion thus far. Best and most recent audio thread I've seen.
I am an audio/graphics professional and my first project, for kicks, is to port my desktop Java Quake3 class game engine to Android and OpenGL ES as a test of well my ability to get Q3 tech playing with ES and Android and it didn't take long to realize the state of audio in SDK 1.0_r1 is not suitable for lots of audio stuff I'd like to accomplish in general and some novel features for my port (IE voice chat with desktop clients from built in mic on G1, etc; fun!). We'll see how the Q3 port turns out; gonna hack a file based push to talk feature most likely via MediaRecorder; delayed audio w/ this though and only one way to desktop clients to show proof of concept. I specifically did not adopt or even look at Android until a handset device was released and the SDK hit 1.0 simply because I knew the platform probably would not be complete and I don't have the time / desire to work around incomplete APIs / implementation (yes, was correct on that; for audio at least; lots of gold to be had elsewhere; seriously, kudos Android team et al, I haven't been this excited in a while about a new tech!). So, yes, lets continue to discuss how to solve the audio issue that encroaches on all of us who want performance audio on Android and all 'droid devices in general. I will throw in my two cents on how I _am_ (not would be) solving it after dealing with the woes and inadequacies of Java Sound on the desktop _for years_ from an API perspective to simply incomplete implementations on various platforms and JVM versions. (Java Sound - Write once, test everywhe... oh wait you mean it doesn't fully work on <X> platform at all?.?. gah!!!) One solution on the desktop has been to ditch Java Sound and support PortAudio (www.portaudio.com) via JNI. I propose that Android can also provide the best and most _portable_ audio solution not only on the G1 and other devices, but _future_ hardware that supports Android by adopting PortAudio and exposing a lean and mean API to developers that then can be further extended with higher level APIs for purpose built processes (speech detection / Jspeex port / DSP processing, even a javax.sound implementation built _on top_ of PortAudio, etc). What is needed is simple and efficient raw audio I/O functionality at the core; PortAudio provides this and only this! For file I/O it's not a bad idea to support Libsndfile (http://www.mega-nerd.com/libsndfile/). Between PortAudio & Libsndfile raw hardware and file based audio I/O can be solved by time tested open source solutions. Now... I mentioned future hardware supporting Android... I just so happen to be developing an embedded audio hardware product that focuses on advanced spatial processing (think large scale 2D and 3D sound arrays; I have a 32 speaker hemisphere setup at my facility in SF for instance; check here for those interested in an overview I published for the recent AES conference in SF w/ picts & equipment specifications -- http://research.egrsoftware.com/conferences/2008/aes2008/) and after finally dipping into Android (IE G1 & SDK 1.0 finally available and in my hands) I've decided unanimously and almost instantly to ditch my previous path which was Analog Devices Blackfin/ Sharc based processors running uClinux and am switching to the TI OMAP3 3550 and Android as the processor/stack. In doing this I already am adopting PortAudio on my future Android based hardware and this is how I presently plan to expose audio I/O to Android developers on my hardware. So in time this is _going_ to be done already. Seeing as there isn't a published / unified vision on where to take audio I/O for Android as is I do strongly propose supporting PortAudio out of it's shear elegance and wide activity and support in the audio community at large across numerous OSes / desktop to mobile. Not only will it provide a mean and lean audio API at the core, but it will be portable at its core between different hardware configurations on hand sets to say custom built audio hardware like my own efforts which will support high channel count analog, ADAT, audio over HDMI, and even MADI I/O in time. There is absolutely no reason to support Java Sound as the core implementation just because that is the most visible Java API for audio to the layman programmer; that would be archaic and quite honestly just silly which is nice to see folks mentioning in this thread Including David S. Audio professionals and people serious with audio and Java _likely_ concur. Anyway... Since I'm already planning PortAudio support with my own 'droid based hardware and it's _very_ applicable to Android as a whole for the entire developer community across all devices and isn't based on a trade marked open or proprietary company oriented API / implementation (SoniVox, sorry!), but a tried and true open source solution that is known to work for many widely adopted cross platform audio applications to great ASIO and device specific hardware it is a compelling way forward. I'll even go so far as offering to get on that black bus for a few months and simply knock PortAudio support out quickly and efficiently for all as I'm passionate about audio and really like and am adopting Android in a big way... Thoughts anyone? Is there a full time resource at Google dedicated to audio support with Android or is this a Sun like operation where audio is completely ignored / just an after thought and one resource at best is sometimes on the gig? Regards, --Mike --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
