[alsa-devel] Master vs. Front/Rear/LFE/... elements

[Pavel Hofman]

Lennart Poettering wrote:
> On Thu, 07.05.09 12:30, Takashi Iwai (tiwai at suse.de) wrote:
> 
>> At Thu, 7 May 2009 11:09:16 +0100,
>> Mark Brown wrote:
>>> On Thu, May 07, 2009 at 10:49:22AM +0200, Takashi Iwai wrote:
>>>
>>>> IMO, the best would be a total rewrite of the current mixer API, as I
>>>> mentioned some times.  Right now it's more complicated than needed,
>>>> but not powerful enough to handle exceptional cases.
>>> Indeed - for example, something that allowed audio routing to be
>>> expressed in the mixing API would be a very big win for embedded systems
>>> too.
>> Right.  But this would also require some changes in the driver side,
>> and it could be complicated.
>>
>> Actually, we had this kind of information in the time of ALSA 0.5.
>> However, it ended up with too burden to the driver code because one
>> had to write a comprehensive static graph in the driver code itself
>> (generated by hand!).  Also, some mixer elements are tightly coupled
>> with certain audio components, but some are pretty abstract and hard
>> to put into a graph.  So, we reduced that in the newer API and
>> implemented a straight array of control elements instead.
>>
>> Nevertheless, a sort of linking would be useful in addition to the
>> current form.  For example, coupling between the control element and
>> the PCM stream is missing, too.
>>
>> Alternatively, we may have an external data outside the kernel
>> driver.  In that case, the data can be expressed more flexibly
>> (XML? Oh yeah :)
> 
> That would actually work for me and I wouldn't even be that disgusted
> by this usage of XML ;-)
> 
> From the PA perspective I actually don't really need the full routing
> of the sound card exposed. I always want to focus on actual end-user
> use cases instead of exposing the full mixer capabilities. All I need
> to know is which elements are in the pipeline from my PCM streams to a
> specific output, resp. from a specific input to my PCM stream and a
> more high-level idea what those elements actually mean. i.e. all I
> need would be an API like this:
> 
> int snd_pcm_get_mixer_path(snd_pcm_t *pcm, snd_mixer_selem_id_t
> path[], unsigned n);
> 
> This would simply return an array of mixer element ids that are in the
> pipeline to the output, resp. from the input, ordered.
> 
> Then, a trivial API that allows me to identify what a mixer element's
> use is would be all I need. 
> 
> Lennart
> 

If you guys decide to go the user-space route, please consider including
an optional text description of each control element, preferrably with
localization support.


Thanks,

Pavel.