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
-~----------~----~----~----~------~----~------~--~---

Reply via email to