From: Mark Brown <broonie@kernel.org>
To: Dan Murphy <dmurphy@ti.com>
Cc: linux-kernel@vger.kernel.org, alsa-devel@alsa-project.org,
tiwai@suse.com, lgirdwood@gmail.com
Subject: Re: [PATCH] ASoC: tas2562: Add support for digital volume control
Date: Thu, 20 Feb 2020 19:40:48 +0000 [thread overview]
Message-ID: <20200220194048.GI3926@sirena.org.uk> (raw)
In-Reply-To: <6f3ff810-5e75-cb33-10d6-198a7c5cd202@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1637 bytes --]
On Thu, Feb 20, 2020 at 01:22:34PM -0600, Dan Murphy wrote:
> On 2/20/20 1:18 PM, Mark Brown wrote:
> > decisions causing changes in the driver. The system may have an
> > external amplifier they prefer to use for hardware volume control, may
> > prefer to do entirely soft volume control in their sound server or
> > something like that.
> But this is an amplifier. Not sure why the system designer would design
> cascading amplifiers.
> And if that was the case wouldn't you want the output to be low so you don't
> overdrive the ext amplifier front end?
The point is that we don't know what people are doing and should try to
keep the kernel out of policy decisions unless there's something that's
clearly just unconditionaly right for all systems. It's a lot easier to
just have a clear rule that we defer to the wisdom of the silicon vendor
than try to get into defaults, and it's a lot easier to just do this as
consistently as we can rather than debating individual configuration
changes.
> I was considering safety in that the device is on at full blast (not sure
> why the HW is defaulted that way but it is).
I bet there's been issues with people turning things on and not
realising they need register writes to hear anything, and the volume
control here is a bit complex as well.
> But if volume is adjusted prior to playback then this is not an issue. But
> if volume is not adjusted then it plays full blast.
Wouldn't be the first time. See all the dual purpose headphone/line
outputs that people build, sensible defaults for headphones and line
outputs are rather different.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Mark Brown <broonie@kernel.org>
To: Dan Murphy <dmurphy@ti.com>
Cc: lgirdwood@gmail.com, perex@perex.cz, tiwai@suse.com,
alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ASoC: tas2562: Add support for digital volume control
Date: Thu, 20 Feb 2020 19:40:48 +0000 [thread overview]
Message-ID: <20200220194048.GI3926@sirena.org.uk> (raw)
In-Reply-To: <6f3ff810-5e75-cb33-10d6-198a7c5cd202@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1637 bytes --]
On Thu, Feb 20, 2020 at 01:22:34PM -0600, Dan Murphy wrote:
> On 2/20/20 1:18 PM, Mark Brown wrote:
> > decisions causing changes in the driver. The system may have an
> > external amplifier they prefer to use for hardware volume control, may
> > prefer to do entirely soft volume control in their sound server or
> > something like that.
> But this is an amplifier. Not sure why the system designer would design
> cascading amplifiers.
> And if that was the case wouldn't you want the output to be low so you don't
> overdrive the ext amplifier front end?
The point is that we don't know what people are doing and should try to
keep the kernel out of policy decisions unless there's something that's
clearly just unconditionaly right for all systems. It's a lot easier to
just have a clear rule that we defer to the wisdom of the silicon vendor
than try to get into defaults, and it's a lot easier to just do this as
consistently as we can rather than debating individual configuration
changes.
> I was considering safety in that the device is on at full blast (not sure
> why the HW is defaulted that way but it is).
I bet there's been issues with people turning things on and not
realising they need register writes to hear anything, and the volume
control here is a bit complex as well.
> But if volume is adjusted prior to playback then this is not an issue. But
> if volume is not adjusted then it plays full blast.
Wouldn't be the first time. See all the dual purpose headphone/line
outputs that people build, sensible defaults for headphones and line
outputs are rather different.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2020-02-20 19:41 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-20 17:27 [PATCH] ASoC: tas2562: Add support for digital volume control Dan Murphy
2020-02-20 17:27 ` Dan Murphy
2020-02-20 18:45 ` Mark Brown
2020-02-20 18:45 ` Mark Brown
2020-02-20 18:46 ` Dan Murphy
2020-02-20 18:46 ` Dan Murphy
2020-02-20 19:18 ` Mark Brown
2020-02-20 19:18 ` Mark Brown
2020-02-20 19:22 ` Dan Murphy
2020-02-20 19:22 ` Dan Murphy
2020-02-20 19:40 ` Mark Brown [this message]
2020-02-20 19:40 ` Mark Brown
2020-02-20 19:52 ` Dan Murphy
2020-02-20 19:52 ` Dan Murphy
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=20200220194048.GI3926@sirena.org.uk \
--to=broonie@kernel.org \
--cc=alsa-devel@alsa-project.org \
--cc=dmurphy@ti.com \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tiwai@suse.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 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.