Re: Master vs. Front/Rear/LFE/... elements

[Lennart Poettering <mznyfn@0pointer.de>]

On Thu, 07.05.09 12:30, Takashi Iwai (tiwai@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

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4