From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pavel Hofman Subject: Re: Master vs. Front/Rear/LFE/... elements Date: Thu, 07 May 2009 15:12:11 +0200 Message-ID: <4A02DE2B.80909@insite.cz> References: <20090506175824.GA30355@tango.0pointer.de> <20090507100915.GB27897@sirena.org.uk> <20090507125654.GB3968@tango.0pointer.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from server.insite.cz (unknown [84.242.100.8]) by alsa0.perex.cz (Postfix) with ESMTP id 8C7B7247D5 for ; Thu, 7 May 2009 15:12:11 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by server.insite.cz (Postfix) with ESMTP id E4BB110289A8 for ; Thu, 7 May 2009 15:12:10 +0200 (CEST) Received: from server.insite.cz ([127.0.0.1]) by localhost (server.insite.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPxLukYuEGT7 for ; Thu, 7 May 2009 15:12:10 +0200 (CEST) Received: from [192.168.1.20] (sara.insite.cz [192.168.1.20]) by server.insite.cz (Postfix) with ESMTP id 59428101F97D for ; Thu, 7 May 2009 15:12:10 +0200 (CEST) In-Reply-To: <20090507125654.GB3968@tango.0pointer.de> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: alsa-devel-bounces@alsa-project.org Errors-To: alsa-devel-bounces@alsa-project.org To: alsa-devel@alsa-project.org List-Id: alsa-devel@alsa-project.org Lennart Poettering wrote: > 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 > 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.