are u means that they not going to support TTS and STT in android???
wesley. On Thu, Jan 8, 2009 at 10:50 AM, Dave Sparks <davidspa...@android.com>wrote: > > There is no plan to support javax.sound. I guess I need to writeup a > media FAQ because this question gets asked repeatedly. > > Cupcake has support for streaming PCM audio in and out of Java. It > also supports static buffers, i.e. load a buffer with sound data and > trigger (one-shot) or loop. Both static and streamed buffers have > support for pitch and volume controls. > > On Jan 7, 1:19 pm, Pv <p...@swooby.com> wrote: > > Any update on anyone getting javax.sound.sampled (or something > > similar) working? > > > > Pv > > > > On Nov 23 2008, 12:49 am, MichaelEGR <foun...@egrsoftware.com> wrote: > > > > > 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---