From: Mauro Carvalho Chehab <mchehab@s-opensource.com>
To: Marcel Hasler <mahasler@gmail.com>
Cc: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
linux-media <linux-media@vger.kernel.org>
Subject: Re: [PATCH v3 3/4] stk1160: Add module param for setting the record gain.
Date: Tue, 6 Dec 2016 10:56:26 -0200 [thread overview]
Message-ID: <20161206105626.7de242a3@vento.lan> (raw)
In-Reply-To: <CAOJOY2M6QANNysnZ_C9G+fFg=a=wYQXGDr49LCYGE7KrbwkE4A@mail.gmail.com>
Em Mon, 5 Dec 2016 22:06:59 +0100
Marcel Hasler <mahasler@gmail.com> escreveu:
> Hello
>
> 2016-12-05 16:38 GMT+01:00 Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>:
> > On 5 December 2016 at 09:12, Mauro Carvalho Chehab
> > <mchehab@s-opensource.com> wrote:
> >> Em Sun, 4 Dec 2016 15:25:25 -0300
> >> Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> escreveu:
> >>
> >>> On 4 December 2016 at 10:01, Marcel Hasler <mahasler@gmail.com> wrote:
> >>> > Hello
> >>> >
> >>> > 2016-12-03 21:46 GMT+01:00 Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>:
> >>> >> On 2 December 2016 at 08:05, Mauro Carvalho Chehab
> >>> >> <mchehab@s-opensource.com> wrote:
> >>> >>> Em Sun, 27 Nov 2016 12:11:48 +0100
> >>> >>> Marcel Hasler <mahasler@gmail.com> escreveu:
> >>> >>>
> >>> >>>> Allow setting a custom record gain for the internal AC97 codec (if available). This can be
> >>> >>>> a value between 0 and 15, 8 is the default and should be suitable for most users. The Windows
> >>> >>>> driver also sets this to 8 without any possibility for changing it.
> >>> >>>
> >>> >>> The problem of removing the mixer is that you need this kind of
> >>> >>> crap to setup the volumes on a non-standard way.
> >>> >>>
> >>> >>
> >>> >> Right, that's a good point.
> >>> >>
> >>> >>> NACK.
> >>> >>>
> >>> >>> Instead, keep the alsa mixer. The way other drivers do (for example,
> >>> >>> em28xx) is that they configure the mixer when an input is selected,
> >>> >>> increasing the volume of the active audio channel to 100% and muting
> >>> >>> the other audio channels. Yet, as the alsa mixer is exported, users
> >>> >>> can change the mixer settings in runtime using some alsa (or pa)
> >>> >>> mixer application.
> >>> >>>
> >>> >>
> >>> >> Yeah, the AC97 mixer we are currently leveraging
> >>> >> exposes many controls that have no meaning in this device,
> >>> >> so removing that still looks like an improvement.
> >>> >>
> >>> >> I guess the proper way is creating our own mixer
> >>> >> (not using snd_ac97_mixer) exposing only the record
> >>> >> gain knob.
> >>> >>
> >>> >> Marcel, what do you think?
> >>> >> --
> >>> >> Ezequiel García, VanguardiaSur
> >>> >> www.vanguardiasur.com.ar
> >>> >
> >>> > As I have written before, the recording gain isn't actually meant to
> >>> > be changed by the user. In the official Windows driver this value is
> >>> > hard-coded to 8 and cannot be changed in any way. And there really is
> >>> > no good reason why anyone should need to mess with it in the first
> >>> > place. The default value will give the best results in pretty much all
> >>> > cases and produces approximately the same volume as the internal 8-bit
> >>> > ADC whose gain cannot be changed at all, not even by a driver.
> >>> >
> >>> > I had considered writing a mixer but chose not to. If the gain setting
> >>> > is openly exposed to mixer applications, how do you tell the users
> >>> > that the value set by the driver already is the optimal and
> >>> > recommended value and that they shouldn't mess with the controls
> >>> > unless they really have to? By having a module parameter, this setting
> >>> > is practically hidden from the normal user but still is available to
> >>> > power-users if they think they really need it. In the end it's really
> >>> > just a compromise between hiding it completely and exposing it openly.
> >>> > Also, this way the driver guarantees reproducible results, since
> >>> > there's no need to remember the positions of any volume sliders.
> >>> >
> >>>
> >>> Hm, right. I've never changed the record gain, and it's true that it
> >>> doens't really improve the volume. So, I would be OK with having
> >>> a module parameter.
> >>>
> >>> On the other side, we are exposing it currently, through the "Capture"
> >>> mixer control:
> >>>
> >>> Simple mixer control 'Capture',0
> >>> Capabilities: cvolume cswitch cswitch-joined
> >>> Capture channels: Front Left - Front Right
> >>> Limits: Capture 0 - 15
> >>> Front Left: Capture 10 [67%] [15.00dB] [on]
> >>> Front Right: Capture 8 [53%] [12.00dB] [on]
> >>>
> >>> So, it would be user-friendly to keep the user interface and continue
> >>> to expose the same knob - even if the default is the optimal, etc.
> >>>
> >>> To be completely honest, I don't think any user is really relying
> >>> on any REC_GAIN / Capture setting, and I'm completely OK
> >>> with having a mixer control or a module parameter. It doesn't matter.
> >>
> >> If you're positive that *all* stk1160 use the ac97 mixer the
> >> same way, and that there's no sense on having a mixer for it,
> >> then it would be ok to remove it.
> >>
> >
> > Let's remove it then!
> >
> >> In such case, then why you need a modprobe parameter to allow
> >> setting the record level? If this mixer entry is not used,
> >> just set it to zero and be happy with that.
> >>
> >
> > Let's remove the module param too, then.
>
> I'm okay with that.
>
> >
> > Thanks,
> > --
> > Ezequiel García, VanguardiaSur
> > www.vanguardiasur.com.ar
>
> I'm willing to prepare one final patchset, provided we can agree on
> and resolve all issues beforehand.
>
> So far the changes would be to remove the module param and to poll
> STK1160_AC97CTL_0 instead of using a fixed delay. It's probably better
> to also poll it before writing, although that never caused problems.
Sounds ok. My experience with AC97 on em28xx is that, as new devices
were added, the delay needed for AC97 varied on some of those new
devices. That's why checking if AC97 is ready before writing was
added to its code.
>
> I'll post some code for review before actually submitting patches.
> Mauro, is there anything else that you think should be changed? If so,
> please tell me now. Thanks.
>
> Best regards
> Marcel
Thanks,
Mauro
next prev parent reply other threads:[~2016-12-06 12:56 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-27 11:07 [PATCH v3 0/4] stk1160: Let the driver setup the device's internal AC97 codec Marcel Hasler
2016-11-27 11:09 ` [PATCH v3 1/4] stk1160: Remove stk1160-mixer and setup internal AC97 codec automatically Marcel Hasler
2016-11-27 11:11 ` [PATCH v3 2/4] stk1160: Check whether to use AC97 codec Marcel Hasler
2016-11-27 11:11 ` [PATCH v3 3/4] stk1160: Add module param for setting the record gain Marcel Hasler
2016-12-02 11:05 ` Mauro Carvalho Chehab
2016-12-03 20:46 ` Ezequiel Garcia
2016-12-04 13:01 ` Marcel Hasler
2016-12-04 18:25 ` Ezequiel Garcia
2016-12-05 12:12 ` Mauro Carvalho Chehab
2016-12-05 15:38 ` Ezequiel Garcia
2016-12-05 21:06 ` Marcel Hasler
2016-12-05 21:18 ` Marcel Hasler
2016-12-05 22:35 ` Ezequiel Garcia
2016-12-05 22:34 ` Ezequiel Garcia
2016-12-06 12:56 ` Mauro Carvalho Chehab [this message]
2016-12-11 12:07 ` Marcel Hasler
2016-12-11 12:20 ` mahasler
2016-12-12 11:21 ` Mauro Carvalho Chehab
2016-12-12 11:28 ` Marcel Hasler
2016-11-27 11:12 ` [PATCH v3 4/4] stk1160: Give the chip some time to retrieve data from AC97 codec Marcel Hasler
2016-12-02 11:09 ` Mauro Carvalho Chehab
2016-12-03 20:41 ` Ezequiel Garcia
2016-12-01 19:49 ` [PATCH v3 0/4] stk1160: Let the driver setup the device's internal " Ezequiel Garcia
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=20161206105626.7de242a3@vento.lan \
--to=mchehab@s-opensource.com \
--cc=ezequiel@vanguardiasur.com.ar \
--cc=linux-media@vger.kernel.org \
--cc=mahasler@gmail.com \
--cc=mchehab@kernel.org \
/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).