From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: [RFC] Channel mapping API Date: Tue, 21 Aug 2012 15:13:47 +0200 Message-ID: References: <50337005.7090404@canonical.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 00C77265B59 for ; Tue, 21 Aug 2012 15:13:47 +0200 (CEST) In-Reply-To: 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: David Henningsson Cc: alsa-devel@alsa-project.org List-Id: alsa-devel@alsa-project.org At Tue, 21 Aug 2012 14:06:09 +0200, Takashi Iwai wrote: > > At Tue, 21 Aug 2012 13:24:53 +0200, > David Henningsson wrote: > > > > On 08/21/2012 12:31 PM, Takashi Iwai wrote: > > > Hi, > > > > > > this is a progress report of my longstanding TODO, the channel map API > > > implementation. I'm going to cover this at Plumbers audio uconf, so > > > we can discuss details there, too. > > > > > > The channel mapping API provides a method for user-space to query, get > > > and set the channel map of a PCM stream. It's required for assigning > > > channels properly for multi-channel streams. > > > > > > > > > * KERNEL IMPLEMENTATION > > > > > > In my latest attempt, I implemented with control elements. A control > > > element is created for each PCM substream with the corresponding > > > device and substream index. Then it gives a TLV for querying maps, a > > > read op for obtaining the current map, and optionally a write op for > > > setting the map. The obvious merit by this way is that no extra > > > kernel ABI is required. > > > > > > A couple of new helper functions are provided for assigning standard > > > channel maps. Currently, HD-audio and AC97 drivers has some > > > implementation. > > > > > > > > > * ALSA-LIB IMPLEMENTATION > > > > > > The additional alsa-lib API functions look like: > > > > > > int **snd_pcm_query_chmaps(snd_pcm_t *pcm); > > > int *snd_pcm_get_chmap(snd_pcm_t *pcm); > > > int snd_pcm_set_chmap(snd_pcm_t *pcm, const int *map); > > > > > > snd_pcm_query_chmaps() returns the list of channel maps. A channel > > > map is represented by an integer array, beginning with the channel map > > > type, followed by the number of channels, and the position of each > > > channel, e.g. > > > { SND_CHMAP_FIXED, 4, SND_CHMAP_FL, SND_CHMAP_FR, SND_CHMAP_RL, SND_CHMAP_RR } > > > > > > snd_pcm_get_chmap() returns the currently assigned channel map for the > > > given PCM stream. If the PCM is before prepared, it fills UNKNOWN. > > > > > > When a driver allows user to change the channel map, user can call > > > snd_pcm_set_chmap(). For example, HDMI allows you to choose whether > > > it's 4.0 or 3.1 output. > > > > Interesting. A few thoughts here: > > > > 1) You seem to have invented new constants for different channels > > (SND_CHMAP_FL for "front left" etc). There is already a channel > > enumeration in include/mixer.h, _snd_mixer_selem_channel_id. Is there a > > reason we can't just reuse it for this purpose? > > No big reason, but a minor reason would be that UNKNOWN = -1 is > a bit impractical and the mixer id definition lacks some new > positions. And, this is for mixer, and another for PCM, so using > SND_MIXER_* doesn't sound right. > > But adjusting to follow the same values won't be a big issue. > Let's see. I updated git trees to follow this now. Takashi