All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tanu Kaskinen <tanuk@iki.fi>
To: Patrick Lai <plai@codeaurora.org>
Cc: alsa-devel <alsa-devel@alsa-project.org>,
	Mark Brown <broonie@opensource.wolfsonmicro.com>,
	Liam Girdwood <lrg@ti.com>
Subject: Re: ucm: hardware resource arbitration
Date: Wed, 12 Sep 2012 16:53:42 +0300	[thread overview]
Message-ID: <1347458022.6888.31.camel@laptop> (raw)
In-Reply-To: <504EDF0F.70809@codeaurora.org>

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

  reply	other threads:[~2012-09-12 13:54 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-11  6:49 ucm: hardware resource arbitration Patrick Lai
2012-09-12 13:53 ` Tanu Kaskinen [this message]
2012-09-12 22:51   ` Patrick Lai
2012-09-16  6:40     ` Tanu Kaskinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1347458022.6888.31.camel@laptop \
    --to=tanuk@iki.fi \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=lrg@ti.com \
    --cc=plai@codeaurora.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.