[alsa-devel] [PATCH 0/3] alsa-lib: UCM - Use Case Manager

[Mark Brown]

On Wed, Sep 22, 2010 at 08:05:12PM +0200, Jaroslav Kysela wrote:
> On Wed, 22 Sep 2010, Mark Brown wrote:

> >...this, though I think the blocking concept is most likely a higher
> >level one than UCM since there's a lot of of overlap between this and
> >policy decisons about which outputs are active.  It might be easier to
> >implement blocking by setting up the use case with a /dev/null stream
> >instead of a real one so applications don't need to cope, though
> >obviously some things will want to know if their audio is being
> >blackholed.

> If the blocking state can be set only from the ucm code (not from an
> application), there is no policy. It's just a reflection about
> actual hardware state. Yours and other comments persuaded me that we
> should not apply any policy in the ucm level.

OK, I think we agree here - my suggestion for using a /dev/null stream
is just an example of something the policy level could configure in the
UCM rather than UCM functionality.

> >Random points since there's no patch to quote:

> >- For the list of known identifiers would it not make sense to just say
> >  that standard ALSA control names are used for things like Capture
> >  Volume?  Just say something like "Use standard ALSA control names or
> >  one of the following additional things with an optional /modifier"

> I don't have any trouble to use the usuall control naming. These
> rules must be documented somewhere, otherwise they might be useless.
> I made this information completely optional and the names are not
> fixed (my code does not look to these values at all).

Right, broadly agree but think we should be providing guidance to users
otherwise the API might be overwhelming - look at the issues we have
with selecting appropriate control names with the current APIs.

> Basically, it's my idea. The major thing for ucm is the verb /
> device / modifier / transition handling and device listing. All
> other optional data might have many usages and it depends on the
> final purpose. So call
> strings like data containers. We can even carry XML or so if necessary :-)

I'm all for having the ability to annoate the use cases with other data
but I do feel that this should be within a much more structured framework
than is present here.  However...

> Also, I plan to add to alsa-lib all parsers for the control ID,
> control value stuff, but to the right API - the control API
> (snd_ctl_*). So there is no requirement to implement these parsers
> in applications. The parsers will return standard structures like
> 'snd_ctl_elem_id_t' or so.

...this is pretty much exactly what I was suggesting with layering on
higher level APIs which provide more useful formats to users.  I'm
therefore not sure if this would actually be resolved or not.  If we're
going to have these more packaged APIs then it would probably be good to
steer people away from the UCM API itself through a combination of
documentation and API naming - make it clear that this is for advanced
users and that for basic usage you're supposed to go via the simpler
APIs.  

Does that sound like a good plan to you?

Having looked at the implementation briefly I also note that you've
kept the procedural specification of the control settings in your
configuration file format.  As I outlined previously I do have serious
concerns about this as a model for users to work with (orthogonally to
the actual implementation which must come down to a procedure at present
due to the ALSA API, something I hope to provide features to avoid in
the future).

If we make everything procedural now it will become much harder to back
out of it later, and I would hope that one of the things that use case
management can do is ensure that users only need to specify their goal
states and don't need to deal with the mechanics of how to achieve them
except in exceptional circumstances.