From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: [RFC] Channel mapping API Date: Tue, 21 Aug 2012 21:29:01 +0200 Message-ID: References: <50337316.4080208@ladisch.de> <50339485.30500@canonical.com> <20120821140648.GC21557@sirena.org.uk> <503397A1.4000409@canonical.com> <20120821141759.GO7995@opensource.wolfsonmicro.com> <5033AB7A.7050609@ladisch.de> <20120821162706.GU7995@opensource.wolfsonmicro.com> <20120821171135.GA7995@opensource.wolfsonmicro.com> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx2.suse.de (cantor2.suse.de [195.135.220.15]) by alsa0.perex.cz (Postfix) with ESMTP id A4113265D65 for ; Tue, 21 Aug 2012 21:29:00 +0200 (CEST) In-Reply-To: <20120821171135.GA7995@opensource.wolfsonmicro.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: Mark Brown Cc: alsa-devel@alsa-project.org, Clemens Ladisch , David Henningsson List-Id: alsa-devel@alsa-project.org At Tue, 21 Aug 2012 18:11:35 +0100, Mark Brown wrote: > > On Tue, Aug 21, 2012 at 07:05:24PM +0200, Takashi Iwai wrote: > > Mark Brown wrote: > > > > The idea was > > > purely to punt the description of the outputs attached to the stream to > > > somewhere we already need to use to describe the outputs rather than > > > having to map the two formats together. > > > Yeah, passing more info is fine. But if it isn't compatible, it > > doesn't have to be the same controller elements as channel map. > > Or, we may put a flag in the query TLV to indicate it's not standard, > > etc... > > So, I guess a lot of my concern here is that this is in line with what > we're doing for control names and obviously that information is basic to > the point of being unhelpful for any non-trivial hardware. If we're > adding something I'd rather it were able to cope with the complicated > cases too; multi-channel audio is a big deal with embedded things but > usually not for 5.1. I think it won't be able to be implemented in a single piece anyway for such a case, but it'd be a combination of some components. As you pointed, the final mapping can be deduced with some extra routing information. But this won't be needed for normal desktop cases. So, if anything similar information (e.g. just the mapped number) would be still useful as a piece for the big picture, I'm fine to allow arbitrary values in the definition of API (again, ABI is already there, so it's really just a matter of definition). Something like the bit flag as I suggested would be easily put into. Just need to know what should be the most appropriate form... Takashi