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

[Jaroslav Kysela <perex@perex.cz>]

On Wed, 22 Sep 2010, Mark Brown wrote:

> On Wed, Sep 22, 2010 at 04:06:56PM +0200, Jaroslav Kysela wrote:
>> On Wed, 22 Sep 2010, Mark Brown wrote:
>
>>> This is what the snd_use_case_*_pcm() functions are all about -
>>> identifying which of the many available streams should be used for a
>>> given output stream.  With modern mobile audio architectures the ability
>>> to route different kind of audio to different PCM streams is essential.
>
>> But it's not possible to guess if streams are independant from the
>> PCM device name. Some hardware has restrictions or driver can offer
>> more PCM devices for one hardware (for example stereo only devices
>> and multichannel devices sharing same hardware portion).
>
> That sounds like an annotation for...
>
>>> Now, it's true that it doesn't explicitly support grouping multiple PCMs
>>> together into a single use case which is probably a good extension to
>>> think about - perhaps returning arrays would cover it, though to be
>>> honest I'm not sure how often that'd get used (and I'd expect apps to
>>> fail to cope).
>
>> Maybe a simple extension to the current API might cover also this
>> issue: Add a third state for devices and modifiers - "blocked". This
>> state will be active when hardware has inter-device/modifier
>> contraints or when another application uses hardware in the blocking
>> way.
>
> ...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.

>>>> The question is how we can make much flexible the passing of these values
>>>> from the configuration files. I think that we may use just a direct way
>>>> between the "identifier" from the snd_use_case_get/set function and the
>>>> configuration files, having syntax something like:
>
>>> There's some scaling issues that need to be dealt with - for example, if
>>> you're asking for the controls for an EQ you likely want to be able to
>>> get an array back with the per-band gains and possibly trimming options
>>> for the bands since there's quite a bit of range in the control offered
>>> by EQs.  This means we will need to be able to return a variably sized
>>> set of controls.
>>
>> Sure, but you can describe this array in a string with some delimiters.
>
> That's not going to be terribly pleasant as an API, though - I'd expect
> the library to have demangled the data before applications are expected
> to work with it.  Otherwise you end up with lots of people implementing
> the same parsing code.

See bellow.

>> I just finished the implementation for all functions in my GIT tree
>> (except card listing). Also, the "Value {}" section is implemented
>> as I proposed - it means that users can pass any read-only values to
>> the API user.
>>
>> The code is not tested, I need to write a simple command line tool
>> for testing the API and also move the control/mixer ID and value
>> handling code from the alsa-utils/amixer utility to alsa-lib.
>
>> So, please, check the use-case.h again:
>
>> http://git.alsa-project.org/?p=alsa-lib.git;a=blob;f=include/use-case.h;h=fdbcaca04c032b22de41cce2d42ab5b84edd37f4;hb=404cd090b279b329c86514984dc74439dedf2e90
>
> 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).

> - For standard string identifiers it'd be nice to provide definitions
>   to provide compile time checking for typos - if we just use strings
>   then they'll only be noticed at runtime, if there's standard defines
>   the build will fail if people use them with typos.

It's a cosmetic issue - I think that I leave this change to someone other.

> - As I said above I don't like the idea of returning just a string for
>   _get() - if the string needs any sort of parsing to be intelligable
>   we shouldn't be forcing users to do all that.
>
> In general I'm nervous about the usability and robustness here; there's
> an awful lot of stuff getting passed around as strings which may or may
> not need parsing.  This is much more of a concern for me on the output
> side than on the input side since it pushes complexity onto client code
> without any safety features at all and causes clients to have to
> implement very similar code to understand the more complex strings.
>
> What might work here would be to use this as a core API for advanced
> users then layer on more specific APIs which make stronger guarantees
> about what comes back (eg, guaranteeing to return only a single control
> name).  We could perhaps merge something like what you've got here and
> then add such features incrementally.

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 :-)

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.

 					Jaroslav

-----
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.