I think Ravi has made a good point and as far as I know staying in PAUSED state after EOS is a common practice for various players.
As a well-educated programmer, I don't think releasing acquired resources after its usage is that difficult:) And even you don't call release() manually, mediaplayer class's finalize() will be called eventually when it's garbage collected and release the player. I guess the main concern we have is that it lacks of robustness for not well-written applications, especially considering the reality of that applications might get randomly killed due to memory shortage. I did a simply test to kill the test app while playback is ongoing and found that music stopped immediately. So it seems binder driver did a good job to decrease the reference count of player object when client app is killed. -Freepine On Mon, Feb 9, 2009 at 4:57 AM, hdandroid <[email protected]> wrote: > > Let's take 3 types of components > > 1) Component must be moved to LOADED state for power savings - A > 2) Component can achieve power savings when moved to IDLE or LOADED > state - B > 3) Component cannot achieve power savings in any state - C > > Component A requires a well written App to call release() upon screen > timeout. > With a well writeen app, both component A and component B can benefit. > There is nothing much we can do for component C in any case. > With a not well written app (which does not call release()), platform > can help take advantage of capabilities of component B. > > Question is can the platform framework help very well written > component B when it is driven by not so well writeen App. > > Right now my component is see as the culprit as the platform continues > to consume power even when > playback has ended. The bad one here is really the app which was not > well written to call release() > upon idle screen timeout.I can save upto siginificant amount of power > (in the range of 50 -100mA depending > on the component). > > Startup latencies are not significantly variable. If a compoent > impementation strictly adheres to the specs recommendation, state > transitions should complete within a short amount of time (20ms > recommended by the spec when transition invloves buffer exchange - Sec > 3.2 of OMX IL 1.1.2). > > I don't think we are violating hardware abstraction here. Implicitly, > it is better to build the platform to help well written component B do > its best. Whether an IL client moves the component to IDLE or PAUSE > should not matter much if the component implementation is compliant > with the spec. Component A and C should continue to function even if > IL client moves them to IDLE instead of PAUSE. State transition delays > will be in the order of few milliseconds not noticable (I don't think > there is noticable delay in skipping from end of one song to the next > song with PV SW codecs on G1 - In this case, framwork is doing a > complete unload and reload of of potentially the same component) > > Sending codec config upon reinitalizing (idle to executing > transition): > This is not needed for all types of media formats (for example for AAC > ADTS and MP3). > Formats which need this would use OMX_BUFFERFLAG_CODECCONFIG to signal > config data. > This is an implementation issue in IL client and OMX component. This > is not an issue if both are spec compliant. > My component would anyway cache configuration data the first time it > is provided. If IL client does not provide it at the time of idle- > >executing transition, it would reuse the configuration information > provided at the very beginning. i.e., it would assume that there is no > configuration change. At this time I am playing with an MP3 component > which does not really require reconfiguration. > > > Sec 3.2 > The standards body identified the 20-millisecond timeout to be a > reasonable > response time for commands that may require buffer processing to be > completed; > the assumption here is that the longest buffer processing would be > less than > 30 milliseconds, which corresponds to 30-frames per second video. > > > Sec 2.1.4 > EXECUTING enables buffer processing to resume where the component left > off. > Transitioning from EXECUTING or PAUSED to IDLE will cause the context > in which > buffers were processed to be lost, which requires the start of a > stream to be > reintroduced. Transitioning from IDLE to LOADED will cause operational > resources > such as communication buffers to be lost. > > > On Feb 8, 11:26 am, GregS <[email protected]> wrote: > > Efficient power consumption is definitely worth pursuing. > > Unfortunately, to my knowledge, the OpenMAX IL spec does not give any > > guidelines on the expected power consumption in different states. > > Therefore there may be some OpenMAX components that might even need to > > be unloaded before there is any power consumption savings, others may > > have saving when driven to idle, or maybe for some it doesn't matter > > what state they are in (i.e., no power savings). Remember we're > > trying to create something that works across many different hardware > > platforms with different OpenMAX component implementations. Using > > similar logic to what you describe, it could be argued that the > > OpenMAX component implementation itself should handle the issues of > > power efficiency when paused rather than requiring every OpenMAX IL > > client that is interfacing with it to know the details of the power > > consumption in different modes as well the start-up latencies so > > proper tradeoffs could be made. The point of the OpenMAX IL interface > > is to abstract hardware details. > > > > Of course all of this is a purely abstract discussion so far and I > > realize we have to deal with non-ideal implementations. So in order > > to assess the tradeoffs of changing the logic, it would be helpful to > > understand if you have specific OpenMAX implementations of concern. > > If so can you provide numbers on the power consumption of different > > states? Part of the challenge of transitioning the component to the > > idle state is that the codec configuration data would need to be > > cached (not done today) so it could be used to reinitialize the state > > of the OpenMAX component. In pause state the component keeps all the > > configuration and state information so it isn't necessary to resend it > > when starting playback again somewhere in the same clip. > > > > On Feb 6, 8:54 am, hdandroid <[email protected]> wrote: > > > > > > > > > You would expect a well written app to issue release(). There is no > > > way to enforce this on all apps that run on the platform. > > > There will always be an app that is not well written which would not > > > call release(). > > > > > From a platform perspective, android platform can allow lower power > > > consumption with both types of apps. This would require Opencore to > > > move the component to Idle or loaded state at the end of playaback. I > > > agree that this would result in additional buffer exchange as you > > > mentioned. It is really small amount of work and it does not result in > > > noticable delays and it is not perceivable by human ears (while > > > playing the same clip again, user would experience the same delay that > > > would result when he/she moves to the next song - this change is not > > > perceivable) > > > > > Another case is music player app is put to background in PAUSE state > > > (at the end of playback) and HW continues to consume power. In this > > > case, well written app would call release() before going to > > > background. Some apps (not well written) apps may not perform this > > > operation. > > > > > I suggest that Opencore make this change (move to IDLE or LOADED at > > > the end of playback) allowing underlying OMX Codecs to stay power > > > friendly. This would allow the Android platform to stay power friendly > > > for both types of Apps (well written and not well written ones) > > > > > On Feb 5, 10:55 pm, rktb <[email protected]> wrote: > > > > > > I see what you are referring to. But, I think moving the component to > > > > PAUSE state might be preferable. > > > > > > First of all, where does this "Pause" come from? The PVPlayerEngine, > > > > at the end of a playback of content, drives the engine to a Paused > > > > state. This reduces the start up time if a same clip is being played > > > > in a loop. With this objective, let us evaluate the possible states. > > > > > > By moving the component to IDLE state, the buffers have to be > returned > > > > to the node. When the playback restarts for the same clip, the > buffers > > > > have to be resend to the component. This seems to be a waste. > > > > > > By moving the component to LOADED state, all the buffers would have > to > > > > be freed. So, restarting the clip would mean re-allocating > > > > buffers...which again seems to be a waste. > > > > > > If the application doesn't really want to consume any resources or > > > > wants to reduce power consumption, it should not wait at the end of > > > > the clip and should call mediaplayer->release(). > > > > > > -Ravi > > > > > > On Feb 5, 10:25 pm, hdandroid <[email protected]> wrote: > > > > > > > Can someone point me to the document? Is is somewhere on PV website > or > > > > > can I get it from git? > > > > > I am pretty sure OpenCore is not tearing down the playback session > - > > > > > it continues to keep the component in PAUSE after the end of > playback. > > > > > > > On Feb 5, 6:24 pm, Dave Sparks <[email protected]> wrote: > > > > > > > > When the app calls release, ultimately it will flow down to > through > > > > > > the framework to tear down the playback session. As Freepine > points > > > > > > out, the OMX decoder node in OpenCore is responsible for making > the > > > > > > appropriate calls to transistion the OMX component. There's an > OMX > > > > > > guide in the OpenCore docs that should help explain this. > > > > > > > > On Feb 5, 1:42 am, hdandroid <[email protected]> wrote: > > > > > > > > > I am not clear about the flow from the app's release() method > to the > > > > > > > OMX component. Isn't PV SW getting involved in changing OMX > component > > > > > > > state from PAUSE to IDLE or LOADED. > > > > > > > > > May be a better way to ask is who drives OMX Audio decoder's > state > > > > > > > transition when release() method is called. (I am assuming > there is > > > > > > > some kind of OMX IL client PV SW in android stack) > > > > > > > > > On Feb 4, 11:12 pm, Dave Sparks <[email protected]> > wrote: > > > > > > > > > > OpenCore has no context to do this, this is managed through > > > > > > > > application life cycle. > > > > > > > > > > The app is supposed to manage the resources by calling > release() on > > > > > > > > the MediaPlayer. If the screen times out, then the app's > onPause() > > > > > > > > method will be called and it should call the release() > method. If the > > > > > > > > app is not doing this - it's an app problem. > > > > > > > > > > On Feb 4, 10:26 pm, hdandroid <[email protected]> wrote: > > > > > > > > > > > At the end of audio playback, opencore framework places OMX > audio > > > > > > > > > decoder component in PAUSE state. User may not perform any > operation > > > > > > > > > after the end of playback (may be for several minutes). In > case of HW > > > > > > > > > audio decode, this will hold up resources and continue to > drain > > > > > > > > > current in PAUSE state. To avoid this from happening, > opencore can > > > > > > > > > either move the component to IDLE (or LOADED) state after > completing > > > > > > > > > playback of each song. This will allow the component to > release HW > > > > > > > > > resources and reduce power consumption > > > > > > > > > > > Is it a straight forward change to move the component to > idle state > > > > > > > > > instead of pause state at the end of playback? Any issues > with this > > > > > > > > > approach?- Hide quoted text - > > > > > > > > > > - Show quoted text -- Hide quoted text - > > > > > > > > - Show quoted text -- Hide quoted text - > > > > > > - Show quoted text -- Hide quoted text - > > > > - Show quoted text - > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
