[android-developers] Re: imeem and buffering audio with MediaPlayer
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 application is handling > its streaming audio. It seems to be able to buffer the entire track > as quickly as possible, as well as buffering the upcoming track before > it is played. > > As far as I can tell from reading several other threads here, that is > only possible by writing the track to a file and then pointing the > media player at the file. But I'm watching df pretty closely and I > don't see the space used on any of the partitions going up as it > buffers. Is the data hiding somewhere? > > Another possibility that was raised was that you could do this using a > file descriptor associated with a socket, sort of like in this > example: > > http://groups.google.com/group/android-developers/browse_thread/threa... > > But apparently this doesn't work--I'm guessing maybe because the > MediaPlayer tries to seek on the fd to determine its length? > (Guessing based on its behavior with normal files that are appended to > after it starts playing.) > > Is there some other possibility? Obviously the imeem folks have it > working well somehow, but I don't quite get how. Some of the other > threads I've read seem to be telling me this isn't quite possible > (links below). > > If I just pass URLs to MediaPlayer one after the other in the normal > way, there's way too long of a delay (10+ seconds) between tracks. > That's too long; long enough for the user to start thinking, "Why > isn't this working?", pick up the phone and double-check it, etc. So > I need some way to start buffering an upcoming track in advance (maybe > create a second MediaPlayer and call prepareAsync() early... although > this seems messy, and it can't be what imeem is doing). > > Thanks for any help. > > Related threads: > > http://groups.google.com/group/android-developers/browse_thread/threa...http://groups.google.com/group/android-developers/browse_thread/threa...http://groups.google.com/group/android-developers/browse_thread/threa... --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: imeem and buffering audio with MediaPlayer
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, Dan McGuirk wrote: > > > Hi, > > > I'm wondering if anyone knows how the imeem application is handling > > its streaming audio. It seems to be able to buffer the entire track > > as quickly as possible, as well as buffering the upcoming track before > > it is played. > > > As far as I can tell from reading several other threads here, that is > > only possible by writing the track to a file and then pointing the > > media player at the file. But I'm watching df pretty closely and I > > don't see the space used on any of the partitions going up as it > > buffers. Is the data hiding somewhere? > > > Another possibility that was raised was that you could do this using a > > file descriptor associated with a socket, sort of like in this > > example: > > >http://groups.google.com/group/android-developers/browse_thread/threa... > > > But apparently this doesn't work--I'm guessing maybe because the > > MediaPlayer tries to seek on the fd to determine its length? > > (Guessing based on its behavior with normal files that are appended to > > after it starts playing.) > > > Is there some other possibility? Obviously the imeem folks have it > > working well somehow, but I don't quite get how. Some of the other > > threads I've read seem to be telling me this isn't quite possible > > (links below). > > > If I just pass URLs to MediaPlayer one after the other in the normal > > way, there's way too long of a delay (10+ seconds) between tracks. > > That's too long; long enough for the user to start thinking, "Why > > isn't this working?", pick up the phone and double-check it, etc. So > > I need some way to start buffering an upcoming track in advance (maybe > > create a second MediaPlayer and call prepareAsync() early... although > > this seems messy, and it can't be what imeem is doing). > > > Thanks for any help. > > > Related threads: > > >http://groups.google.com/group/android-developers/browse_thread/threa.. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: imeem and buffering audio with MediaPlayer
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 is > using an HTTP proxy on the device. The proxy server could be buffering > up the next stream while the current stream is playing. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: imeem and buffering audio with MediaPlayer
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 believe that OpenCore seeks to the end immediately to find the end of the file and that won't work with a partial download. On Jan 3, 12:37 am, blindfold wrote: > 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 is > > using an HTTP proxy on the device. The proxy server could be buffering > > up the next stream while the current stream is playing. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: imeem and buffering audio with MediaPlayer
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 solution in a future SDK, until then continuing with the "cache-to-flash" approach. Regards On Jan 3, 5:33 pm, Dave Sparks wrote: > 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 believe that OpenCore seeks to the end immediately to > find the end of the file and that won't work with a partial download. > > On Jan 3, 12:37 am, blindfold wrote: > > > 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 is > > > using an HTTP proxy on the device. The proxy server could be buffering > > > up the next stream while the current stream is playing. > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: imeem and buffering audio with MediaPlayer
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 a few months if the API is improved. On Jan 2, 10: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. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: imeem and buffering audio with MediaPlayer
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 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 a few months if the API is improved. > > On Jan 2, 10: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. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: imeem and buffering audio with MediaPlayer
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 functionality mentioned here appears quite significant for many of us - although I cannot judge if it also addresses Dan McGuirk's needs. Or am I confused about what is coming up in the short term? Regards On Jan 6, 11:49 pm, Dave Sparks wrote: > I don't think there will be significant changes to the MediaPlayer API > deployed on devices in the next few months. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: imeem and buffering audio with MediaPlayer
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 changes address Dan McGuirk's needs unless he's planning on doing MP3 decode in Java. Cupcake is pretty much feature complete and we're working on stabilization now. I'm hoping to do some major updates to the media framework in the release after Cupcake. On Jan 7, 6:17 am, blindfold wrote: > 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 functionality mentioned here appears quite significant for > many of us - although I cannot judge if it also addresses Dan > McGuirk's needs. Or am I confused about what is coming up in the short > term? > > Regards > > On Jan 6, 11:49 pm, Dave Sparks wrote: > > > I don't think there will be significant changes to the MediaPlayer API > > deployed on devices in the next few months. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: imeem and buffering audio with MediaPlayer
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 hardware? If so, I hope it does not also bypass the low- level audio mixer, because apart from my own on-the-fly synthesized audio, I simultaneously output (asynchronously, depending on events) my own sampled human speech as well as speech from the Android TTS engine. It would be horrible if AudioTrack blocked the audio output from simultaneous access by Mediaplayer. I had been expecting a new API method like MediaPlayer.create(Context context, byte[] audioData) as a minor extension to android.media.MediaPlayer, but now I am again confused about what to expect, and actually worried about the interaction between AudioTrack and MediaPlayer. Indeed there is no word about (low-level) audio mixing or MediaPlayer in http://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob_plain;f=media/java/android/media/AudioTrack.java;hb=cupcake So, will AudioTrack and MediaPlayer "play" along nicely? Thanks On Jan 8, 4:07 am, Dave Sparks wrote: > 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 changes address Dan McGuirk's needs unless he's > planning on doing MP3 decode in Java. > > Cupcake is pretty much feature complete and we're working on > stabilization now. I'm hoping to do some major updates to the media > framework in the release after Cupcake. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: imeem and buffering audio with MediaPlayer
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 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 hardware? If so, I hope it does not also bypass the low- > level audio mixer, because apart from my own on-the-fly synthesized > audio, I simultaneously output (asynchronously, depending on events) > my own sampled human speech as well as speech from the Android TTS > engine. It would be horrible if AudioTrack blocked the audio output > from simultaneous access by Mediaplayer. > > I had been expecting a new API method like MediaPlayer.create(Context > context, byte[] audioData) as a minor extension to > android.media.MediaPlayer, but now I am again confused about what to > expect, and actually worried about the interaction between AudioTrack > and MediaPlayer. > > Indeed there is no word about (low-level) audio mixing or MediaPlayer > in > > http://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob_... > > So, will AudioTrack and MediaPlayer "play" along nicely? > > Thanks > > On Jan 8, 4:07 am, Dave Sparks wrote: > > > 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 changes address Dan McGuirk's needs unless he's > > planning on doing MP3 decode in Java. > > > Cupcake is pretty much feature complete and we're working on > > stabilization now. I'm hoping to do some major updates to the media > > framework in the release after Cupcake. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: imeem and buffering audio with MediaPlayer
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 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 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 hardware? If so, I hope it does not also bypass the low- > > level audio mixer, because apart from my own on-the-fly synthesized > > audio, I simultaneously output (asynchronously, depending on events) > > my own sampled human speech as well as speech from the Android TTS > > engine. It would be horrible if AudioTrack blocked the audio output > > from simultaneous access by Mediaplayer. > > > I had been expecting a new API method like MediaPlayer.create(Context > > context, byte[] audioData) as a minor extension to > > android.media.MediaPlayer, but now I am again confused about what to > > expect, and actually worried about the interaction between AudioTrack > > and MediaPlayer. > > > Indeed there is no word about (low-level) audio mixing or MediaPlayer > > in > > >http://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob_... > > > So, will AudioTrack and MediaPlayer "play" along nicely? > > > Thanks --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
