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

[Liam Girdwood <lrg@slimlogic.co.uk>]

On Tue, 2010-09-07 at 20:17 +0200, Jaroslav Kysela wrote:
> On Tue, 7 Sep 2010, Mark Brown wrote:
> 
> > On Tue, Sep 07, 2010 at 04:42:57PM +0200, Jaroslav Kysela wrote:
> >
> >> control API. I think that it might be more "easy to understand" and
> >> universal to define just sequence of commands like:
> >
> >> SectionDefaults [
> >>          exec "amixer cset name='Master Playback Switch',index=2 1,1"
> >
> > ...
> >
> >> Because "amixer cset" command will be probably most used command, we can
> >> eventually move the amixer code to alsa-lib to not create so much
> >> processes and speed-up things.
> >
> >> It means that the ucm should not track card controls, but commands for
> >> transitions.
> >
> > I don't understand the motivation here - what does this buy us?
> >
> > Looking at this from the embedded perspective I really would much rather
> > see a use case manager that understands what it's doing (rather than
> > essentially just running shell script).  This allows us to do things
> > like specify target states (rather than having to have full sequences
> > for all transitions, which is one of the things it'd be good to avoid)
> > and will allow us to take advantage of any additions to the ALSA APIs
> > for things like batching operations without changes to the per machine
> > configurations.
> >
> > Having the facility to shell out in case some non-ALSA stuff needs to be
> > done might be handy but I'd expect that for things within ALSA a tool
> > like the use case manager would understand ALSA natively.
> >
> > For embedded systems, especially those like mobile phones with extensive
> > use case requirements, the usability issues mostly come from the very
> > large numbers of controls which is at best orthogonal to shelling out to
> > amixer (or whatever) commands.
> 
> My idea is to have the most used commands working with the ALSA API 
> built directly into the ucm code to not use fork/exec so much in embedded 
> environments. 

What does this really buy us over the current (direct alsa-lib API)
code ? 

Fwiw, UCM was never intended to replace any of the alsa-utils, but to
complement them in complex audio systems (like phones).

> But I can imagine that some system configurations can use 
> this API to send events to another manager which can control another 
> parts of the system like video, input devices, network devices and so on 
> according the sound setup.

UCM is purely to abstract the audio hardware for higher level
middle-ware and applications. It's really up to the system middle-ware
and daemons here to configure/control the other subsystems in line with
the system use case.

> 
> Also, the possibility to generate the alsa-lib's configuration files at 
> run-time might be a nice feature for future. 

Fwiw, UCM is _needed_ now and I really can't emphasise this strongly
enough atm. Some embedded ODMs are even now using and shipping closed
source proprietary software for audio hardware UCM.

The UCM configuration files for embedded system will likely be very
specific to the hardware and not really suited to run time generation.
However, there is nothing stopping runtime generation with the original
file format.   

> I take UCM like a way to 
> integrate all things regarding PCM streams and mixer controls together and 
> let users / system administrators / distribution makers create the 
> abstract layers depending their requirements.
> 
> It's about flexibility.

Exactly, but there is nothing stopping flexibility with the current code
base.

Liam 
-- 
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk