If top-down approach is implemented then system does not have to initiate bottom-up approach. Bottom-up approach is useful when top- down is not impemented or not initiated for some reason.
For the particular system that I am concerned: top-down is not working (cupcake). I have the ability to support bottom-up provided PV framework enables suspension policy and fully supports the call flow. There can always be a situation where bottom-up approach is unavoidable (app/player cannot detect HW loss/reset) >> > I.e. should the underlying low-level components be the ones to detect > resource pre-emption and propagate the suspension request from the > "bottom-up" to the Opencore framework and application layer? > > Or should the application/player should be aware of resouce preemption > and inform the underlying framework/codec compoents (say, by issuing a > pause) before this preemption happens. On Feb 26, 10:58 am, v_dusan <[email protected]> wrote: > OMX Component suspension should be viewed not only as an interaction > between OMX component and OXM client, > but from the perspective of the overall system design. > > I.e. should the underlying low-level components be the ones to detect > resource pre-emption and propagate the suspension request from the > "bottom-up" to the Opencore framework and application layer? > > Or should the application/player should be aware of resouce preemption > and inform the underlying framework/codec compoents (say, by issuing a > pause) before this preemption happens. > > OpenCore framework reacts to the OMX_ErrorComponentSuspended error > event as it does with most error events reported from OMX component. > The error event is reported to the higher layers (player engine/app) > which initiate the current playback tear-down in this case. This > results in stopping and resetting the OpenCore framework (i.e. > transitioning the underlying OMX component into Idle and then Loaded > state - and finally freeing the OMX component handle). > > The OMX component needs to be able to transition to idle and then to > loaded state even if it is suspended (i.e. in the paused state due to > suspension) - as stated in section 2.1.17.6 of OMX Spec IL 1.1.2: > > "IL client may perform any of the normal state transitions on a > suspended component with the following exception: a client may not > transition a suspended component into the Executing state." > > If the underlying omx component is capable of transitioning to idle, > and then to loaded state (even if it is suspended) - there should not > be a problem nor would it cause a crash. > > On Feb 25, 8:48 pm, hdandroid <[email protected]> wrote: > > > > > Looks like OpenCore does not allow component suspension. We need to > > enable this policy to handle the case of resource preemption with HW > > codecs. Looking for support on OMX call flow for the entire section > > 3.1.2.6.3 on "Suspension Due to Pre-emption of Resources" > > > Cupcake OpenCore crashes when OMX_ErrorComponentSuspended event is > > reported by OMX component.- 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 -~----------~----~----~----~------~----~------~--~---
