Hi Jay! > > I have created audio and video player based on api_test sample > program. I am trying out the following use-case: > > 1) Audio Player - acquires audio_playback resource and starts playing > 2) Video Player - acquires audio_playback resource and starts playing > > This results in a resource_callback in the Audio Player, where it > comes to know that it has "lost" the audio_playback resource. Hence it > pauses the audio Playback. > > 3) Video Player is paused - so it releases audio_playback resource > This results in a resource_callback to the video player that it has > "lost" the audio_playback resource > > At this point, I expect the Audio Player to get a resource_callback, > saying that the audio_playback resource is "available" . However, I > see that there is no resource_callback happening in Audio Player. Is > this behaviour correct?
There should be a callback every single time a resource set changes state. If there isn't, there's a bug somewhere. :-) There are three states that a resource set can have after initialization: "acquired", "available", and "lost". "Available" means that the resource is available for acquiring. It is still lost, meaning that the application does not have it, but the application is told that it will (most likely) get it if it tries to acquire it. You should not use "available" as part of your state machine -- for this case, tracking the "acquired" state will be enough. If "autorelease" is off (as it is by default) and app1 has called acquire, app1 will automatically reacquire the resource set when app2 releases it. > I am asking because Audio Player is depending on the resource_callback > telling it that the audio_playback resource is "available" when the > Video Player releases the resource audio_playback, so the Audio Player > can resume the playing of the audio(i.e audio playback) When Video Player releases the resource set, Audio Player should have it's own resource set do transition "available" -> "acquired" and a callback be called accordingly. Ismo _______________________________________________ IVI mailing list [email protected] https://lists.tizen.org/listinfo/ivi
