View source for MixerAPIalsalib

==Abstract Mixer API in alsa-lib==

The basic idea is to provide the "expected" abstract mapping from the user and application view to the control elements which are directly mapped to the hardware.

[JaroslavKysela] I have had an idea to use a light version of an lisp interpreter (or compiler) to describe the expressions between the abstract and direct (hardware) controls. It seems that the main problem is how the lisp should be integrated into alsa-lib. The API for applications should be definitely in plain C. As Takashi noted, it might be that C -> lisp -> C path might be inefficient. In case, when we will have someday a lisp compiler which translate the lisp code to C, then the efficiency will be much better. Of course, there must be always a way to replace the lisp code with C code for the best optimization.

[JaroslavKysela] Note that lisp might replace the configuration files as well, because the current configuration language have serious gaps (is static) and the runtime extensions (function) are really ugly hack.

[JaroslavKysela] Unfortunately, to take full power of the lisp as configuration / mapping description language, we must map all C functions / definitions which alsa-lib provides into the lisp space. I am preparing a small tool which parses C header files and translates functions to lisp interpreter automagically.

[JamesCourtierDutton] I think we should first try to simplify the mixer api so that the mixer application is much simplier. How about a simple find first, find next API. The mixer app would request

 Input values:
 handle = handle returned when one did open_mixer();
 mode is one of PLAYBACK,CAPTURE,GLOBAL or 1,2,3;
 Return value:
 control_id is the return value.
 Function:
 find_first_control(handle, mode, *control_id)

 Input values:
  handle = handle returned when one did open_mixer();
  mode is one of PLAYBACK,CAPTURE,GLOBAL,VISIBILITY; (bit mask)
  control_id is last returned control_id
 Return value:
  control_id.
 Function:
  find_next_control(handle, mode, *control_id)

The mixer app could then iterate over all the controls and build up a list of control_ids.
This API could then be used to return e.g. only Visible playback controls.
The mixer app would then make function calls to retrieve details about each control.
Each control would have
Presence/Absence:
Mute, Gain control, On/Off Switch, ENUM.
The max amount of channels per control would be 2 for stereo.

We could then add plugins in alsa-lib that could add or remove controls from the list, with the plugins having commonly used features. E.g. Implement a "Master" playback control if the hardware does not have it. One could also dynamically add or remove controls.
----
[https://bugtrack.alsa-project.org/wiki/wikka.php?wakka=MixerAPIalsalib] by [[User:Perex]] [[2005-03]]  [[User:JamesCourtierDutton]] [[2006-10]]

[[Category:Development]] [[Category:MigratedFromDev]]