On Mon, 2014-10-27 at 07:00 +0000, Jay D Bhatt wrote:
> Hi,
> 
>  
> 
> I am working on two applications: audio player and phone.
> 
>  
> 
> I have made both applications resource aware applications. The
> Incoming call doesn’t pre-empt audio player in below case:
> 
>  
> 
> 1)     Audio Player playing audio file
> 
> 2)     Incoming call comes, while the audio is playing.
> 
> 3)     Expected behaviour should be audio should be paused and call
> ringtone and communication on phone is established. But existing
> behaviour is audio is not paused, it mixes with call ringtone and even
> when the call communication is established.
> 
>  
> 
> As per understanding both are using same audio_playback resource, so
> it should be released by audio player once acquired by phone
> application.

The default Tizen ruleset is configured so that music gets mixed with
phone calls with a 20 dB attenuation. The telephony plugin takes the
audio_playback resource as shared, so it allows mixing in streams from
lower-priority classes. That is why your application does not lose its
audio_playback resource. 

If you want to change this behaviour, the most trivial way is to
configure the telephony plugin (which tracks phone calls via ofono) to
take audio_playback in exclusive mode. You can do this by changing the
line

m:try_load_plugin('telephony')

to

m:try_load_plugin('telephony', {
       playback="audio_playback,mandatory,exclusive"
})

in /etc/murphy/murphy.lua

Change both instances of the loading attempt (there is one for when
running with ICO + system-controller and one for without at the very
end).

You can also test-drive how this would work in practice without changing
the configuration by using the resource-client test-client (form the
murphy-tests RPM package). Start it up as 

  resource-client phone driver me:audio_playback,audio_recording

then acquire the resource set by the acquire command. You should see
your player losing its resources. If you then release the resource set
using the release command, your player should get its resource set
regranted (unless you have created it with the autorelease flag set).

> 
> Below is the murphy related properties for phone:
> 
>  
> 
> murphyd[169]: I: Telephony resource-set configuration:
> 
> murphyd[169]: I:     zone: driver, class: phone, priority: 1
> 
> murphyd[169]: I:     playback: mandatory shared audio_playback

See, it is taking audio_playback as a shared resource...

>  role:s:phone
> 
> murphyd[169]: I:     recording: mandatory exclusive audio_recording
> role:s:phone
> 
>  
> 
> And below are the murphy related properties for audioplayer:
> 
>  
> 
> murphyd[169]: resource-set flags:1 priority:0 class:'player'
> zone:'driver'
> 
> murphyd[169]:    resource: name:'audio_playback' mandatory exclusive
> 
> murphyd[169]:       attribute role:'music'
> 
> murphyd[169]:       attribute pid:'<unknown>'
> 
> murphyd[169]:       attribute policy:'relaxed'
> 
>  
> 
> Is there anything wrong with the properties? Both have different
> priority and different application class, but as per murphy, call
> should pre-empt audio player. Can anybody help on this?

If you don't want to change the configuration, an ugly hack is to add
audio_recording as mandatory to the resource set of your player. Because
the telephony plugin also takes audio_recording as an exclusive
resource, there will be a resource conflict and your player (which has
lower priority) will get pre-empted.

I must emphasize that this is just a kludge not something you should
consider a solution for achieving your desired behavior. Changing the
configuration/ruleset to suit your needs is the right tool for that.
That said, you might want to give it a try anyway, just to play around a
bit with resources/murphy and see how the resource sets interact with
each other in practice.

Cheers,
  Krisztian


> 
> Thanks,
> 
> Jay
> 
>  
> 
> 
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~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
> mailad...@igate.com. 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 software viruses. You should carry out your
> own virus checks before opening an attachment. To know more about
> IGATE please visit www.igate.com.
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>  
> _______________________________________________
> IVI mailing list
> IVI@lists.tizen.org
> https://lists.tizen.org/listinfo/ivi

---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
_______________________________________________
IVI mailing list
IVI@lists.tizen.org
https://lists.tizen.org/listinfo/ivi

Reply via email to