Excellent! That should suffice (for me). I fuse 64 independent audio
channels internally, but that part is not exposed to Android.
Thanks
On Jan 9, 4:59 am, Dave Sparks wrote:
> Yes, AudioTrack and MediaPlayer will play along very nicely.
>
> MediaPlayer uses AudioTrack for its low-level audio
Yes, AudioTrack and MediaPlayer will play along very nicely.
MediaPlayer uses AudioTrack for its low-level audio interface. Up to
32 tracks of audio can be mixed.
On Jan 8, 5:49 am, blindfold wrote:
> Thanks David. You say that Cupcake's AudioTrack allows for
>
> > generating raw audio in the a
Thanks David. You say that Cupcake's AudioTrack allows for
> generating raw audio in the application to be streamed to the audio output.
> It does not include a byte stream interface to the MediaPlayer, for example.
Does this mean that it bypasses MediaPlayer altogether in accessing
the audio ha
That refers to the AudioTrack and AudioRecord interfaces which allow
for things like recording from the microphone and generating raw audio
in the application to be streamed to the audio output. It does not
include a byte stream interface to the MediaPlayer, for example.
I don't see that those ch
The Cupcake roadmap reads about new features at
http://source.android.com/roadmap/cupcake
"Access to the raw audio data for playback and recording from
application code" and "Streaming audio I/O for applications". The
associated MediaPlayer API changes well may be minimal, but the
resulting func
I don't think there will be significant changes to the MediaPlayer API
deployed on devices in the next few months.
On Jan 4, 7:08 pm, Dan McGuirk wrote:
> Thanks for the reply and the suggestion.
>
> I do wonder, though, how long this will remain the suggested
> solution. Are there plans to upd
Thanks for the reply and the suggestion.
I do wonder, though, how long this will remain the suggested
solution. Are there plans to update the API to allow more
flexibility? I wouldn't really want to put a lot of effort into
developing and maintaining this kind of scheme just to throw it away
in
Thank you David. I was considering whether I should pursue this
approach as an ad interim solution, but lacking experience in this
sort of http server programming it could take a lot of time and effort
to figure things out and make it robust, so in principle I'd rather
wait for the more general so
I haven't tried it myself and don't have any sample code. The proxy
approach has one advantage over simple file playback: It can start
playing as soon as there is a reasonable amount of content downloaded
- assuming the content is formatted properly for streaming. For local
file playback, I believ
How does the HTTP proxy approach perform as compared to saving to
flash and then playing from there? Is there any sample code for trying
this proxy server workaround for playing audio?
Thanks
On Jan 2, 6:32 pm, Dave Sparks wrote:
> I haven't looked at imeem, but one way to get around the issue
ooh thats an interesting idea.
On Jan 2, 9:32 am, Dave Sparks wrote:
> I haven't looked at imeem, but one way to get around the issue is
> using an HTTP proxy on the device. The proxy server could be buffering
> up the next stream while the current stream is playing.
>
> On Dec 30 2008, 11:37 pm
I haven't looked at imeem, but one way to get around the issue is
using an HTTP proxy on the device. The proxy server could be buffering
up the next stream while the current stream is playing.
On Dec 30 2008, 11:37 pm, Dan McGuirk wrote:
> Hi,
>
> I'm wondering if anyone knows how the imeem appl
12 matches
Mail list logo
