You can simulate this behavior under a test program by the following sequence:
MediaPlayer mp = MediaPlayer.create(); mp.setDataSource(path_to_test_file"); mp.prepare(); mp.seekTo(offset_in_msecs); It could be that the OMX h/w decoder isn't getting all the configuration data it needs under these circumstances. We don't currently have an AAC h/w decoder to test it internally, the G1 is using the OpenCore software codecs. On Feb 9, 6:59 pm, chrisk <[email protected]> wrote: > Yes, I am seeing a problem. When resuming a session, the OMX component > will need to be re-loaded and > configured correctly again. With AAC, for example, opencore will send > a config buffer at the beginning of the file. > Does the config buffer get sent again? > > I think for my debugging purposes, you have already given me the info > I need to work with. Resuming this playback > after rebooting the device is essentially the same as starting a new > decode session (loaded->idle->executing for OMX) > but starting from the saved location in the file. > > I am not sure how opencore handles the reposition required for this to > work consistently. > Perhaps, the same port parameter negotiation is done again and all > needed config buffers > are sent again to the OMX component? I can verify this easily enough. > > I do know that a the typical ff/rewind type of reposition works well, > so I am not sure what the difference is > when doing a reposition immediately if trying to resume a previously > terminated session. > > On Feb 9, 4:33 pm, Marco Nelissen <[email protected]> wrote: > > > On Mon, Feb 9, 2009 at 1:06 PM, Chris Kelly <[email protected]> wrote: > > > I have noticed that when booting up after this has happened, then navigate > > > to Music player application, the previous session (song and song location > > > on > > > progress bar) are restored. I assume this is done by some entry in /data? > > > If > > > The music app stores its state in a SharedPreferences and restores it > > from there. > > > > the app was killed to free resources after a pause, then why would this > > > playback session data need to be stored. > > > I don't understand what you're asking. The music app restores its > > previous state so that, from the point of view of the user, it looks > > like it's always there, even if it got killed while the user wasn't > > using it, or after restarting the phone. > > > > It seems that the OMX/opencore implementation does not like to start a > > > decode session in the middle of a file. > > > All the music app does when it restores its state is to open the file > > for playback and then seek to the saved position. > > Are you seeing any problems with that? Does it happen with any > > particular file or file type? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "android-framework" 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-framework?hl=en -~----------~----~----~----~------~----~------~--~---
