Hi Ismo, 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? 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) Thanks, Jay -----Original Message----- From: Puustinen, Ismo [mailto:[email protected]] Sent: 18 September 2014 18:31 To: Jay D Bhatt Cc: [email protected] Subject: Re: Resource Acquiring of same application class and priority logic Hi Jay, Do you have the video and audio playback in the same process? If yes, just use the same resource set for both of them (assuming you don't need video_playback resource). If the resource sets are in separate processes and you don't have communication between them, you can use the resource sets to preempt the previously playing application. Anyway, the sounds should not be mixed, if you have two resource sets and haven't set the resources to have shared attribute. You should read the documentation here: https://01.org/murphy/documentation/resource-aware-applications Try also to experiment with a resource client (the D-Bus client at https://github.com/01org/murphy/blob/master/doc/plugins/resource-dbus/resource-client.py or the native one in murphy-tests package). Run the resource clients in two terminal windows and get a feeling how the resource sets are acquired and released and how the preemption works. Then see how running the resource clients affects your media player application. Ismo Puustinen <[email protected]> On Thu, 2014-09-18 at 12:21 +0000, Jay D Bhatt wrote: > Hi Ismo, > > I like to only acquire and release audio_playback resource. I am currently > not thinking about video_playback resource. > > So, for audio_playback resource, the sequence is like 1) audio player played > audio_playback will be acquired to play audio 2) audio is still playing, > then I play video, so now it also wants audio_playback resource. > > Now, How video player will get audio_playback resource? I already have > acquire function to acquire audio_playback resource in video player, but it > does not acquire resource completely. I get audio and video sound mixed. > > Should I implement logic to do something in video player or I should expect > murphy to do this automatically for me? > > Thanks, > Jay > > > > -----Original Message----- > From: Puustinen, Ismo [mailto:[email protected]] > Sent: 18 September 2014 17:24 > To: Jay D Bhatt > Cc: [email protected] > Subject: Re: Resource Acquiring of same application class and priority > logic > > Hello Jay, > > > I am trying to implement murphy resource aware application for audio > > and video player. > > Great! :-) > > > I initially create resource set and add resources .Then I acquire > > resource by default on playing any file audio file or video file and > > automatically the resource will be acquired. But I have few doubt > > about the same. > > The automatic allocation of resources is not fully compatible with manual > allocation of resources. In particular, if you play audio with gstreamer and > do not allocate the resource set manually, PulseAudio (with > pulseaudio-module-murphy-ivi plugin) will allocate a default resource set for > you if media.role stream property is set to "music". If you do create a > resource set manually using the resource API, you have to set the "pid" > attribute of the resource set to match the pid of the playing application so > that PulseAudio and Murphy understand that you have a manually handled > resource set for the media player. You have to do the acquisition/releasing > of the resource set by yourself in this case. Just acquire the resource set > before you start playing and release after you finish playing. Only play > audio when you have the permission to do so from the resource engine. > > > So, if I play audio file and then I play video file the > > audio_playback resource should be used by video file. My question is > > : Is this taken care by murphy or it is to be taken care by > > implementor( since both have same application class and priorities, > > so whatever logic mute or pause needs to be implemented in the logic). > > So in other words the problem is that you want to have either an > "audio_playback" (for audio file case) or both "audio_playback" and > "video_playback" (for video file case)? You can have two resource sets > -- one for video and one for audio -- and acquire and release them according > to the file type you want to play. > > Ismo Puustinen <[email protected]> > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Disclaimer~~ > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Information contained and transmitted by this e-mail is confidential and > proprietary to IGATE and its affiliates and is intended for use only by the > recipient. If you are not the intended recipient, you are hereby notified > that any dissemination, distribution, copying or use of this e-mail is > strictly prohibited and you are requested to delete this e-mail immediately > and notify the originator or [email protected] > <mailto:[email protected]>. IGATE does not enter into any agreement with > any party by e-mail. Any views expressed by an individual do not necessarily > reflect the view of IGATE. IGATE is not responsible for the consequences of > any actions taken on the basis of information provided, through this email. > The contents of an attachment to this e-mail may contain software viruses, > which could damage your own computer system. While IGATE has taken every > reasonable precaution to minimise this risk, we cannot accept liability for > any damage which you sustain as a result of softw are viruses. You should carry out your own virus checks before opening an attachment. To know more about IGATE please visit www.igate.com <http://www.igate.com>. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Disclaimer~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Information contained and transmitted by this e-mail is confidential and proprietary to IGATE and its affiliates and is intended for use only by the recipient. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this e-mail is strictly prohibited and you are requested to delete this e-mail immediately and notify the originator or [email protected] <mailto:[email protected]>. IGATE does not enter into any agreement with any party by e-mail. Any views expressed by an individual do not necessarily reflect the view of IGATE. IGATE is not responsible for the consequences of any actions taken on the basis of information provided, through this email. The contents of an attachment to this e-mail may contain software viruses, which could damage your own computer system. While IGATE has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of softwar e viruses. You should carry out your own virus checks before opening an attachment. To know more about IGATE please visit www.igate.com <http://www.igate.com>. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _______________________________________________ IVI mailing list [email protected] https://lists.tizen.org/listinfo/ivi
