HW continues to cosume power from the time the component is put to PAUSE to the time finalize() is called. This duration could be significant and result in unnecessary power consumption. (if you are lukcy the app might get killed - otherwise HW continues to consume power)
Even if the component is moved to OMX IDLE state, user interface can show that player is PAUSED. There is no change in UI behavior with this approach. On Feb 8, 6:33 pm, Freepine <[email protected]> wrote: > 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 > > ... > > read more »- 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 -~----------~----~----~----~------~----~------~--~---
