From: David Henningsson <david.henningsson@canonical.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: alsa-devel@alsa-project.org
Subject: Re: [RFC] ALSA: usb: supply channel maps even when wChannelConfig is unspecified
Date: Mon, 04 Nov 2013 10:20:12 +0100 [thread overview]
Message-ID: <527766CC.2050609@canonical.com> (raw)
In-Reply-To: <s5hzjpkr1ai.wl%tiwai@suse.de>
On 11/04/2013 09:58 AM, Takashi Iwai wrote:
> At Fri, 1 Nov 2013 16:38:59 +0100,
> David Henningsson wrote:
>>
>> If wChannelconfig is given for some formats but not others, userspace
>> might not be able to set the channel map.
>>
>> This is RFC because I'm not sure what the best behaviour is - to guess
>> the channel map from the given number of channels (it's quite likely
>> that one channel is MONO and two channels is FL FR), or just to supply
>> UNKNOWN for all channels.
>>
>
> In the case of USB-audio, I guess this is OK to fill the guessed
> chmaps, especially for the mono channel. So I can take this patch if
> you already tested on your device.
>
>> But the complete lack of channel map for a format leads userspace to
>> believe that the format is not available at all. Or am I
>> misunderstanding how this should be used?
>
> The chmap is just an optional information, thus excluding the format
> due to the lack of chmap doesn't sound right. The lack of chmap means
> merely that the hardware doesn't give the chmap information, but the
> format itself must be available.
>
> So, in the case of PA, I'd expect it handles such a format as is of
> now, just guessing / using the pre-defined chmaps.
Ok, can you clarify this (theoretical) example:
I wanted to use the channel mapping API to distinguish between 2.1
surround and 4.0 surround.
Now assume we're connected to some device, successfully set hw params to
four output channels.
When then asking for maps through query_chmaps, it returns one chmap
only, and its value is "FL FR".
What should PA do in this situation?
1) Skip both 2.1 and 4.0 surround, after all, it supports only FL FR chmap.
2) Allow both 2.1 and 4.0 surround, since we did not get a chmap that
had the same amount of channels as we set the hwparams to.
3) Either option 1 or 2, but also complain loudly about the fact that
we set the hwparams to 4 channels but got a chmap that wasn't 4
channels, and ask ALSA developers to fix the driver.
--
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic
next prev parent reply other threads:[~2013-11-04 9:20 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-01 15:38 [RFC] ALSA: usb: supply channel maps even when wChannelConfig is unspecified David Henningsson
2013-11-04 8:58 ` Takashi Iwai
2013-11-04 9:20 ` David Henningsson [this message]
2013-11-04 9:31 ` Takashi Iwai
2013-11-04 9:47 ` David Henningsson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=527766CC.2050609@canonical.com \
--to=david.henningsson@canonical.com \
--cc=alsa-devel@alsa-project.org \
--cc=tiwai@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.