Hello,
Quoting Tanu Kaskinen tanu.kaski...@digia.com:
On Fri, 2011-10-14 at 15:27 +0300, Janos Kovacs wrote:
The policy decision point would send profile changes for the detected
cards (needed to route between BT A2DP and SCO for instance) as well
as it would send for each media role a
On Fri, Oct 14, 2011 at 03:27:58PM +0300, Janos Kovacs wrote:
So the idea is to use a modified device manager, David's jack
detection (with the port support for cards) and a stripped version of
Margarita's UCM patches.
I think this sounds like an excellent approach and it's fantastic that
Hi,
On Mon, Oct 17, 2011 at 1:35 PM, Mark Brown broo...@sirena.org.uk wrote:
On Fri, Oct 14, 2011 at 03:27:58PM +0300, Janos Kovacs wrote:
So the idea is to use a modified device manager, David's jack
detection (with the port support for cards) and a stripped version of
Margarita's UCM
On Mon, Oct 17, 2011 at 02:31:42PM +0300, Janos Kovacs wrote:
The first attempt is to map UCM verbs directly to alsa card profiles with the
combination with combination of certain UCM modifiers. We would have
profiles like HiFi: Play Music, HiFi Low Power: Play Music + Capture
Music,
Voice
Can we make such problem simple enough to only use profile to handle policy?
We can assume:
1. All needed profile are defined by ucm verb.
2. All sinks and sources in certain profile are defined by ucm devices.
3. Each profile provide several sinks and sources, if pa client don't
specify the
Hi,
I am one of the authors of the MeeGo policy system and currently
trying to do something similar @Intel. The original MeeGo policy
system was used in Nokia products (in N900 and in the currently
shipping N9).
In MeeGo we had a policy decision daemon that communicated its
routing, corking and
From the discussions it seems that many other people tries to solve
the same problem. We, who made the MeeGo policy framework, concluded
that we need to either upstream our stuff or use/adopt the work that
is in progress.
This is excellent news!
The policy decision point would send profile
