static audio buffers and PCM streamin should do what i need. i don't see any javadoc api for the new cupcake features on the android site, can you point to where this code is located (ie: what package)?
-peter have you written up this FAQ? On Jan 7, 6:50 pm, Dave Sparks <[email protected]> wrote: > Thereisnoplantosupportjavax.sound. I guess I need to writeup a > media FAQ because this question gets asked repeatedly. > > Cupcake hassupportfor 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 havesupportfor > pitch and volume controls. > > On Jan 7, 1:19 pm, Pv <[email protected]> wrote: > > > Any update on anyone gettingjavax.sound.sampled (or something > > similar) working? > > > Pv > > > On Nov 23 2008, 12:49 am, MichaelEGR <[email protected]> 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 andsupport > > > 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.soundimplementation 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 tosupportLibsndfile (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 presentlyplanto expose audio I/O to Android developers on my > > > hardware. So in time this is _going_ to be done already. > > > > Seeing asthereisn'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 andsupportin 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 > > >supporthigh channel count analog, ADAT, audio over HDMI, and even > > > MADI I/O in time.Thereis absolutelynoreason tosupportJava 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 PortAudiosupportwith 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 PortAudiosupportout quickly and efficiently > > > for all as I'm passionate about audio and really like and am adopting > > > Android in a big way... > > > > Thoughts anyone? > > > > Istherea full time resource at Google dedicated to audiosupport > > > 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 -~----------~----~----~----~------~----~------~--~---
