From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Jaroslav Kysela <perex@perex.cz>,
shumingf@realtek.com, broonie@kernel.org, lgirdwood@gmail.com
Cc: oder_chiou@realtek.com, jack.yu@realtek.com,
alsa-devel@alsa-project.org, lars@metafoo.de,
derek.fang@realtek.com, bard.liao@intel.com, flove@realtek.com,
pierre-louis.bossart@intel.com
Subject: Re: [PATCH v2] ASoC: rt1316: Add RT1316 SDCA vendor-specific driver
Date: Thu, 18 Feb 2021 08:49:35 -0600 [thread overview]
Message-ID: <84ce7570-b5c7-d89d-7d65-a391c3b65f93@linux.intel.com> (raw)
In-Reply-To: <350ee43a-af99-bb8e-60d3-2a0dc561cb45@perex.cz>
On 2/18/21 3:44 AM, Jaroslav Kysela wrote:
> Dne 18. 02. 21 v 10:12 shumingf@realtek.com napsal(a):
>
>> + SND_SOC_DAPM_SWITCH("DAC L", SND_SOC_NOPM, 0, 0, &rt1316_sto_dac_l),
>> + SND_SOC_DAPM_SWITCH("DAC R", SND_SOC_NOPM, 0, 0, &rt1316_sto_dac_r),
>
> Truly, I don't understand the reason to have a separate L/R switch when we can
> map this functionality to one stereo (multichannel) control.
>
> It's an issue for all ASoC drivers. We should consider to be more strict for
> the new ones.
At the same time we have to recognize that the L/R notion only makes
sense at the input to the amplifier. The amplifier may recombine
channels to deal with orientation/posture or simply select a specific
input, and drive different speakers (e.g. tweeter/woofer). Dac L and R
are often an abuse of language when the system have multi-way speakers.
Exhibit A for this is the TigerLake device with 2 RT1316 and 4 speakers.
L/R don't make sense to describe amplifier outputs and speaker position.
There's also a difficult balance to be found between exposing all the
capabilities of the device, and making integration and userspace
simpler. I2C/IS2 and SoundWire devices tend to expose more controls than
HDaudio ones, and that was driven by a desire to optimize as much as
possible. Some devices are designed with limited number of controls,
others provide hooks to tweak everything in the system by exposing
literally have thousands of controls. I don't think we should pick and
choose which controls we want to expose, that's the codec vendor's job
IMHO (or the device class definition when standard and applicable)
next prev parent reply other threads:[~2021-02-18 16:04 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-18 9:12 [PATCH v2] ASoC: rt1316: Add RT1316 SDCA vendor-specific driver shumingf
2021-02-18 9:44 ` Jaroslav Kysela
2021-02-18 14:49 ` Pierre-Louis Bossart [this message]
2021-02-20 17:55 ` Jaroslav Kysela
2021-02-22 13:35 ` Mark Brown
2021-02-22 15:48 ` Pierre-Louis Bossart
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=84ce7570-b5c7-d89d-7d65-a391c3b65f93@linux.intel.com \
--to=pierre-louis.bossart@linux.intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=bard.liao@intel.com \
--cc=broonie@kernel.org \
--cc=derek.fang@realtek.com \
--cc=flove@realtek.com \
--cc=jack.yu@realtek.com \
--cc=lars@metafoo.de \
--cc=lgirdwood@gmail.com \
--cc=oder_chiou@realtek.com \
--cc=perex@perex.cz \
--cc=pierre-louis.bossart@intel.com \
--cc=shumingf@realtek.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).