ucm: hardware resource arbitration

ucm: hardware resource arbitration

[Patrick Lai]

Hi,

I have two use cases which can acquire same CODEC path but they cannot
run concurrently through mixing. When such scenario does arise,
arbitration is required based on priority of use cases. On the other
hand, same use cases on different platform may use different CODEC
paths so arbitration is not required. In order to decide whether
arbitration is required, I think the best place to do so is in UCM. I
looked at existing UCM APIs but I do not believe existing APIs have
concept of arbitration built in. If I am wrong, how can I handle
arbitration with existing UCM APIs. If I am correct, is there anyone
looking to expand UCM APIs for similar scenario?

Thanks
Patrick
-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: ucm: hardware resource arbitration

[Tanu Kaskinen]

On Mon, 2012-09-10 at 23:49 -0700, Patrick Lai wrote:
> Hi,
> 
> I have two use cases which can acquire same CODEC path but they cannot
> run concurrently through mixing. When such scenario does arise,
> arbitration is required based on priority of use cases. On the other
> hand, same use cases on different platform may use different CODEC
> paths so arbitration is not required. In order to decide whether
> arbitration is required, I think the best place to do so is in UCM. I
> looked at existing UCM APIs but I do not believe existing APIs have
> concept of arbitration built in. If I am wrong, how can I handle
> arbitration with existing UCM APIs. If I am correct, is there anyone
> looking to expand UCM APIs for similar scenario?

In my opinion routing priorities don't belong in the UCM configuration.
UI designers will want to dictate the routing policy (i.e. what device
to prefer in which use case). The same hardware may end up being used in
different products, and the UI designers for those different products
may not all want the same policy. Therefore, I don't want UCM
configurations to include any routing policy. The policy configuration
belongs to some component that sits above alsa and UCM.

-- 
Tanu

Re: ucm: hardware resource arbitration

[Patrick Lai]

On 9/12/2012 6:53 AM, Tanu Kaskinen wrote:
> On Mon, 2012-09-10 at 23:49 -0700, Patrick Lai wrote:
>> Hi,
>>
>> I have two use cases which can acquire same CODEC path but they cannot
>> run concurrently through mixing. When such scenario does arise,
>> arbitration is required based on priority of use cases. On the other
>> hand, same use cases on different platform may use different CODEC
>> paths so arbitration is not required. In order to decide whether
>> arbitration is required, I think the best place to do so is in UCM. I
>> looked at existing UCM APIs but I do not believe existing APIs have
>> concept of arbitration built in. If I am wrong, how can I handle
>> arbitration with existing UCM APIs. If I am correct, is there anyone
>> looking to expand UCM APIs for similar scenario?
>
> In my opinion routing priorities don't belong in the UCM configuration.
> UI designers will want to dictate the routing policy (i.e. what device
> to prefer in which use case).

Thanks for your feedback. Actually, I am not looking at routing policy 
in term of preferred device for a given use case. I agree that
something above alsa/ucm should decide. My problem is two use cases
cannot co-exist on certain platforms but not on the others. Two use 
cases are coming from two SW entities which are not aware of each other 
but they all talk to UCM for hardware configuration. Each SW entity 
decides its own use case and preferred device. Please correct me if I am 
wrong. UCM is designed to abstract hardware configuration detail. So, it 
seems appropriate to me that UCM can  contain information about the use 
cases a given platform can support/not support concurrently. Since 
UCM(assuming it's singleton) is the entity that has visibility to all 
use cases exercised by all SW entities, It makes sense to me to have UCM 
notify clients if its use case is to be preempted. Even if we want to 
create a resource manager on top of UCM for two SW entities to 
communicate, does UCM already have API allowing client to know its use 
case is a go or no go?

Thanks
Patrick

The same hardware may end up being used in
> different products, and the UI designers for those different products
> may not all want the same policy.  Therefore, I don't want UCM
> configurations to include any routing policy. The policy configuration
> belongs to some component that sits above alsa and UCM.
>

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: ucm: hardware resource arbitration

[Tanu Kaskinen]

On Wed, 2012-09-12 at 15:51 -0700, Patrick Lai wrote:
> On 9/12/2012 6:53 AM, Tanu Kaskinen wrote:
> > In my opinion routing priorities don't belong in the UCM configuration.
> > UI designers will want to dictate the routing policy (i.e. what device
> > to prefer in which use case).
> 
> Thanks for your feedback. Actually, I am not looking at routing policy 
> in term of preferred device for a given use case. I agree that
> something above alsa/ucm should decide. My problem is two use cases
> cannot co-exist on certain platforms but not on the others. Two use 
> cases are coming from two SW entities which are not aware of each other 
> but they all talk to UCM for hardware configuration. Each SW entity 
> decides its own use case and preferred device. Please correct me if I am 
> wrong. UCM is designed to abstract hardware configuration detail. So, it 
> seems appropriate to me that UCM can  contain information about the use 
> cases a given platform can support/not support concurrently. Since 
> UCM(assuming it's singleton) is the entity that has visibility to all 
> use cases exercised by all SW entities, It makes sense to me to have UCM 
> notify clients if its use case is to be preempted. Even if we want to 
> create a resource manager on top of UCM for two SW entities to 
> communicate, does UCM already have API allowing client to know its use 
> case is a go or no go?

It sounds like you think UCM is a daemon, to which clients connect.
AFAIK, UCM is only a library. There are no "UCM clients", only
applications that read the UCM configuration files and activate things
by using the library. While it probably wouldn't be impossible to have a
notification mechanism even without a central daemon, I don't think that
such mechanism currently exists, nor do I think that such mechanism is
needed. If a system has multiple audio applications that may run
simultaneously, I think there should be a "resource manager" application
between UCM and the applications.

Regarding the problem of "two use cases [can] co-exist on certain
platforms but not on the others": I think this should be solvable by
using the ConflictingDevice list inside SectionDevice. In your example
you have two applications that can or can not use the hardware at the
same time, depending on the platform. The applications should use the
resource manager, and it's then up to the resource manager to decide
which application can use the hardware. The resource manager needs to
somehow know what device the application needs (maybe this information
comes directly from the application), and based on the ConflictingDevice
information in UCM and some priority configuration it can do the
decision.

-- 
Tanu