[Hardy LPIA LUM]: RealTek hda-intel volume remapping for non-linear volume scales

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

[Hardy LPIA LUM]: RealTek hda-intel volume remapping for non-linear volume scales

Colin Ian King-2
LP#249233 - sound volume too low.

for Hardy LPIA LUM.

The attached patch fixes a hardware volume scaling issue on a variety of
Realtek chips found on Atom based netbooks. The main issue is that
setting the volume at low levels is very low and does not scale
linearly. Also, at high volume levels one can get distortion. Hence
there is a requirement to keep the volume levels between a defined
minimum and maximum and also try and scale the provided volume levels to
produce a perceived linear scaling response.

One can select linear or parabolic volume remapping to scale (remap) a
volume level to physical volume level between a desired minimum
and maximum range. This allows adjustment if the volume is not audible
at low settings or distorts if set too high.

Linear mapping scales the volume linearly between a given low and high.

Parabolic mapping scales the volume between a given low and high
so that low volume levels are scaled more favourably (using an inverse
squared parabolic function) than high volume ranges to overcome
non-linear volume scaling found on Realtek model cw020 hardware.

The default is no mapping whatsoever.

Attached: The patch.

--
Colin King   <[hidden email]>
"Me transmitte sursum, caledoni"
       

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team

0001-UBUNTU-SAUCE-hda-intel-volume-remapping-for-non-li.patch (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Hardy LPIA LUM]: RealTek hda-intel volume remapping for non-linear volume scales

Tim Gardner-2
Colin Ian King wrote:

> LP#249233 - sound volume too low.
>
> for Hardy LPIA LUM.
>
> The attached patch fixes a hardware volume scaling issue on a variety of
> Realtek chips found on Atom based netbooks. The main issue is that
> setting the volume at low levels is very low and does not scale
> linearly. Also, at high volume levels one can get distortion. Hence
> there is a requirement to keep the volume levels between a defined
> minimum and maximum and also try and scale the provided volume levels to
> produce a perceived linear scaling response.
>
> One can select linear or parabolic volume remapping to scale (remap) a
> volume level to physical volume level between a desired minimum
> and maximum range. This allows adjustment if the volume is not audible
> at low settings or distorts if set too high.
>
> Linear mapping scales the volume linearly between a given low and high.
>
> Parabolic mapping scales the volume between a given low and high
> so that low volume levels are scaled more favourably (using an inverse
> squared parabolic function) than high volume ranges to overcome
> non-linear volume scaling found on Realtek model cw020 hardware.
>
> The default is no mapping whatsoever.
>
> Attached: The patch.
>
>

Is this really doing what you expect?

 static int slave_get_val(struct link_slave *slave,
                         struct snd_ctl_elem_value *ucontrol)
 {
@@ -305,8 +360,15 @@ static int master_put(struct snd_kcontrol *kcontrol,
                master->val = old_val;
                uval->id = slave->slave.id;
                slave_get_val(slave, uval);
-               master->val = ucontrol->value.integer.value[0];
+
+               /* Put to slaves a remapped volume */
+               master->val = vol_remap(master->info.min_val,
+                                       master->info.max_val,
+                                       ucontrol->value.integer.value[0]);
                slave_put_val(slave, uval);
+               /* And actually save the original unremapped volume
+                  for master_get() */
+               master->val = ucontrol->value.integer.value[0];
        }
        kfree(uval);
        return 1;

I looks like master-val is simply set twice (unless there are side
effects happening in slave_put_val()).

rtg

--
Tim Gardner [hidden email]

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

Re: [Hardy LPIA LUM]: RealTek hda-intel volume remapping for non-linear volume scales

Stefan Bader-2
Tim Gardner wrote:

> Colin Ian King wrote:
>> LP#249233 - sound volume too low.
>>
>> for Hardy LPIA LUM.
>>
>> The attached patch fixes a hardware volume scaling issue on a variety of
>> Realtek chips found on Atom based netbooks. The main issue is that
>> setting the volume at low levels is very low and does not scale
>> linearly. Also, at high volume levels one can get distortion. Hence
>> there is a requirement to keep the volume levels between a defined
>> minimum and maximum and also try and scale the provided volume levels to
>> produce a perceived linear scaling response.
>>
>> One can select linear or parabolic volume remapping to scale (remap) a
>> volume level to physical volume level between a desired minimum
>> and maximum range. This allows adjustment if the volume is not audible
>> at low settings or distorts if set too high.
>>
>> Linear mapping scales the volume linearly between a given low and high.
>>
>> Parabolic mapping scales the volume between a given low and high
>> so that low volume levels are scaled more favourably (using an inverse
>> squared parabolic function) than high volume ranges to overcome
>> non-linear volume scaling found on Realtek model cw020 hardware.
>>
>> The default is no mapping whatsoever.
>>
>> Attached: The patch.
>>
>>
>
> Is this really doing what you expect?
>
>  static int slave_get_val(struct link_slave *slave,
>                          struct snd_ctl_elem_value *ucontrol)
>  {
> @@ -305,8 +360,15 @@ static int master_put(struct snd_kcontrol *kcontrol,
>                 master->val = old_val;
>                 uval->id = slave->slave.id;
>                 slave_get_val(slave, uval);
> -               master->val = ucontrol->value.integer.value[0];
> +
> +               /* Put to slaves a remapped volume */
> +               master->val = vol_remap(master->info.min_val,
> +                                       master->info.max_val,
> +                                       ucontrol->value.integer.value[0]);
>                 slave_put_val(slave, uval);
> +               /* And actually save the original unremapped volume
> +                  for master_get() */
> +               master->val = ucontrol->value.integer.value[0];
>         }
>         kfree(uval);
>         return 1;
>
> I looks like master-val is simply set twice (unless there are side
> effects happening in slave_put_val()).
>
> rtg
>
It seems to be a little hackery to save a temp. The intermediate value is
propagated by slave_put_val and the master value is kept as before.

--

When all other means of communication fail, try words!



--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

Re: [Hardy LPIA LUM]: RealTek hda-intel volume remapping for non-linear volume scales

Colin Ian King-2
In reply to this post by Tim Gardner-2
Hi Tim,

On Tue, 2009-04-21 at 09:33 -0600, Tim Gardner wrote:
> Colin Ian King wrote:
> > LP#249233 - sound volume too low.
> >
> > for Hardy LPIA LUM.
> >
[ Text deleted ]

> Is this really doing what you expect?
>
>  static int slave_get_val(struct link_slave *slave,
>                          struct snd_ctl_elem_value *ucontrol)
>  {
> @@ -305,8 +360,15 @@ static int master_put(struct snd_kcontrol *kcontrol,
>                 master->val = old_val;
>                 uval->id = slave->slave.id;
>                 slave_get_val(slave, uval);
> -               master->val = ucontrol->value.integer.value[0];
> +
> +               /* Put to slaves a remapped volume */
> +               master->val = vol_remap(master->info.min_val,
> +                                       master->info.max_val,
> +                                       ucontrol->value.integer.value[0]);
>                 slave_put_val(slave, uval);
> +               /* And actually save the original unremapped volume
> +                  for master_get() */
> +               master->val = ucontrol->value.integer.value[0];
>         }
>         kfree(uval);
>         return 1;
>
> I looks like master-val is simply set twice (unless there are side
> effects happening in slave_put_val()).

It's good to know your eye is keen...

The fact is that slave_put_val() requires a master->val to be set for
the volume to be set correctly (this case a remapped version). However
master->val can be interrogated later for the master volume setting, and
we need to return the expected value and not the remapped value else we
get ALSA confused. Without a major rewrite of slave_put_xval() I cannot
see around this.

Colin

>
> rtg
>
> --
> Tim Gardner [hidden email]
>
--
Colin King   <[hidden email]>
"Me transmitte sursum, caledoni"


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

Re: [Hardy LPIA LUM]: RealTek hda-intel volume remapping for non-linear volume scales

Stefan Bader-2
In reply to this post by Colin Ian King-2
Colin Ian King wrote:

> LP#249233 - sound volume too low.
>
> for Hardy LPIA LUM.
>
> The attached patch fixes a hardware volume scaling issue on a variety of
> Realtek chips found on Atom based netbooks. The main issue is that
> setting the volume at low levels is very low and does not scale
> linearly. Also, at high volume levels one can get distortion. Hence
> there is a requirement to keep the volume levels between a defined
> minimum and maximum and also try and scale the provided volume levels to
> produce a perceived linear scaling response.
>
> One can select linear or parabolic volume remapping to scale (remap) a
> volume level to physical volume level between a desired minimum
> and maximum range. This allows adjustment if the volume is not audible
> at low settings or distorts if set too high.
>
> Linear mapping scales the volume linearly between a given low and high.
>
> Parabolic mapping scales the volume between a given low and high
> so that low volume levels are scaled more favourably (using an inverse
> squared parabolic function) than high volume ranges to overcome
> non-linear volume scaling found on Realtek model cw020 hardware.
>
> The default is no mapping whatsoever.
>
> Attached: The patch.
>
>
The rest seems sane. ACK

--

When all other means of communication fail, try words!



--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

Re: [Hardy LPIA LUM]: RealTek hda-intel volume remapping for non-linear volume scales

Tim Gardner-2
In reply to this post by Colin Ian King-2
Colin Ian King wrote:

> Hi Tim,
>
> On Tue, 2009-04-21 at 09:33 -0600, Tim Gardner wrote:
>> Colin Ian King wrote:
>>> LP#249233 - sound volume too low.
>>>
>>> for Hardy LPIA LUM.
>>>
> [ Text deleted ]
>
>> Is this really doing what you expect?
>>
>>  static int slave_get_val(struct link_slave *slave,
>>                          struct snd_ctl_elem_value *ucontrol)
>>  {
>> @@ -305,8 +360,15 @@ static int master_put(struct snd_kcontrol *kcontrol,
>>                 master->val = old_val;
>>                 uval->id = slave->slave.id;
>>                 slave_get_val(slave, uval);
>> -               master->val = ucontrol->value.integer.value[0];
>> +
>> +               /* Put to slaves a remapped volume */
>> +               master->val = vol_remap(master->info.min_val,
>> +                                       master->info.max_val,
>> +                                       ucontrol->value.integer.value[0]);
>>                 slave_put_val(slave, uval);
>> +               /* And actually save the original unremapped volume
>> +                  for master_get() */
>> +               master->val = ucontrol->value.integer.value[0];
>>         }
>>         kfree(uval);
>>         return 1;
>>
>> I looks like master-val is simply set twice (unless there are side
>> effects happening in slave_put_val()).
>
> It's good to know your eye is keen...
>
> The fact is that slave_put_val() requires a master->val to be set for
> the volume to be set correctly (this case a remapped version). However
> master->val can be interrogated later for the master volume setting, and
> we need to return the expected value and not the remapped value else we
> get ALSA confused. Without a major rewrite of slave_put_xval() I cannot
> see around this.
>
> Colin

In that case ACK (but also ick!)

--
Tim Gardner [hidden email]

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

Re: [Hardy LPIA LUM]: RealTek hda-intel volume remapping for non-linear volume scales

Stefan Bader-2
In reply to this post by Colin Ian King-2
Just one thought that occurred: has this any chance to go upstream? What will
be our plan for Intrepid and following?

--

When all other means of communication fail, try words!



--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

Re: [Hardy LPIA LUM]: RealTek hda-intel volume remapping for non-linear volume scales

Andy Whitcroft-3
In reply to this post by Colin Ian King-2
On Tue, Apr 21, 2009 at 04:51:21PM +0100, Colin Ian King wrote:

> It's good to know your eye is keen...
>
> The fact is that slave_put_val() requires a master->val to be set for
> the volume to be set correctly (this case a remapped version). However
> master->val can be interrogated later for the master volume setting, and
> we need to return the expected value and not the remapped value else we
> get ALSA confused. Without a major rewrite of slave_put_xval() I cannot
> see around this.

Which lock is protecting master->val for the duration of the update, ie.
while it is holding the bodged value to prevent alsa seeing it?

-apw

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

Re: [Hardy LPIA LUM]: RealTek hda-intel volume remapping for non-linear volume scales

Colin Ian King-2
On Wed, 2009-04-22 at 01:48 +0100, Andy Whitcroft wrote:

> On Tue, Apr 21, 2009 at 04:51:21PM +0100, Colin Ian King wrote:
>
> > It's good to know your eye is keen...
> >
> > The fact is that slave_put_val() requires a master->val to be set for
> > the volume to be set correctly (this case a remapped version). However
> > master->val can be interrogated later for the master volume setting, and
> > we need to return the expected value and not the remapped value else we
> > get ALSA confused. Without a major rewrite of slave_put_xval() I cannot
> > see around this.
>
> Which lock is protecting master->val for the duration of the update, ie.
> while it is holding the bodged value to prevent alsa seeing it?
Andy, you are 100% right in questioning this. Attached is corrected
version containing a mutex to protect the master value in the
master_get()/master_put() functions.


--
Colin King   <[hidden email]>
"Me transmitte sursum, caledoni"

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team

0001-UBUNTU-SAUCE-hda-intel-volume-remapping-for-non-li.patch (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Hardy LPIA LUM]: RealTek hda-intel volume remapping for non-linear volume scales

Tim Gardner-2
Colin Ian King wrote:

> On Wed, 2009-04-22 at 01:48 +0100, Andy Whitcroft wrote:
>> On Tue, Apr 21, 2009 at 04:51:21PM +0100, Colin Ian King wrote:
>>
>>> It's good to know your eye is keen...
>>>
>>> The fact is that slave_put_val() requires a master->val to be set for
>>> the volume to be set correctly (this case a remapped version). However
>>> master->val can be interrogated later for the master volume setting, and
>>> we need to return the expected value and not the remapped value else we
>>> get ALSA confused. Without a major rewrite of slave_put_xval() I cannot
>>> see around this.
>> Which lock is protecting master->val for the duration of the update, ie.
>> while it is holding the bodged value to prevent alsa seeing it?
>
> Andy, you are 100% right in questioning this. Attached is corrected
> version containing a mutex to protect the master value in the
> master_get()/master_put() functions.
>
>
>

Stefan - the version of the patch that you pulled does not appear to
have Colin's locking changes.

--
Tim Gardner [hidden email]

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

Re: [Hardy LPIA LUM]: RealTek hda-intel volume remapping for non-linear volume scales

Stefan Bader-2
Tim Gardner wrote:

> Colin Ian King wrote:
>> On Wed, 2009-04-22 at 01:48 +0100, Andy Whitcroft wrote:
>>> On Tue, Apr 21, 2009 at 04:51:21PM +0100, Colin Ian King wrote:
>>>
>>>> It's good to know your eye is keen...
>>>>
>>>> The fact is that slave_put_val() requires a master->val to be set for
>>>> the volume to be set correctly (this case a remapped version). However
>>>> master->val can be interrogated later for the master volume setting, and
>>>> we need to return the expected value and not the remapped value else we
>>>> get ALSA confused. Without a major rewrite of slave_put_xval() I cannot
>>>> see around this.
>>> Which lock is protecting master->val for the duration of the update, ie.
>>> while it is holding the bodged value to prevent alsa seeing it?
>> Andy, you are 100% right in questioning this. Attached is corrected
>> version containing a mutex to protect the master value in the
>> master_get()/master_put() functions.
>>
>>
>>
>
> Stefan - the version of the patch that you pulled does not appear to
> have Colin's locking changes.
>
I don't remember pulling this at all. Either my memory or...


--

When all other means of communication fail, try words!



--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

Re: [Hardy LPIA LUM]: RealTek hda-intel volume remapping for non-linear volume scales

Tim Gardner-2
Stefan Bader wrote:

> Tim Gardner wrote:
>> Colin Ian King wrote:
>>> On Wed, 2009-04-22 at 01:48 +0100, Andy Whitcroft wrote:
>>>> On Tue, Apr 21, 2009 at 04:51:21PM +0100, Colin Ian King wrote:
>>>>
>>>>> It's good to know your eye is keen...
>>>>> The fact is that slave_put_val() requires a master->val to be set for
>>>>> the volume to be set correctly (this case a remapped version). However
>>>>> master->val can be interrogated later for the master volume
>>>>> setting, and
>>>>> we need to return the expected value and not the remapped value
>>>>> else we
>>>>> get ALSA confused. Without a major rewrite of slave_put_xval() I
>>>>> cannot
>>>>> see around this.
>>>> Which lock is protecting master->val for the duration of the update,
>>>> ie.
>>>> while it is holding the bodged value to prevent alsa seeing it?
>>> Andy, you are 100% right in questioning this. Attached is corrected
>>> version containing a mutex to protect the master value in the
>>> master_get()/master_put() functions.
>>>
>>>
>>
>> Stefan - the version of the patch that you pulled does not appear to
>> have Colin's locking changes.
>>
> I don't remember pulling this at all. Either my memory or...
>
>

Hmm, Colin?

--
Tim Gardner [hidden email]

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team