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 - --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
