alsactl adds volume controls?

alsactl adds volume controls?

[David Henningsson]

So I've discovered that my sound card has a "PCM Playback Volume"
control, but changing that control does not alter the volume. This is
not only confusing but also a problem for PulseAudio. (PA merges this
control into it's overall volume, and so when the user moves PA's volume
control, in some ranges nothing happens.)

Interestingly enough, this control does not come from the HDA parser, it
is added by alsactl at boot time...! (Through alsa-lib's
snd_ctl_elem_add_integer, which does an snd_ctl_ioctl.)

So the question is, why is alsactl creating volume controls, and why is
userspace allowed to add controls in the first place, if the kernel
can't use them for anything anyway? That doesn't make sense to me.

This a generic problem, but sound card info, if that matters, is
available here:
https://launchpad.net/bugs/625149
Codec: http://launchpadlibrarian.net/54478760/Card0.Codecs.codec.0.txt

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

Re: alsactl adds volume controls?

[Clemens Ladisch]

David Henningsson wrote:
> So I've discovered that my sound card has a "PCM Playback Volume"
> control, but changing that control does not alter the volume.
> 
> Interestingly enough, this control does not come from the HDA parser, it
> is added by alsactl at boot time...!

This control was created by the software volume plugin.  When not using
this plugin, the control does not have any effect.

To get rid of it, delete its entry from /etc/asound.state.


Regards,
Clemens

Re: alsactl adds volume controls?

[David Henningsson]

2010-08-27 17:43, Clemens Ladisch skrev:
> David Henningsson wrote:
>> So I've discovered that my sound card has a "PCM Playback Volume"
>> control, but changing that control does not alter the volume.
>>
>> Interestingly enough, this control does not come from the HDA parser, it
>> is added by alsactl at boot time...!
> 
> This control was created by the software volume plugin.  When not using
> this plugin, the control does not have any effect.
> 
> To get rid of it, delete its entry from /etc/asound.state.

Hmm, I wonder if this is an Ubuntu-specific bug then? Because when I run
Maverick (the upcoming Ubuntu release) from a Live-CD, the "PCM Playback
Volume" control is still there (and there is no asound.state, neither in
/etc or in /var/lib/alsa).
When I use the plughw interface, the "PCM Playback Volume" does not
affect volume output. Should I use another device string to test the
softvol plugin, to see if it's there or not?

Btw, I still think it's strange that a userspace plugin, with controls
that only effects userspace, still can create controls in kernel-space.
Am I missing something?

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

Re: alsactl adds volume controls?

[Raymond Yau]

2010/8/28 David Henningsson <david.henningsson@canonical.com>

> 2010-08-27 17:43, Clemens Ladisch skrev:
> > David Henningsson wrote:
> >> So I've discovered that my sound card has a "PCM Playback Volume"
> >> control, but changing that control does not alter the volume.
> >>
> >> Interestingly enough, this control does not come from the HDA parser, it
> >> is added by alsactl at boot time...!
> >
> > This control was created by the software volume plugin.  When not using
> > this plugin, the control does not have any effect.
> >
> > To get rid of it, delete its entry from /etc/asound.state.
>
> Hmm, I wonder if this is an Ubuntu-specific bug then? Because when I run
> Maverick (the upcoming Ubuntu release) from a Live-CD, the "PCM Playback
> Volume" control is still there (and there is no asound.state, neither in
> /etc or in /var/lib/alsa).
> When I use the plughw interface, the "PCM Playback Volume" does not
> affect volume output. Should I use another device string to test the
> softvol plugin, to see if it's there or not?
>

The softvol plugin it is defined in "front" device in
/usr/share/alsa/cards/HDA-Intel.conf

reason is some HDA codec does not has any hardware volume control (analog)

this user-defined control only effective when the application use "front"
device

it is a bug in PA server to open "front" device for playback and capture

it is not easy to remove the control unless you know the trick

shutdown without alsactl store

Re: alsactl adds volume controls?

[Raymond Yau]

2010/8/27 David Henningsson <david.henningsson@canonical.com>

> So I've discovered that my sound card has a "PCM Playback Volume"
> control, but changing that control does not alter the volume. This is
> not only confusing but also a problem for PulseAudio. (PA merges this
> control into it's overall volume, and so when the user moves PA's volume
> control, in some ranges nothing happens.)
>

The "PCM Playback Volume" is a hardware volume control for those AC97 codec
( the name is "Wave" in Windows )

The "PCM Playback Volume" is most likely softvol on HDA Intel since it is
defined in HDA-Intel.conf

AFAIK, aplay has an option to disable softvol by using SND_PCM_NO_SOFTVOL

   --disable-softvol   disable software volume control (softvol)

Re: alsactl adds volume controls?

[Takashi Iwai]

At Sat, 28 Aug 2010 06:58:20 +0800,
Raymond Yau wrote:
> 
> 2010/8/28 David Henningsson <david.henningsson@canonical.com>
> 
> > 2010-08-27 17:43, Clemens Ladisch skrev:
> > > David Henningsson wrote:
> > >> So I've discovered that my sound card has a "PCM Playback Volume"
> > >> control, but changing that control does not alter the volume.
> > >>
> > >> Interestingly enough, this control does not come from the HDA parser, it
> > >> is added by alsactl at boot time...!
> > >
> > > This control was created by the software volume plugin.  When not using
> > > this plugin, the control does not have any effect.
> > >
> > > To get rid of it, delete its entry from /etc/asound.state.
> >
> > Hmm, I wonder if this is an Ubuntu-specific bug then? Because when I run
> > Maverick (the upcoming Ubuntu release) from a Live-CD, the "PCM Playback
> > Volume" control is still there (and there is no asound.state, neither in
> > /etc or in /var/lib/alsa).
> > When I use the plughw interface, the "PCM Playback Volume" does not
> > affect volume output. Should I use another device string to test the
> > softvol plugin, to see if it's there or not?
> >
> 
> The softvol plugin it is defined in "front" device in
> /usr/share/alsa/cards/HDA-Intel.conf
> 
> reason is some HDA codec does not has any hardware volume control (analog)
> 
> this user-defined control only effective when the application use "front"
> device

Hm, but if PA opens the device with SND_PCM_NO_SOFTVOL flag, the
softvol should be skipped.


Takashi

Re: alsactl adds volume controls?

[Raymond Yau]

2010/8/30 Takashi Iwai <tiwai@suse.de>

> At Sat, 28 Aug 2010 06:58:20 +0800,
> Raymond Yau wrote:
> >
> > 2010/8/28 David Henningsson <david.henningsson@canonical.com>
> >
> > > 2010-08-27 17:43, Clemens Ladisch skrev:
> > > > David Henningsson wrote:
> > > >> So I've discovered that my sound card has a "PCM Playback Volume"
> > > >> control, but changing that control does not alter the volume.
> > > >>
> > > >> Interestingly enough, this control does not come from the HDA
> parser, it
> > > >> is added by alsactl at boot time...!
> > > >
> > > > This control was created by the software volume plugin.  When not
> using
> > > > this plugin, the control does not have any effect.
> > > >
> > > > To get rid of it, delete its entry from /etc/asound.state.
> > >
> > > Hmm, I wonder if this is an Ubuntu-specific bug then? Because when I
> run
> > > Maverick (the upcoming Ubuntu release) from a Live-CD, the "PCM
> Playback
> > > Volume" control is still there (and there is no asound.state, neither
> in
> > > /etc or in /var/lib/alsa).
> > > When I use the plughw interface, the "PCM Playback Volume" does not
> > > affect volume output. Should I use another device string to test the
> > > softvol plugin, to see if it's there or not?
> > >
> >
> > The softvol plugin it is defined in "front" device in
> > /usr/share/alsa/cards/HDA-Intel.conf
> >
> > reason is some HDA codec does not has any hardware volume control
> (analog)
> >
> > this user-defined control only effective when the application use "front"
> > device
>
> Hm, but if PA opens the device with SND_PCM_NO_SOFTVOL flag, the
> softvol should be skipped.
>
>
AFAIK, PA did not use SND_PCM_NO_SOFTVOL and in "analog stereo duplex"
profile , PA open "front" device for playback and capture which access the
same "PCM Playback volume" control concurrently

You can see the output of snd_pcm_dump() in the pulseraudio log still
contain soffvol which is an indiication that PA did not use
SND_PCM_NO_SOFTVOL

the softvol control can only be distinguished using
snd_ctl_elem_info_is_user()  and there is no snd_mixer_* function to find
out the softvol control since PA server use simple mixer api

Re: alsactl adds volume controls?

[Takashi Iwai]

At Mon, 30 Aug 2010 17:30:19 +0800,
Raymond Yau wrote:
> 
> 2010/8/30 Takashi Iwai <tiwai@suse.de>
> 
> > At Sat, 28 Aug 2010 06:58:20 +0800,
> > Raymond Yau wrote:
> > >
> > > 2010/8/28 David Henningsson <david.henningsson@canonical.com>
> > >
> > > > 2010-08-27 17:43, Clemens Ladisch skrev:
> > > > > David Henningsson wrote:
> > > > >> So I've discovered that my sound card has a "PCM Playback Volume"
> > > > >> control, but changing that control does not alter the volume.
> > > > >>
> > > > >> Interestingly enough, this control does not come from the HDA
> > parser, it
> > > > >> is added by alsactl at boot time...!
> > > > >
> > > > > This control was created by the software volume plugin.  When not
> > using
> > > > > this plugin, the control does not have any effect.
> > > > >
> > > > > To get rid of it, delete its entry from /etc/asound.state.
> > > >
> > > > Hmm, I wonder if this is an Ubuntu-specific bug then? Because when I
> > run
> > > > Maverick (the upcoming Ubuntu release) from a Live-CD, the "PCM
> > Playback
> > > > Volume" control is still there (and there is no asound.state, neither
> > in
> > > > /etc or in /var/lib/alsa).
> > > > When I use the plughw interface, the "PCM Playback Volume" does not
> > > > affect volume output. Should I use another device string to test the
> > > > softvol plugin, to see if it's there or not?
> > > >
> > >
> > > The softvol plugin it is defined in "front" device in
> > > /usr/share/alsa/cards/HDA-Intel.conf
> > >
> > > reason is some HDA codec does not has any hardware volume control
> > (analog)
> > >
> > > this user-defined control only effective when the application use "front"
> > > device
> >
> > Hm, but if PA opens the device with SND_PCM_NO_SOFTVOL flag, the
> > softvol should be skipped.
> >
> >
> AFAIK, PA did not use SND_PCM_NO_SOFTVOL and in "analog stereo duplex"
> profile , PA open "front" device for playback and capture which access the
> same "PCM Playback volume" control concurrently

OK, then the fix would be let PA use this flag.
The softvol makes really no sense for PA...


Takashi

> You can see the output of snd_pcm_dump() in the pulseraudio log still
> contain soffvol which is an indiication that PA did not use
> SND_PCM_NO_SOFTVOL
> 
> the softvol control can only be distinguished using
> snd_ctl_elem_info_is_user()  and there is no snd_mixer_* function to find
> out the softvol control since PA server use simple mixer api
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> 

Re: alsactl adds volume controls?

[David Henningsson]

2010-08-30 10:01, Takashi Iwai skrev:
> At Sat, 28 Aug 2010 06:58:20 +0800,
> Raymond Yau wrote:
>>
>> 2010/8/28 David Henningsson <david.henningsson@canonical.com>
>>
>>> 2010-08-27 17:43, Clemens Ladisch skrev:
>>>> David Henningsson wrote:
>>>>> So I've discovered that my sound card has a "PCM Playback Volume"
>>>>> control, but changing that control does not alter the volume.
>>>>>
>>>>> Interestingly enough, this control does not come from the HDA parser, it
>>>>> is added by alsactl at boot time...!
>>>>
>>>> This control was created by the software volume plugin.  When not using
>>>> this plugin, the control does not have any effect.
>>>>
>>>> To get rid of it, delete its entry from /etc/asound.state.
>>>
>>> Hmm, I wonder if this is an Ubuntu-specific bug then? Because when I run
>>> Maverick (the upcoming Ubuntu release) from a Live-CD, the "PCM Playback
>>> Volume" control is still there (and there is no asound.state, neither in
>>> /etc or in /var/lib/alsa).
>>> When I use the plughw interface, the "PCM Playback Volume" does not
>>> affect volume output. Should I use another device string to test the
>>> softvol plugin, to see if it's there or not?
>>>
>>
>> The softvol plugin it is defined in "front" device in
>> /usr/share/alsa/cards/HDA-Intel.conf
>>
>> reason is some HDA codec does not has any hardware volume control (analog)
>>
>> this user-defined control only effective when the application use "front"
>> device
> 
> Hm, but if PA opens the device with SND_PCM_NO_SOFTVOL flag, the
> softvol should be skipped.

But that does not apply to the mixer controls as well, does it? I think
we still have a problem with PA assuming that it can change the PCM
volume control to change the output volume.


-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

Re: alsactl adds volume controls?

[Takashi Iwai]

At Mon, 30 Aug 2010 15:01:29 +0200,
David Henningsson wrote:
> 
> 2010-08-30 10:01, Takashi Iwai skrev:
> > At Sat, 28 Aug 2010 06:58:20 +0800,
> > Raymond Yau wrote:
> >>
> >> 2010/8/28 David Henningsson <david.henningsson@canonical.com>
> >>
> >>> 2010-08-27 17:43, Clemens Ladisch skrev:
> >>>> David Henningsson wrote:
> >>>>> So I've discovered that my sound card has a "PCM Playback Volume"
> >>>>> control, but changing that control does not alter the volume.
> >>>>>
> >>>>> Interestingly enough, this control does not come from the HDA parser, it
> >>>>> is added by alsactl at boot time...!
> >>>>
> >>>> This control was created by the software volume plugin.  When not using
> >>>> this plugin, the control does not have any effect.
> >>>>
> >>>> To get rid of it, delete its entry from /etc/asound.state.
> >>>
> >>> Hmm, I wonder if this is an Ubuntu-specific bug then? Because when I run
> >>> Maverick (the upcoming Ubuntu release) from a Live-CD, the "PCM Playback
> >>> Volume" control is still there (and there is no asound.state, neither in
> >>> /etc or in /var/lib/alsa).
> >>> When I use the plughw interface, the "PCM Playback Volume" does not
> >>> affect volume output. Should I use another device string to test the
> >>> softvol plugin, to see if it's there or not?
> >>>
> >>
> >> The softvol plugin it is defined in "front" device in
> >> /usr/share/alsa/cards/HDA-Intel.conf
> >>
> >> reason is some HDA codec does not has any hardware volume control (analog)
> >>
> >> this user-defined control only effective when the application use "front"
> >> device
> > 
> > Hm, but if PA opens the device with SND_PCM_NO_SOFTVOL flag, the
> > softvol should be skipped.
> 
> But that does not apply to the mixer controls as well, does it?

It does.  The mixer element is created when this kind of PCM stream is
opened without SND_PCM_NO_SOFTVOL flag.  Then it leaves the control
for the later use, and alsactl saves/restores it.  So, it's a chicken-
and-egg problem.

Of course, it's possible that it wasn't PA who opened the PCM stream.
But, something opened the stream and it created the mixer element.
This is the correct behavior.

> I think
> we still have a problem with PA assuming that it can change the PCM
> volume control to change the output volume.

PA can check whether it's a user-defined control or not.


Takashi

Re: alsactl adds volume controls?

[David Henningsson]

2010-08-30 15:08, Takashi Iwai skrev:
> At Mon, 30 Aug 2010 15:01:29 +0200,
> David Henningsson wrote:
>>
>> 2010-08-30 10:01, Takashi Iwai skrev:
>>> At Sat, 28 Aug 2010 06:58:20 +0800,
>>> Raymond Yau wrote:
>>>>
>>>> 2010/8/28 David Henningsson <david.henningsson@canonical.com>
>>>>
>>>>> 2010-08-27 17:43, Clemens Ladisch skrev:
>>>>>> David Henningsson wrote:
>>>>>>> So I've discovered that my sound card has a "PCM Playback Volume"
>>>>>>> control, but changing that control does not alter the volume.
>>>>>>>
>>>>>>> Interestingly enough, this control does not come from the HDA parser, it
>>>>>>> is added by alsactl at boot time...!
>>>>>>
>>>>>> This control was created by the software volume plugin.  When not using
>>>>>> this plugin, the control does not have any effect.
>>>>>>
>>>>>> To get rid of it, delete its entry from /etc/asound.state.
>>>>>
>>>>> Hmm, I wonder if this is an Ubuntu-specific bug then? Because when I run
>>>>> Maverick (the upcoming Ubuntu release) from a Live-CD, the "PCM Playback
>>>>> Volume" control is still there (and there is no asound.state, neither in
>>>>> /etc or in /var/lib/alsa).
>>>>> When I use the plughw interface, the "PCM Playback Volume" does not
>>>>> affect volume output. Should I use another device string to test the
>>>>> softvol plugin, to see if it's there or not?
>>>>
>>>> The softvol plugin it is defined in "front" device in
>>>> /usr/share/alsa/cards/HDA-Intel.conf
>>>>
>>>> reason is some HDA codec does not has any hardware volume control (analog)
>>>>
>>>> this user-defined control only effective when the application use "front"
>>>> device
>>>
>>> Hm, but if PA opens the device with SND_PCM_NO_SOFTVOL flag, the
>>> softvol should be skipped.
>>
>> But that does not apply to the mixer controls as well, does it?
> 
> It does.  The mixer element is created when this kind of PCM stream is
> opened without SND_PCM_NO_SOFTVOL flag.  Then it leaves the control
> for the later use, and alsactl saves/restores it.  So, it's a chicken-
> and-egg problem.

Sounds a little strange to me. Thinking in general, if something is
created when a stream is opened, that something should be destroyed when
the stream is closed.

> Of course, it's possible that it wasn't PA who opened the PCM stream.
> But, something opened the stream and it created the mixer element.
> This is the correct behavior.

And once created, it stays there forever... So even if PA does not
create it, we'll just transform a persistent problem to an suddenly
appearing problem?

Anyway, do we want softvol at all for HDA? Wouldn't that be such an
unusual use case, that those people that can't adjust volume any other
way, can add that softvol themselves in .asoundrc?

>> I think
>> we still have a problem with PA assuming that it can change the PCM
>> volume control to change the output volume.
> 
> PA can check whether it's a user-defined control or not.

Would that be safe - I mean, can't there be user-defined controls PA
*should* care about?

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

Re: alsactl adds volume controls?

[Raymond Yau]

2010/9/1 David Henningsson <david.henningsson@canonical.com>

> 2010-08-30 15:08, Takashi Iwai skrev:
> > At Mon, 30 Aug 2010 15:01:29 +0200,
> > David Henningsson wrote:
> >>
> >> 2010-08-30 10:01, Takashi Iwai skrev:
> >>> At Sat, 28 Aug 2010 06:58:20 +0800,
> >>> Raymond Yau wrote:
> >>>>
> >>>> 2010/8/28 David Henningsson <david.henningsson@canonical.com>
> >>>>
> >>>>> 2010-08-27 17:43, Clemens Ladisch skrev:
> >>>>>> David Henningsson wrote:
> >>>>>>> So I've discovered that my sound card has a "PCM Playback Volume"
> >>>>>>> control, but changing that control does not alter the volume.
> >>>>>>>
> >>>>>>> Interestingly enough, this control does not come from the HDA
> parser, it
> >>>>>>> is added by alsactl at boot time...!
> >>>>>>
> >>>>>> This control was created by the software volume plugin.  When not
> using
> >>>>>> this plugin, the control does not have any effect.
> >>>>>>
> >>>>>> To get rid of it, delete its entry from /etc/asound.state.
> >>>>>
> >>>>> Hmm, I wonder if this is an Ubuntu-specific bug then? Because when I
> run
> >>>>> Maverick (the upcoming Ubuntu release) from a Live-CD, the "PCM
> Playback
> >>>>> Volume" control is still there (and there is no asound.state, neither
> in
> >>>>> /etc or in /var/lib/alsa).
> >>>>> When I use the plughw interface, the "PCM Playback Volume" does not
> >>>>> affect volume output. Should I use another device string to test the
> >>>>> softvol plugin, to see if it's there or not?
> >>>>
> >>>> The softvol plugin it is defined in "front" device in
> >>>> /usr/share/alsa/cards/HDA-Intel.conf
> >>>>
> >>>> reason is some HDA codec does not has any hardware volume control
> (analog)
> >>>>
> >>>> this user-defined control only effective when the application use
> "front"
> >>>> device
> >>>
> >>> Hm, but if PA opens the device with SND_PCM_NO_SOFTVOL flag, the
> >>> softvol should be skipped.
> >>
> >> But that does not apply to the mixer controls as well, does it?
> >
> > It does.  The mixer element is created when this kind of PCM stream is
> > opened without SND_PCM_NO_SOFTVOL flag.  Then it leaves the control
> > for the later use, and alsactl saves/restores it.  So, it's a chicken-
> > and-egg problem.
>
> Sounds a little strange to me. Thinking in general, if something is
> created when a stream is opened, that something should be destroyed when
> the stream is closed.
>

Them , the mixer application will also abort when the stream is closed and
you cannot access the control before the stream is opened (i.e. just like
those hardware PCM volume control of ymfpci or via82xx


>
> > Of course, it's possible that it wasn't PA who opened the PCM stream.
> > But, something opened the stream and it created the mixer element.
> > This is the correct behavior.
>
> And once created, it stays there forever... So even if PA does not
> create it, we'll just transform a persistent problem to an suddenly
> appearing problem?
>
> Anyway, do we want softvol at all for HDA? Wouldn't that be such an
> unusual use case, that those people that can't adjust volume any other
> way, can add that softvol themselves in .asoundrc?
>
> >> I think
> >> we still have a problem with PA assuming that it can change the PCM
> >> volume control to change the output volume.
> >
> > PA can check whether it's a user-defined control or not.
>
> Would that be safe - I mean, can't there be user-defined controls PA
> *should* care about?
>

>From the viewpoint of PA server , it just want to know how to calculate the
total dB range of the hardware volume controls in the audio path from DAC
[Audio Output] to the speakers/ headphone [Pin complex]

it don't really need softvol plugin if PA server can really provide software
attenuation when the sound card does not has hardware volume control

Re: alsactl adds volume controls?

[Takashi Iwai]

At Wed, 01 Sep 2010 15:26:54 +0200,
David Henningsson wrote:
> 
> 2010-08-30 15:08, Takashi Iwai skrev:
> > At Mon, 30 Aug 2010 15:01:29 +0200,
> > David Henningsson wrote:
> >>
> >> 2010-08-30 10:01, Takashi Iwai skrev:
> >>> At Sat, 28 Aug 2010 06:58:20 +0800,
> >>> Raymond Yau wrote:
> >>>>
> >>>> 2010/8/28 David Henningsson <david.henningsson@canonical.com>
> >>>>
> >>>>> 2010-08-27 17:43, Clemens Ladisch skrev:
> >>>>>> David Henningsson wrote:
> >>>>>>> So I've discovered that my sound card has a "PCM Playback Volume"
> >>>>>>> control, but changing that control does not alter the volume.
> >>>>>>>
> >>>>>>> Interestingly enough, this control does not come from the HDA parser, it
> >>>>>>> is added by alsactl at boot time...!
> >>>>>>
> >>>>>> This control was created by the software volume plugin.  When not using
> >>>>>> this plugin, the control does not have any effect.
> >>>>>>
> >>>>>> To get rid of it, delete its entry from /etc/asound.state.
> >>>>>
> >>>>> Hmm, I wonder if this is an Ubuntu-specific bug then? Because when I run
> >>>>> Maverick (the upcoming Ubuntu release) from a Live-CD, the "PCM Playback
> >>>>> Volume" control is still there (and there is no asound.state, neither in
> >>>>> /etc or in /var/lib/alsa).
> >>>>> When I use the plughw interface, the "PCM Playback Volume" does not
> >>>>> affect volume output. Should I use another device string to test the
> >>>>> softvol plugin, to see if it's there or not?
> >>>>
> >>>> The softvol plugin it is defined in "front" device in
> >>>> /usr/share/alsa/cards/HDA-Intel.conf
> >>>>
> >>>> reason is some HDA codec does not has any hardware volume control (analog)
> >>>>
> >>>> this user-defined control only effective when the application use "front"
> >>>> device
> >>>
> >>> Hm, but if PA opens the device with SND_PCM_NO_SOFTVOL flag, the
> >>> softvol should be skipped.
> >>
> >> But that does not apply to the mixer controls as well, does it?
> > 
> > It does.  The mixer element is created when this kind of PCM stream is
> > opened without SND_PCM_NO_SOFTVOL flag.  Then it leaves the control
> > for the later use, and alsactl saves/restores it.  So, it's a chicken-
> > and-egg problem.
> 
> Sounds a little strange to me. Thinking in general, if something is
> created when a stream is opened, that something should be destroyed when
> the stream is closed.

It's not about the stream-level volume.  It's about the global volume.
There have been bunch of machines that have no h/w volume control.
This is the mechanism for such environment.  You certainly don't want
to reset the system-level volume at each time you close the stream.

> > Of course, it's possible that it wasn't PA who opened the PCM stream.
> > But, something opened the stream and it created the mixer element.
> > This is the correct behavior.
> 
> And once created, it stays there forever...

Not necessarily forever.  It's alsactl who saves/restores the element

> So even if PA does not
> create it, we'll just transform a persistent problem to an suddenly
> appearing problem?

Yes, it's just because you started an app that doesn't cope with PA.
And, it's PA who doesn't cope with softvol setup.  This is the
conflicting situation.

Now the system doesn't know whether you'll start the non-PA app
again.  So, the volume has to be retained.

> Anyway, do we want softvol at all for HDA? Wouldn't that be such an
> unusual use case, that those people that can't adjust volume any other
> way, can add that softvol themselves in .asoundrc?

The softvol itself does nothing if the corresponding h/w volume
control exists.  It's activated only when the corresponding volume
element is unavailable.

> >> I think
> >> we still have a problem with PA assuming that it can change the PCM
> >> volume control to change the output volume.
> > 
> > PA can check whether it's a user-defined control or not.
> 
> Would that be safe - I mean, can't there be user-defined controls PA
> *should* care about?

It depends on the driver implementation, but as long as PA does
software volume control by itself, and as long as the control elements
are mixer elements, they can be ignored.


Takashi

Re: alsactl adds volume controls?

[David Henningsson]

2010-09-02 10:06, Takashi Iwai skrev:
> At Wed, 01 Sep 2010 15:26:54 +0200,
> David Henningsson wrote:
>>
>> 2010-08-30 15:08, Takashi Iwai skrev:
>>> At Mon, 30 Aug 2010 15:01:29 +0200,
>>> David Henningsson wrote:
>>>>
>>>> 2010-08-30 10:01, Takashi Iwai skrev:
>>>>> At Sat, 28 Aug 2010 06:58:20 +0800,
>>>>> Raymond Yau wrote:
>>>>>>
>>>>>> 2010/8/28 David Henningsson <david.henningsson@canonical.com>
>>>>>>
>>>>>>> 2010-08-27 17:43, Clemens Ladisch skrev:
>>>>>>>> David Henningsson wrote:
>>>>>>>>> So I've discovered that my sound card has a "PCM Playback Volume"
>>>>>>>>> control, but changing that control does not alter the volume.
>>>>>>>>>
>>>>>>>>> Interestingly enough, this control does not come from the HDA parser, it
>>>>>>>>> is added by alsactl at boot time...!
>>>>>>>>
>>>>>>>> This control was created by the software volume plugin.  When not using
>>>>>>>> this plugin, the control does not have any effect.
>>>>>>>>
>>>>>>>> To get rid of it, delete its entry from /etc/asound.state.
>>>>>>>
>>>>>>> Hmm, I wonder if this is an Ubuntu-specific bug then? Because when I run
>>>>>>> Maverick (the upcoming Ubuntu release) from a Live-CD, the "PCM Playback
>>>>>>> Volume" control is still there (and there is no asound.state, neither in
>>>>>>> /etc or in /var/lib/alsa).
>>>>>>> When I use the plughw interface, the "PCM Playback Volume" does not
>>>>>>> affect volume output. Should I use another device string to test the
>>>>>>> softvol plugin, to see if it's there or not?
>>>>>>
>>>>>> The softvol plugin it is defined in "front" device in
>>>>>> /usr/share/alsa/cards/HDA-Intel.conf
>>>>>>
>>>>>> reason is some HDA codec does not has any hardware volume control (analog)
>>>>>>
>>>>>> this user-defined control only effective when the application use "front"
>>>>>> device
>>>>>
>>>>> Hm, but if PA opens the device with SND_PCM_NO_SOFTVOL flag, the
>>>>> softvol should be skipped.
>>>>
>>>> But that does not apply to the mixer controls as well, does it?
>>>
>>> It does.  The mixer element is created when this kind of PCM stream is
>>> opened without SND_PCM_NO_SOFTVOL flag.  Then it leaves the control
>>> for the later use, and alsactl saves/restores it.  So, it's a chicken-
>>> and-egg problem.
>>
>> Sounds a little strange to me. Thinking in general, if something is
>> created when a stream is opened, that something should be destroyed when
>> the stream is closed.
> 
> It's not about the stream-level volume.  It's about the global volume.
> There have been bunch of machines that have no h/w volume control.
> This is the mechanism for such environment.  You certainly don't want
> to reset the system-level volume at each time you close the stream.

So if it's about the global volume it should be created on startup
rather than when the stream is opened for the first time.

>>> Of course, it's possible that it wasn't PA who opened the PCM stream.
>>> But, something opened the stream and it created the mixer element.
>>> This is the correct behavior.
>>
>> And once created, it stays there forever...
> 
> Not necessarily forever.  It's alsactl who saves/restores the element
> 
>> So even if PA does not
>> create it, we'll just transform a persistent problem to an suddenly
>> appearing problem?
> 
> Yes, it's just because you started an app that doesn't cope with PA.
> And, it's PA who doesn't cope with softvol setup.  This is the
> conflicting situation.

So as I understand it PA should call snd_pcm_open with the
SND_PCM_NO_SOFTVOL, which it currently does not. It still puzzles me
however how PA manages to open without that flag, which creates a mixer
control, and later on that softvol control has no effect.

> Now the system doesn't know whether you'll start the non-PA app
> again.  So, the volume has to be retained.
> 
>> Anyway, do we want softvol at all for HDA? Wouldn't that be such an
>> unusual use case, that those people that can't adjust volume any other
>> way, can add that softvol themselves in .asoundrc?
> 
> The softvol itself does nothing if the corresponding h/w volume
> control exists.  It's activated only when the corresponding volume
> element is unavailable.

Right, but I have a "Master" volume, a "Front" volume, "Headphone"
volume and so on, so I have all the HW volumes I need, it's just that
none of them happen to be labeled "PCM".

>>>> I think
>>>> we still have a problem with PA assuming that it can change the PCM
>>>> volume control to change the output volume.
>>>
>>> PA can check whether it's a user-defined control or not.
>>
>> Would that be safe - I mean, can't there be user-defined controls PA
>> *should* care about?
> 
> It depends on the driver implementation, but as long as PA does
> software volume control by itself, and as long as the control elements
> are mixer elements, they can be ignored.

Interesting. I went looking into the snd_mixer_selem_* documentation (PA
uses the simple mixer interface), but I couldn't find a function for
determining whether a control is user-defined or not, would you mind
pointing me to it? Thanks!

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

Re: alsactl adds volume controls?

[Takashi Iwai]

At Thu, 02 Sep 2010 11:24:45 +0200,
David Henningsson wrote:
> 
> 2010-09-02 10:06, Takashi Iwai skrev:
> > At Wed, 01 Sep 2010 15:26:54 +0200,
> > David Henningsson wrote:
> >>
> >> 2010-08-30 15:08, Takashi Iwai skrev:
> >>> At Mon, 30 Aug 2010 15:01:29 +0200,
> >>> David Henningsson wrote:
> >>>>
> >>>> 2010-08-30 10:01, Takashi Iwai skrev:
> >>>>> At Sat, 28 Aug 2010 06:58:20 +0800,
> >>>>> Raymond Yau wrote:
> >>>>>>
> >>>>>> 2010/8/28 David Henningsson <david.henningsson@canonical.com>
> >>>>>>
> >>>>>>> 2010-08-27 17:43, Clemens Ladisch skrev:
> >>>>>>>> David Henningsson wrote:
> >>>>>>>>> So I've discovered that my sound card has a "PCM Playback Volume"
> >>>>>>>>> control, but changing that control does not alter the volume.
> >>>>>>>>>
> >>>>>>>>> Interestingly enough, this control does not come from the HDA parser, it
> >>>>>>>>> is added by alsactl at boot time...!
> >>>>>>>>
> >>>>>>>> This control was created by the software volume plugin.  When not using
> >>>>>>>> this plugin, the control does not have any effect.
> >>>>>>>>
> >>>>>>>> To get rid of it, delete its entry from /etc/asound.state.
> >>>>>>>
> >>>>>>> Hmm, I wonder if this is an Ubuntu-specific bug then? Because when I run
> >>>>>>> Maverick (the upcoming Ubuntu release) from a Live-CD, the "PCM Playback
> >>>>>>> Volume" control is still there (and there is no asound.state, neither in
> >>>>>>> /etc or in /var/lib/alsa).
> >>>>>>> When I use the plughw interface, the "PCM Playback Volume" does not
> >>>>>>> affect volume output. Should I use another device string to test the
> >>>>>>> softvol plugin, to see if it's there or not?
> >>>>>>
> >>>>>> The softvol plugin it is defined in "front" device in
> >>>>>> /usr/share/alsa/cards/HDA-Intel.conf
> >>>>>>
> >>>>>> reason is some HDA codec does not has any hardware volume control (analog)
> >>>>>>
> >>>>>> this user-defined control only effective when the application use "front"
> >>>>>> device
> >>>>>
> >>>>> Hm, but if PA opens the device with SND_PCM_NO_SOFTVOL flag, the
> >>>>> softvol should be skipped.
> >>>>
> >>>> But that does not apply to the mixer controls as well, does it?
> >>>
> >>> It does.  The mixer element is created when this kind of PCM stream is
> >>> opened without SND_PCM_NO_SOFTVOL flag.  Then it leaves the control
> >>> for the later use, and alsactl saves/restores it.  So, it's a chicken-
> >>> and-egg problem.
> >>
> >> Sounds a little strange to me. Thinking in general, if something is
> >> created when a stream is opened, that something should be destroyed when
> >> the stream is closed.
> > 
> > It's not about the stream-level volume.  It's about the global volume.
> > There have been bunch of machines that have no h/w volume control.
> > This is the mechanism for such environment.  You certainly don't want
> > to reset the system-level volume at each time you close the stream.
> 
> So if it's about the global volume it should be created on startup
> rather than when the stream is opened for the first time.

Ideally yes.  But pragmatically, no, it didn't work like that at that
time.  The change had to be seamless.

> >>> Of course, it's possible that it wasn't PA who opened the PCM stream.
> >>> But, something opened the stream and it created the mixer element.
> >>> This is the correct behavior.
> >>
> >> And once created, it stays there forever...
> > 
> > Not necessarily forever.  It's alsactl who saves/restores the element
> > 
> >> So even if PA does not
> >> create it, we'll just transform a persistent problem to an suddenly
> >> appearing problem?
> > 
> > Yes, it's just because you started an app that doesn't cope with PA.
> > And, it's PA who doesn't cope with softvol setup.  This is the
> > conflicting situation.
> 
> So as I understand it PA should call snd_pcm_open with the
> SND_PCM_NO_SOFTVOL, which it currently does not. It still puzzles me
> however how PA manages to open without that flag, which creates a mixer
> control, and later on that softvol control has no effect.

PA opens the "hw" device in general.  This skips the whole things.

> > Now the system doesn't know whether you'll start the non-PA app
> > again.  So, the volume has to be retained.
> > 
> >> Anyway, do we want softvol at all for HDA? Wouldn't that be such an
> >> unusual use case, that those people that can't adjust volume any other
> >> way, can add that softvol themselves in .asoundrc?
> > 
> > The softvol itself does nothing if the corresponding h/w volume
> > control exists.  It's activated only when the corresponding volume
> > element is unavailable.
> 
> Right, but I have a "Master" volume, a "Front" volume, "Headphone"
> volume and so on, so I have all the HW volumes I need, it's just that
> none of them happen to be labeled "PCM".

That's the problem.  The front playback stream is supposed to have
a PCM volume control.

> >>>> I think
> >>>> we still have a problem with PA assuming that it can change the PCM
> >>>> volume control to change the output volume.
> >>>
> >>> PA can check whether it's a user-defined control or not.
> >>
> >> Would that be safe - I mean, can't there be user-defined controls PA
> >> *should* care about?
> > 
> > It depends on the driver implementation, but as long as PA does
> > software volume control by itself, and as long as the control elements
> > are mixer elements, they can be ignored.
> 
> Interesting. I went looking into the snd_mixer_selem_* documentation (PA
> uses the simple mixer interface), but I couldn't find a function for
> determining whether a control is user-defined or not, would you mind
> pointing me to it? Thanks!

There seems no direct access from the mixer API.
But you can parse the mixer element to get hcontrol, then snd_ctl_elem
can be checked for its attribute.

Yeah, a new function could be added for controlling it.
Or, as an easier option, we can make snd_mixer_open() or
snd_ctl_open() for skipping the user-defined controls with some flag
like snd_pcm_open().


Takashi

Re: alsactl adds volume controls?

[Jaroslav Kysela]

On Thu, 2 Sep 2010, David Henningsson wrote:

> Interesting. I went looking into the snd_mixer_selem_* documentation (PA
> uses the simple mixer interface), but I couldn't find a function for
> determining whether a control is user-defined or not, would you mind
> pointing me to it? Thanks!

This logic is bad. We can have user-defined controls for the user space 
drivers or daemons.

The additional flag to mixer open functions - as proposed by Takashi - is 
more appropriate in this case when there is a system handling the software 
volume itself. But the question is quite same: How we can distinguish the 
software volume control? I think that some TLV information might do this 
job well.

 					Jaroslav

-----
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.

Re: alsactl adds volume controls?

[Clemens Ladisch]

Jaroslav Kysela wrote:
> On Thu, 2 Sep 2010, David Henningsson wrote:
> > Interesting. I went looking into the snd_mixer_selem_* documentation (PA
> > uses the simple mixer interface), but I couldn't find a function for
> > determining whether a control is user-defined or not, would you mind
> > pointing me to it? Thanks!
> 
> This logic is bad. We can have user-defined controls for the user space 
> drivers or daemons.
> 
> The additional flag to mixer open functions - as proposed by Takashi - is
> more appropriate in this case when there is a system handling the software
> volume itself. But the question is quite same: How we can distinguish the
> software volume control? I think that some TLV information might do this
> job well.

I think applications should not be required to distinguish software
controls.

The problem is that PA tries to use this control although it is inactive.
The obvious solution is that this control should be marked as inactive,
and that the softvol plugin marks it active only while actually running.

What is the reason for alsactl not trying to restore inactive controls?


Regards,
Clemens

Re: alsactl adds volume controls?

[Jaroslav Kysela]

On Thu, 2 Sep 2010, Clemens Ladisch wrote:

> Jaroslav Kysela wrote:
>> On Thu, 2 Sep 2010, David Henningsson wrote:
>>> Interesting. I went looking into the snd_mixer_selem_* documentation (PA
>>> uses the simple mixer interface), but I couldn't find a function for
>>> determining whether a control is user-defined or not, would you mind
>>> pointing me to it? Thanks!
>>
>> This logic is bad. We can have user-defined controls for the user space
>> drivers or daemons.
>>
>> The additional flag to mixer open functions - as proposed by Takashi - is
>> more appropriate in this case when there is a system handling the software
>> volume itself. But the question is quite same: How we can distinguish the
>> software volume control? I think that some TLV information might do this
>> job well.
>
> I think applications should not be required to distinguish software
> controls.
>
> The problem is that PA tries to use this control although it is inactive.
> The obvious solution is that this control should be marked as inactive,
> and that the softvol plugin marks it active only while actually running.

It's nice idea.

> What is the reason for alsactl not trying to restore inactive controls?

Most (maybe all - need to check drivers) of inactive control values are 
reset to the original value when they're going to the active state. Maybe 
we need to add another flag - inactive but persistent.

 						Jaroslav

-----
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.

Re: alsactl adds volume controls?

[Clemens Ladisch]

Jaroslav Kysela wrote:
> On Thu, 2 Sep 2010, Clemens Ladisch wrote:
> > What is the reason for alsactl not trying to restore inactive controls?
> 
> Most (maybe all - need to check drivers) of inactive control values are
> reset to the original value when they're going to the active state.

(There are both kinds of inactive controls.)

It wouldn't hurt to restore controls that will be reset later.

> Maybe we need to add another flag - inactive but persistent.

This is more or less implied by the current documentation:
/* control does actually nothing, but may be updated */

I'd rather add a flag for controls that will be reset by the driver,
because this is an action that is done in addition to the 'normal'
control behaviour.

One could also say that inactive controls that will be reset have a
value only as long as they are active, i.e., while inactive, there is
no current value.  In other words, while inactive, they should be
neither readable nor writable.  (Hmm, one could make them just readonly
to avoid problems due to unexpected error codes in mixer applications,
but the last value that it had before becoming inactive isn't likely to
be interesting to anyone.)


Regards,
Clemens

Re: alsactl adds volume controls?

[Jaroslav Kysela]

On Thu, 2 Sep 2010, Clemens Ladisch wrote:

> Jaroslav Kysela wrote:
>> On Thu, 2 Sep 2010, Clemens Ladisch wrote:
>>> What is the reason for alsactl not trying to restore inactive controls?
>>
>> Most (maybe all - need to check drivers) of inactive control values are
>> reset to the original value when they're going to the active state.
>
> (There are both kinds of inactive controls.)
>
> It wouldn't hurt to restore controls that will be reset later.
>
>> Maybe we need to add another flag - inactive but persistent.
>
> This is more or less implied by the current documentation:
> /* control does actually nothing, but may be updated */
>
> I'd rather add a flag for controls that will be reset by the driver,
> because this is an action that is done in addition to the 'normal'
> control behaviour.
>
> One could also say that inactive controls that will be reset have a
> value only as long as they are active, i.e., while inactive, there is
> no current value.  In other words, while inactive, they should be
> neither readable nor writable.  (Hmm, one could make them just readonly

Another good idea.

> to avoid problems due to unexpected error codes in mixer applications,
> but the last value that it had before becoming inactive isn't likely to
> be interesting to anyone.)

The read only value can be used with a monitoring application to set the 
original value back for a reason.

 						Jaroslav

-----
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.

Re: alsactl adds volume controls?

[Sebastian H.]

Am 02.09.2010 19:28, schrieb Jaroslav Kysela:
> On Thu, 2 Sep 2010, Clemens Ladisch wrote:
> 
>> Jaroslav Kysela wrote:
>>> On Thu, 2 Sep 2010, Clemens Ladisch wrote:
>>>> What is the reason for alsactl not trying to restore inactive controls?
>>>
>>> Most (maybe all - need to check drivers) of inactive control values are
>>> reset to the original value when they're going to the active state.
>>
>> (There are both kinds of inactive controls.)
>>
>> It wouldn't hurt to restore controls that will be reset later.
>>
>>> Maybe we need to add another flag - inactive but persistent.
>>
>> This is more or less implied by the current documentation:
>> /* control does actually nothing, but may be updated */
>>
>> I'd rather add a flag for controls that will be reset by the driver,
>> because this is an action that is done in addition to the 'normal'
>> control behaviour.
>>
>> One could also say that inactive controls that will be reset have a
>> value only as long as they are active, i.e., while inactive, there is
>> no current value.  In other words, while inactive, they should be
>> neither readable nor writable.  (Hmm, one could make them just readonly
> 
> Another good idea.
> 
>> to avoid problems due to unexpected error codes in mixer applications,
>> but the last value that it had before becoming inactive isn't likely to
>> be interesting to anyone.)
> 
> The read only value can be used with a monitoring application to set the 
> original value back for a reason.
> 

Hello
(this may be a bit off topic)

Working on the alsamixer-qt4 application I found that something like
snd_mixer_selem_is_writable ( ... )
or
snd_mixer_selem_is_readable ( ... )
would be quite useful.

E.g. there are elements like "Equalizer Peaks"
or there could be elements like "Headphones plugged in"
that are only meant to be read.
But right now there's no way to tell from the snd_mixer_selem_* API
if an element/channel is read-only.
In alsamixer-qt4 this can cause floods of error messages
when a GUI-Widget tries to write to such an element.

Thinking of "Equalizer Peaks" also something like
snd_mixer_selem_needs_poll ( ... )
or maybe
snd_mixer_selem_is_volatile ( ... )
would be interesting to know about for a mixer application.

My two cents for a snd_mixer_selem_* wishlist ;-)

Regards,
Sebastian H.

Re: alsactl adds volume controls?

[David Henningsson]

2010-09-02 11:44, Takashi Iwai skrev:
> At Thu, 02 Sep 2010 11:24:45 +0200,
> David Henningsson wrote:
>>
>> 2010-09-02 10:06, Takashi Iwai skrev:
>>> At Wed, 01 Sep 2010 15:26:54 +0200,
>>> David Henningsson wrote:
>>>>
>>>> 2010-08-30 15:08, Takashi Iwai skrev:
>>>>> At Mon, 30 Aug 2010 15:01:29 +0200,
>>>>> David Henningsson wrote:
>>>>>>
>>>>>> 2010-08-30 10:01, Takashi Iwai skrev:
>>>>>>> At Sat, 28 Aug 2010 06:58:20 +0800,
>>>>>>> Raymond Yau wrote:
>>>>>>>>
>>>>>>>> 2010/8/28 David Henningsson <david.henningsson@canonical.com>
>>>>>>>>
>>>>>>>>> 2010-08-27 17:43, Clemens Ladisch skrev:
>>>>>>>>>> David Henningsson wrote:
>>>>>>>>>>> So I've discovered that my sound card has a "PCM Playback Volume"
>>>>>>>>>>> control, but changing that control does not alter the volume.
>>>>>>>>>>>
>>>>>>>>>>> Interestingly enough, this control does not come from the HDA parser, it
>>>>>>>>>>> is added by alsactl at boot time...!
>>>>>>>>>>
>>>>>>>>>> This control was created by the software volume plugin.  When not using
>>>>>>>>>> this plugin, the control does not have any effect.
>>>>>>>>>>
>>>>>>>>>> To get rid of it, delete its entry from /etc/asound.state.
>>>>>>>>>
>>>>>>>>> Hmm, I wonder if this is an Ubuntu-specific bug then? Because when I run
>>>>>>>>> Maverick (the upcoming Ubuntu release) from a Live-CD, the "PCM Playback
>>>>>>>>> Volume" control is still there (and there is no asound.state, neither in
>>>>>>>>> /etc or in /var/lib/alsa).
>>>>>>>>> When I use the plughw interface, the "PCM Playback Volume" does not
>>>>>>>>> affect volume output. Should I use another device string to test the
>>>>>>>>> softvol plugin, to see if it's there or not?
>>>>>>>>
>>>>>>>> The softvol plugin it is defined in "front" device in
>>>>>>>> /usr/share/alsa/cards/HDA-Intel.conf
>>>>>>>>
>>>>>>>> reason is some HDA codec does not has any hardware volume control (analog)
>>>>>>>>
>>>>>>>> this user-defined control only effective when the application use "front"
>>>>>>>> device
>>>>>>>
>>>>>>> Hm, but if PA opens the device with SND_PCM_NO_SOFTVOL flag, the
>>>>>>> softvol should be skipped.
>>>>>>
>>>>>> But that does not apply to the mixer controls as well, does it?
>>>>>
>>>>> It does.  The mixer element is created when this kind of PCM stream is
>>>>> opened without SND_PCM_NO_SOFTVOL flag.  Then it leaves the control
>>>>> for the later use, and alsactl saves/restores it.  So, it's a chicken-
>>>>> and-egg problem.
>>>>
>>>> Sounds a little strange to me. Thinking in general, if something is
>>>> created when a stream is opened, that something should be destroyed when
>>>> the stream is closed.
>>>
>>> It's not about the stream-level volume.  It's about the global volume.
>>> There have been bunch of machines that have no h/w volume control.
>>> This is the mechanism for such environment.  You certainly don't want
>>> to reset the system-level volume at each time you close the stream.
>>
>> So if it's about the global volume it should be created on startup
>> rather than when the stream is opened for the first time.
> 
> Ideally yes.  But pragmatically, no, it didn't work like that at that
> time.  The change had to be seamless.
> 
>>>>> Of course, it's possible that it wasn't PA who opened the PCM stream.
>>>>> But, something opened the stream and it created the mixer element.
>>>>> This is the correct behavior.
>>>>
>>>> And once created, it stays there forever...
>>>
>>> Not necessarily forever.  It's alsactl who saves/restores the element
>>>
>>>> So even if PA does not
>>>> create it, we'll just transform a persistent problem to an suddenly
>>>> appearing problem?
>>>
>>> Yes, it's just because you started an app that doesn't cope with PA.
>>> And, it's PA who doesn't cope with softvol setup.  This is the
>>> conflicting situation.
>>
>> So as I understand it PA should call snd_pcm_open with the
>> SND_PCM_NO_SOFTVOL, which it currently does not. It still puzzles me
>> however how PA manages to open without that flag, which creates a mixer
>> control, and later on that softvol control has no effect.
> 
> PA opens the "hw" device in general.  This skips the whole things.

Right, so it tries both, which has the side effect of creating a volume
control, and then prefers hw.

>>> Now the system doesn't know whether you'll start the non-PA app
>>> again.  So, the volume has to be retained.
>>>
>>>> Anyway, do we want softvol at all for HDA? Wouldn't that be such an
>>>> unusual use case, that those people that can't adjust volume any other
>>>> way, can add that softvol themselves in .asoundrc?
>>>
>>> The softvol itself does nothing if the corresponding h/w volume
>>> control exists.  It's activated only when the corresponding volume
>>> element is unavailable.
>>
>> Right, but I have a "Master" volume, a "Front" volume, "Headphone"
>> volume and so on, so I have all the HW volumes I need, it's just that
>> none of them happen to be labeled "PCM".
> 
> That's the problem.  The front playback stream is supposed to have
> a PCM volume control.

May I kindly ask you to reconsider that statement? AFAIK, for Realtek
chips it is more common not to have a PCM volume control (and I haven't
checked the rest). So that would mean we have tons of bugs in the HDA
driver(s).

So, this softvol is only useful if all these three conditions are met:

1) you're opening "front:x" (or the "surround:x" variants), not
"plughw:x", "hw:x", "default:x", "dmix:x" or anything else.

2) you have no playback volume what so ever

3) you're not using PA or another sound server with its own software
volume mechanism

And so far I haven't came across a single HDA that fulfills condition
2), and I find the combination even more unlikely, but YMMV.

>>>>>> I think
>>>>>> we still have a problem with PA assuming that it can change the PCM
>>>>>> volume control to change the output volume.
>>>>>
>>>>> PA can check whether it's a user-defined control or not.
>>>>
>>>> Would that be safe - I mean, can't there be user-defined controls PA
>>>> *should* care about?
>>>
>>> It depends on the driver implementation, but as long as PA does
>>> software volume control by itself, and as long as the control elements
>>> are mixer elements, they can be ignored.
>>
>> Interesting. I went looking into the snd_mixer_selem_* documentation (PA
>> uses the simple mixer interface), but I couldn't find a function for
>> determining whether a control is user-defined or not, would you mind
>> pointing me to it? Thanks!
> 
> There seems no direct access from the mixer API.
> But you can parse the mixer element to get hcontrol, then snd_ctl_elem
> can be checked for its attribute.
> 
> Yeah, a new function could be added for controlling it.
> Or, as an easier option, we can make snd_mixer_open() or
> snd_ctl_open() for skipping the user-defined controls with some flag
> like snd_pcm_open().

What would be really helpful would be if snd_mixer_open() took an
optional pcm handle, and then only returned the mixer controls that
affects the signal path of that pcm.

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

Re: alsactl adds volume controls?

[Jaroslav Kysela]

On Fri, 3 Sep 2010, David Henningsson wrote:

> What would be really helpful would be if snd_mixer_open() took an
> optional pcm handle, and then only returned the mixer controls that
> affects the signal path of that pcm.

This will be solved by another mechanism like ucm (use case manager). The 
idea is to return the PCM handle and associated mixer controls (master + 
pcm) for specified use case (like hdmi output etc.).

 					Jaroslav

-----
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.

Re: alsactl adds volume controls?

[Raymond Yau]

2010/9/3 David Henningsson <david.henningsson@canonical.com>

> 2010-09-02 11:44, Takashi Iwai skrev:
> > At Thu, 02 Sep 2010 11:24:45 +0200,
> > David Henningsson wrote:
> >>
> >> 2010-09-02 10:06, Takashi Iwai skrev:
> >>> At Wed, 01 Sep 2010 15:26:54 +0200,
> >>> David Henningsson wrote:
> >>>>
> >>>> 2010-08-30 15:08, Takashi Iwai skrev:
> >>>>> At Mon, 30 Aug 2010 15:01:29 +0200,
> >>>>> David Henningsson wrote:
> >>>>>>
> >>>>>> 2010-08-30 10:01, Takashi Iwai skrev:
> >>>>>>> At Sat, 28 Aug 2010 06:58:20 +0800,
> >>>>>>> Raymond Yau wrote:
> >>>>>>>>
> >>>>>>>> 2010/8/28 David Henningsson <david.henningsson@canonical.com>
> >>>>>>>>
> >>>>>>>>> 2010-08-27 17:43, Clemens Ladisch skrev:
> >>>>>>>>>> David Henningsson wrote:
> >>>>>>>>>>> So I've discovered that my sound card has a "PCM Playback
> Volume"
> >>>>>>>>>>> control, but changing that control does not alter the volume.
> >>>>>>>>>>>
> >>>>>>>>>>> Interestingly enough, this control does not come from the HDA
> parser, it
> >>>>>>>>>>> is added by alsactl at boot time...!
> >>>>>>>>>>
> >>>>>>>>>> This control was created by the software volume plugin.  When
> not using
> >>>>>>>>>> this plugin, the control does not have any effect.
> >>>>>>>>>>
> >>>>>>>>>> To get rid of it, delete its entry from /etc/asound.state.
> >>>>>>>>>
> >>>>>>>>> Hmm, I wonder if this is an Ubuntu-specific bug then? Because
> when I run
> >>>>>>>>> Maverick (the upcoming Ubuntu release) from a Live-CD, the "PCM
> Playback
> >>>>>>>>> Volume" control is still there (and there is no asound.state,
> neither in
> >>>>>>>>> /etc or in /var/lib/alsa).
> >>>>>>>>> When I use the plughw interface, the "PCM Playback Volume" does
> not
> >>>>>>>>> affect volume output. Should I use another device string to test
> the
> >>>>>>>>> softvol plugin, to see if it's there or not?
> >>>>>>>>
> >>>>>>>> The softvol plugin it is defined in "front" device in
> >>>>>>>> /usr/share/alsa/cards/HDA-Intel.conf
> >>>>>>>>
> >>>>>>>> reason is some HDA codec does not has any hardware volume control
> (analog)
> >>>>>>>>
> >>>>>>>> this user-defined control only effective when the application use
> "front"
> >>>>>>>> device
> >>>>>>>
> >>>>>>> Hm, but if PA opens the device with SND_PCM_NO_SOFTVOL flag, the
> >>>>>>> softvol should be skipped.
> >>>>>>
> >>>>>> But that does not apply to the mixer controls as well, does it?
> >>>>>
> >>>>> It does.  The mixer element is created when this kind of PCM stream
> is
> >>>>> opened without SND_PCM_NO_SOFTVOL flag.  Then it leaves the control
> >>>>> for the later use, and alsactl saves/restores it.  So, it's a
> chicken-
> >>>>> and-egg problem.
> >>>>
> >>>> Sounds a little strange to me. Thinking in general, if something is
> >>>> created when a stream is opened, that something should be destroyed
> when
> >>>> the stream is closed.
> >>>
> >>> It's not about the stream-level volume.  It's about the global volume.
> >>> There have been bunch of machines that have no h/w volume control.
> >>> This is the mechanism for such environment.  You certainly don't want
> >>> to reset the system-level volume at each time you close the stream.
> >>
> >> So if it's about the global volume it should be created on startup
> >> rather than when the stream is opened for the first time.
> >
> > Ideally yes.  But pragmatically, no, it didn't work like that at that
> > time.  The change had to be seamless.
> >
> >>>>> Of course, it's possible that it wasn't PA who opened the PCM stream.
> >>>>> But, something opened the stream and it created the mixer element.
> >>>>> This is the correct behavior.
> >>>>
> >>>> And once created, it stays there forever...
> >>>
> >>> Not necessarily forever.  It's alsactl who saves/restores the element
> >>>
> >>>> So even if PA does not
> >>>> create it, we'll just transform a persistent problem to an suddenly
> >>>> appearing problem?
> >>>
> >>> Yes, it's just because you started an app that doesn't cope with PA.
> >>> And, it's PA who doesn't cope with softvol setup.  This is the
> >>> conflicting situation.
> >>
> >> So as I understand it PA should call snd_pcm_open with the
> >> SND_PCM_NO_SOFTVOL, which it currently does not. It still puzzles me
> >> however how PA manages to open without that flag, which creates a mixer
> >> control, and later on that softvol control has no effect.
> >
> > PA opens the "hw" device in general.  This skips the whole things.
>
> Right, so it tries both, which has the side effect of creating a volume
> control, and then prefers hw.
>
> >>> Now the system doesn't know whether you'll start the non-PA app
> >>> again.  So, the volume has to be retained.
> >>>
> >>>> Anyway, do we want softvol at all for HDA? Wouldn't that be such an
> >>>> unusual use case, that those people that can't adjust volume any other
> >>>> way, can add that softvol themselves in .asoundrc?
> >>>
> >>> The softvol itself does nothing if the corresponding h/w volume
> >>> control exists.  It's activated only when the corresponding volume
> >>> element is unavailable.
> >>
> >> Right, but I have a "Master" volume, a "Front" volume, "Headphone"
> >> volume and so on, so I have all the HW volumes I need, it's just that
> >> none of them happen to be labeled "PCM".
> >
> > That's the problem.  The front playback stream is supposed to have
> > a PCM volume control.
>
> May I kindly ask you to reconsider that statement? AFAIK, for Realtek
> chips it is more common not to have a PCM volume control (and I haven't
> checked the rest). So that would mean we have tons of bugs in the HDA
> driver(s).
>
> So, this softvol is only useful if all these three conditions are met:
>
> 1) you're opening "front:x" (or the "surround:x" variants), not
> "plughw:x", "hw:x", "default:x", "dmix:x" or anything else.
>
> 2) you have no playback volume what so ever
>
> 3) you're not using PA or another sound server with its own software
> volume mechanism
>
> And so far I haven't came across a single HDA that fulfills condition
> 2), and I find the combination even more unlikely, but YMMV.
>
> >>>>>> I think
> >>>>>> we still have a problem with PA assuming that it can change the PCM
> >>>>>> volume control to change the output volume.
> >>>>>
> >>>>> PA can check whether it's a user-defined control or not.
> >>>>
> >>>> Would that be safe - I mean, can't there be user-defined controls PA
> >>>> *should* care about?
> >>>
> >>> It depends on the driver implementation, but as long as PA does
> >>> software volume control by itself, and as long as the control elements
> >>> are mixer elements, they can be ignored.
> >>
> >> Interesting. I went looking into the snd_mixer_selem_* documentation (PA
> >> uses the simple mixer interface), but I couldn't find a function for
> >> determining whether a control is user-defined or not, would you mind
> >> pointing me to it? Thanks!
> >
> > There seems no direct access from the mixer API.
> > But you can parse the mixer element to get hcontrol, then snd_ctl_elem
> > can be checked for its attribute.
> >
> > Yeah, a new function could be added for controlling it.
> > Or, as an easier option, we can make snd_mixer_open() or
> > snd_ctl_open() for skipping the user-defined controls with some flag
> > like snd_pcm_open().
>
> What would be really helpful would be if snd_mixer_open() took an
> optional pcm handle, and then only returned the mixer controls that
> affects the signal path of that pcm.
>

The major problem is PA open "front" by both playback and capture

PA should not open "front" for capture

The softvol plugin should check the slave pcm (playback/capture) match with
the name of the control (Playback Volume/ Capture Volume)

There is one control in the alsamixer , but it is unclear that it control
both streams or only the recent stream


I: module-alsa-sink.c: Using 2 fragments of size 32768 bytes, buffer time is
371.52ms
I: module-alsa-sink.c: Time scheduling watermark is 20.00ms
D: module-alsa-sink.c: hwbuf_unused_frames=0
D: module-alsa-sink.c: setting avail_min=62005
I: module-alsa-sink.c: Volume ranges from 0 to 39.
I: module-alsa-sink.c: Volume ranges from -58.50 dB to 0.00 dB.
I: alsa-util.c: ALSA device lacks independant volume controls for each
channel.
I: module-alsa-sink.c: Using hardware volume control. Hardware dB scale
supported.
D: alsa-util.c: snd_pcm_dump():
D: alsa-util.c: Soft volume PCM
D: alsa-util.c: Control: PCM Playback Volume
D: alsa-util.c: min_dB: -51
D: alsa-util.c: max_dB: 0
D: alsa-util.c: resolution: 256
D: alsa-util.c: Its setup is:
D: alsa-util.c:   stream       : PLAYBACK
D: alsa-util.c:   access       : MMAP_INTERLEAVED
D: alsa-util.c:   format       : S16_LE
D: alsa-util.c:   subformat    : STD
D: alsa-util.c:   channels     : 2
D: alsa-util.c:   rate         : 44100
D: alsa-util.c:   exact rate   : 44100 (44100/1)
D: alsa-util.c:   msbits       : 16
D: alsa-util.c:   buffer_size  : 16384
D: alsa-util.c:   period_size  : 8192
D: alsa-util.c:   period_time  : 185759
D: alsa-util.c:   tstamp_mode  : NONE
D: alsa-util.c:   period_step  : 1
D: alsa-util.c:   avail_min    : 62005
D: alsa-util.c:   period_event : 0
D: alsa-util.c:   start_threshold  : -1
D: alsa-util.c:   stop_threshold   : -1
D: alsa-util.c:   silence_threshold: 0
D: alsa-util.c:   silence_size : 0
D: alsa-util.c:   boundary     : 1073741824
D: alsa-util.c: Slave: Hardware PCM card 1 'HDA Intel' device 0 subdevice 0
D: alsa-util.c: Its setup is:
D: alsa-util.c:   stream       : PLAYBACK
D: alsa-util.c:   access       : MMAP_INTERLEAVED
D: alsa-util.c:   format       : S16_LE
D: alsa-util.c:   subformat    : STD
D: alsa-util.c:   channels     : 2
D: alsa-util.c:   rate         : 44100
D: alsa-util.c:   exact rate   : 44100 (44100/1)
D: alsa-util.c:   msbits       : 16
D: alsa-util.c:   buffer_size  : 16384
D: alsa-util.c:   period_size  : 8192
D: alsa-util.c:   period_time  : 185759
D: alsa-util.c:   tstamp_mode  : NONE
D: alsa-util.c:   period_step  : 1
D: alsa-util.c:   avail_min    : 62005
D: alsa-util.c:   period_event : 0
D: alsa-util.c:   start_thresh
D: module-alsa-sink.c: Read hardware volume: 0: 100% 1: 100%
D: module-alsa-sink.c: Thread starting up
D: rtpoll.c: Acquired POSIX realtime signal SIGRTMIN+27
I: module-alsa-sink.c: Starting playback.
I: module.c: Loaded "module-alsa-sink" (index: #2; argument: "device_id=1
sink_name=alsa_output.pci_8086_284b_sound_card_0_alsa_playback_0 tsched=1").
D: module-hal-detect.c: Loading module-alsa-source with arguments
'device_id=1
source_name=alsa_input.pci_8086_284b_sound_card_0_alsa_capture_0 tsched=1'
D: alsa-util.c: Trying front:1 with SND_PCM_NO_AUTO_FORMAT ...
D: alsa-util.c: Maximum hw buffer size is 371 ms
I: module-alsa-source.c: Successfully opened device front:1.
I: module-alsa-source.c: Successfully enabled mmap() mode.
I: module-alsa-source.c: Successfully enabled timer-based scheduling mode.
I: (alsa-lib)control.c: Invalid CTL front:1
I: alsa-util.c: Unable to attach to mixer front:1: No such file or directory
I: alsa-util.c: Successfully attached to mixer 'hw:1'
I: alsa-util.c: Using mixer control "Capture".
I: source.c: Created source 3
"alsa_input.pci_8086_284b_sound_card_0_alsa_capture_0" with sample spec
s16le 2ch 44100Hz and channel map front-left,front-right
I: module-alsa-source.c: Using 2 fragments of size 32768 bytes, buffer time
is 371.52ms
I: module-alsa-source.c: Time scheduling watermark is 20.00ms
D: module-alsa-source.c: hwbuf_unused_frames=0
D: module-alsa-source.c: setting avail_min=62005
I: module-alsa-source.c: Volume ranges from 0 to 54.
I: module-alsa-source.c: Volume ranges from -58.50 dB to 22.50 dB.
I: alsa-util.c: All 2 channels can be mapped to mixer channels.
I: module-alsa-source.c: Using hardware volume control. Hardware dB scale
supported.
D: alsa-util.c: snd_pcm_dump():
D: alsa-util.c: Soft volume PCM
D: alsa-util.c: Control: PCM Playback Volume
D: alsa-util.c: min_dB: -51
D: alsa-util.c: max_dB: 0
D: alsa-util.c: resolution: 256
D: alsa-util.c: Its setup is:
D: alsa-util.c:   stream       : CAPTURE
D: alsa-util.c:   access       : MMAP_INTERLEAVED
D: alsa-util.c:   format       : S16_LE
D: alsa-util.c:   subformat    : STD
D: alsa-util.c:   channels     : 2
D: alsa-util.c:   rate         : 44100
D: alsa-util.c:   exact rate   : 44100 (44100/1)
D: alsa-util.c:   msbits       : 16
D: alsa-util.c:   buffer_size  : 16384
D: alsa-util.c:   period_size  : 8192
D: alsa-util.c:   period_time  : 185759
D: alsa-util.c:   tstamp_mode  : NONE
D: alsa-util.c:   period_step  : 1
D: alsa-util.c:   avail_min    : 62005
D: alsa-util.c:   period_event : 0
D: alsa-util.c:   start_threshold  : -1
D: alsa-util.c:   stop_threshold   : -1
D: alsa-util.c:   silence_threshold: 0
D: alsa-util.c:   silence_size : 0
D: alsa-util.c:   boundary     : 1073741824
D: alsa-util.c: Slave: Hardware PCM card 1 'HDA Intel' device 0 subdevice 0
D: alsa-util.c: Its setup is:
D: alsa-util.c:   stream       : CAPTURE
D: alsa-util.c:   access       : MMAP_INTERLEAVED
D: alsa-util.c:   format       : S16_LE
D: alsa-util.c:   subformat    : STD
D: alsa-util.c:   channels     : 2
D: alsa-util.c:   rate         : 44100
D: alsa-util.c:   exact rate   : 44100 (44100/1)
D: alsa-util.c:   msbits       : 16
D: alsa-util.c:   buffer_size  : 16384
D: alsa-util.c:   period_size  : 8192
D: alsa-util.c:   period_time  : 185759
D: alsa-util.c:   tstamp_mode  : NONE
D: alsa-util.c:   period_step  : 1
D: alsa-util.c:   avail_min    : 62005
D: alsa-util.c:   period_event : 0
D: alsa-util.c:   start_threshol
D: module-alsa-source.c: Read hardware volume: 0:  62% 1:  62%

Re: alsactl adds volume controls?

[Colin Guthrie]

Hi all,

I'm just re-kickstarting this thread after discussing this issue with
David on IRC.

'Twas brillig, and Jaroslav Kysela at 02/09/10 18:28 did gyre and gimble:
> On Thu, 2 Sep 2010, Clemens Ladisch wrote:
> 
>> Jaroslav Kysela wrote:
>>> On Thu, 2 Sep 2010, Clemens Ladisch wrote:
>>>> What is the reason for alsactl not trying to restore inactive controls?
>>>
>>> Most (maybe all - need to check drivers) of inactive control values are
>>> reset to the original value when they're going to the active state.
>>
>> (There are both kinds of inactive controls.)
>>
>> It wouldn't hurt to restore controls that will be reset later.
>>
>>> Maybe we need to add another flag - inactive but persistent.
>>
>> This is more or less implied by the current documentation:
>> /* control does actually nothing, but may be updated */
>>
>> I'd rather add a flag for controls that will be reset by the driver,
>> because this is an action that is done in addition to the 'normal'
>> control behaviour.
>>
>> One could also say that inactive controls that will be reset have a
>> value only as long as they are active, i.e., while inactive, there is
>> no current value.  In other words, while inactive, they should be
>> neither readable nor writable.  (Hmm, one could make them just readonly
> 
> Another good idea.

Ultimately there are a lot of ideas here on how to solve this, but I'd
also like to see something quite practical (new APIs etc. can be useful
but I'm still not quite understanding things as they work currently, so
perhaps my naive summary can provide some insight by being so out of
touch! (I live in hope!)).


>From what I understand:
 1. *All* HDA devices have a PCM softvol control. Some use this actively
due to the fact they lack a real h/w volume control. Others do not
technically "use" it.

 2. The PCM softvol has a 51dB range. When it's "active" this presumably
works. When it's inactive (which appears to be the case on my primary
machine), regardless of what the it's set to, there will be 0dB change.

 3. There is a flag when opening PCM device (SND_PCM_NO_SOFTVOL) that
will cause the PCM mixer to not have any impact in *all* cases rather
than just in the "inactive" case.

 4. When looking at only mixer elements (e.g. not opening any streams)
there is no way to know whether a given mixer is active or not (with
current APIs), i.e. From using only the mixer related API calls, the PCM
volume range is always presented as being 0 -> -51dB for the PCM
softvol, even when it actually has no effect (i.e. the information
presented is highly misleading).  Is there a way to know which mixers
are active when you open a pcm stream? (and this question applies to
both with and without using the SND_PCM_NO_SOFTVOL flag). I don't
personally know the API hence this newbie-level question.


Firstly, are all of the above statements correct? Have I fundamentally
misunderstood something?


Moving on, here are my observations about some of the comments on this
thread so far.

1. The point about opening "front" for both playback and capture in PA
is valid but irrelevant in this case. We are, for the moment, only
concerned about playback streams and ensuring that the mixers apparently
used to control the volume for that stream are accurate.

2. Using the UCM system to indicate whether a mixer element is relevant
or not is a potential nice solution in the future, but it's not
available now and it will also require that UCM metadata is available.
Perhaps some internal awareness of a mixer being "active" or not can
expose this UCM rule automatically? If that is not the case then it will
take years for static UCM metadata to be produced to fix this problem
and also years for alsa clients to actually use it (thankfully there are
not that many alsa clients what would *need* to make use of this -
mostly just PA and some independent mixer apps).

3. Using SND_PCM_NO_SOFTVOL at all times would mean we would have to
ignore all softvol mixer elements. It is perfectly possible to control
the mixer pipeline with no streams active. This could be a solution,
(i.e. using this flag at all times in PA, and ignore all softvol mixers)
but is it the right one?

I'm also not 100% sure about using this in PA. It was used back in 2008:

commit ff3f43525d0b528d43a0480d596973d07c920580
Author: Lennart Poettering <lennart@poettering.net>
Date:   Wed Jul 16 11:12:07 2008 +0200

    try to bypass alsa softvol, since it is broken when used with
snd_pcm_rewind()

but it was removed again in:

commit 1c4ad4b64be168d13a31c8147505b88967be4afb
Author: Lennart Poettering <lennart@poettering.net>
Date:   Sun Aug 31 16:25:37 2008 +0200

    rework device opening code: work around broken SND_PCM_NO_AUTO_xxx
support in ALSA <= 1.0.17a


I'm not 100% sure if this second commit intended to remove the
NO_SOFTVOL option of if it was simply removed in the wash accidentally.
I'll try and confirm with Lennart.



Potential solutions would include:
 1. If the "correct" solution is to just use SND_PCM_NO_AUTO in PA, and
then deliberately/actively ignore any softvol mixers, then nothing needs
done at the alsa level I guess.

 2. Simply fixing things to NOT add the inactive PCM mixer when it's not
needed. I'm not sure I actually understand why this isn't an option to
fix this problem but that generally seems to be the suggestion by those
in the know. I would rather this mixer was simply absent on my machine.

 3. Add an API to know whether a mixer element is active (IMO
is_writable() is insufficient. If the current value of PCM says it's set
to e.g. -28dB then we need to believe what it says. Even if we decide
not to write new values to PCM mixer, we have to believe what it says -
we is_writable() does not solve the overall problem of knowing the
ultimate product of the various attenuations in the pipeline).

 4. *Always* activate PCM softvol. I mean, why is it even inactive in
the first place? If it worked to provide "extra" attenuation in addition
to the Master (which is presumably h/w based) control in the cases where
softvol wasn't really needed, then it would not be lying about the dB
range it claims to support. David did suggest that by always activating
it, it would result in extra memory/copy (and thus power) overhead which
is a valid reason for not adopting this approach. It would however solve
the immediate problem of the lies the mixer current tells! Perhaps some
flag could be added to enable this by default but allow it to be turned
off when power-saving is of critical importance?

 5. Would it be possible to adjust the range reported by the softvol
plugin when it is inactive. e.g. could a an "active" PCM say "I offer
51dB range in 255" steps while an "inactive" one could say "I offer
0.1dB range in 1 step". PA could easily be patched to ignore a mixer
which has such a trivially low range.



I'm not sure how sensible any of the above suggestions, nor how accurate
the observations, but hopefully it'll be enough to kick start the
discussion again.

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

Re: alsactl adds volume controls?

[Mark Brown]

On Wed, Sep 29, 2010 at 03:26:38PM +0100, Colin Guthrie wrote:

> 2. Using the UCM system to indicate whether a mixer element is relevant
> or not is a potential nice solution in the future, but it's not
> available now and it will also require that UCM metadata is available.

...

>  3. Add an API to know whether a mixer element is active (IMO
> is_writable() is insufficient. If the current value of PCM says it's set
> to e.g. -28dB then we need to believe what it says. Even if we decide
> not to write new values to PCM mixer, we have to believe what it says -
> we is_writable() does not solve the overall problem of knowing the
> ultimate product of the various attenuations in the pipeline).

I think a new API is called for here - the basic problem we've got is
that while we do have a fairly good idea of how the controls are
conected to audio routes inside the kernel for HDA and for embedded
stuff we've no way of exposing this to the userspace applications.  This
is the root cause of a lot of the hassle here, we don't know which
controls are involved in a given audio path reliably and we don't know
if there are additional gain stages in the path.  I see this as separate
to the UCM thing with saying which control you should use for adjusting
a particular use case - UCM says "use this as your master volume for
headphone" or whatever which is separate to determining the total system
gain through the audio path.

There's some time in the LPC audio track discussion set aside for doing
some requirements gathering on this.

Re: alsactl adds volume controls?

[Raymond Yau]

2010/9/29 Colin Guthrie <gmane@colin.guthr.ie>

>
>
> From what I understand:
>  1. *All* HDA devices have a PCM softvol control. Some use this actively
> due to the fact they lack a real h/w volume control. Others do not
> technically "use" it.
>

If you disable pulseaudio in mandriva 2010  after a forced relogin by
mandrake center , it fall back to use dmix/dsnoop, so the softvol plugin
"PCM Playback Volume" and "Digital Capture Volume" are always used by any
application since they are defined in "default" device in HDA-Intel.conf

Re: alsactl adds volume controls?

[Clemens Ladisch]

Colin Guthrie wrote:
>  1. *All* HDA devices have a PCM softvol control.

The HDA "default" and "front" devices include the softvol plugin.
However, when the control already exists as a hardware control, the
plugin removes itself and isn't actually used (same as if the
SND_PCM_NO_SOFTVOL flag is set).

So, all HDA devices have a "PCM Playback Volume" control, either in
hardware or created by the softvol plugin.  (This control is absent
only when the softvol plugin has not been used.)

> Some use this actively due to the fact they lack a real h/w volume
> control. Others do not technically "use" it.

The hardware control is always used.  The user control created by
softvol is used when some application is using the softvol plugin.
(For an application using device names like "hw" or "plughw", there will
be not softvol plugin.)

>  2. The PCM softvol has a 51dB range. When it's "active" this presumably
> works. When it's inactive (which appears to be the case on my primary
> machine), regardless of what the it's set to, there will be 0dB change.

Yes.  (When using ALSA's default "default" or "front" devices, it should
be active.)

>  3. There is a flag when opening PCM device (SND_PCM_NO_SOFTVOL) that
> will cause the PCM mixer to not have any impact in *all* cases

... except when that control is a hardware control.

>  4. When looking at only mixer elements (e.g. not opening any streams)
> there is no way to know whether a given mixer is active or not (with
> current APIs), i.e. From using only the mixer related API calls, the PCM
> volume range is always presented as being 0 -> -51dB for the PCM
> softvol, even when it actually has no effect (i.e. the information
> presented is highly misleading).  Is there a way to know which mixers
> are active when you open a pcm stream? (and this question applies to
> both with and without using the SND_PCM_NO_SOFTVOL flag).

There is snd_ctl_elem_info_is_inactive(), but the softvol plugin never
sets its control to inactive.

Since there is only one global control, any property of this control is
not useful for applications like PA to determine whether its own stream
is being affected.

> Potential solutions would include:
>  1. If the "correct" solution is to just use SND_PCM_NO_AUTO in PA, and
> then deliberately/actively ignore any softvol mixers, then nothing needs
> done at the alsa level I guess.

Yes.

Use snd_ctl_elem_info_is_user() to check for the softvol mixer element.

>  2. Simply fixing things to NOT add the inactive PCM mixer when it's not
> needed.

It was decided to store this control in the hardware device so that it
is saved/restored together with the 'real' controls.


Regards,
Clemens

Re: alsactl adds volume controls?

[Colin Guthrie]

Hi,

Thanks for your reply as always Clemens.

'Twas brillig, and Clemens Ladisch at 30/09/10 12:03 did gyre and gimble:
> Colin Guthrie wrote:
>>  1. *All* HDA devices have a PCM softvol control.
> 
> The HDA "default" and "front" devices include the softvol plugin.
> However, when the control already exists as a hardware control, the
> plugin removes itself and isn't actually used (same as if the
> SND_PCM_NO_SOFTVOL flag is set).

Ahh OK, I think the problem is that David's test tool uses plughw device
rather than front... thus it does NOT use softvol (confirmed here
testing plughw and front) and thus the PCM softvol does not come into
play during the test cycle for me and thus it reports that the PCM
slider is totally incorrect with regards to it's dB values reported and
actual.

> So, all HDA devices have a "PCM Playback Volume" control, either in
> hardware or created by the softvol plugin.  (This control is absent
> only when the softvol plugin has not been used.)

I'll refer back to the above statement below[1].

>> Some use this actively due to the fact they lack a real h/w volume
>> control. Others do not technically "use" it.
> 
> The hardware control is always used.  The user control created by
> softvol is used when some application is using the softvol plugin.
> (For an application using device names like "hw" or "plughw", there will
> be not softvol plugin.)

OK. As pulse's mixer profiles *tries* to use "front" but will fall back
to "hw", we can be pretty much certain that the softvol plugin will
exist in all cases. The trick is knowing whether or not the control is
active.

>>  2. The PCM softvol has a 51dB range. When it's "active" this presumably
>> works. When it's inactive (which appears to be the case on my primary
>> machine), regardless of what the it's set to, there will be 0dB change.
> 
> Yes.  (When using ALSA's default "default" or "front" devices, it should
> be active.)

I've now confirmed that that is indeed the case for me. As PA opens the
front device for me, I can confirm that it does actually make an impact
(although the latency of updates is terrible for me when I adjust the
alsamixer. I guess changing PCM directly in alsamixer it doesn't trigger
an immediate rewind in PA so the buffer has to run out for the change to
be heard.

So currently, PCM does have impact in PA for me. Good. I confirmed that
making PA open the devices with the NO_SOFTVOL flag does indeed make it
non-functional. So far so good.

>>  3. There is a flag when opening PCM device (SND_PCM_NO_SOFTVOL) that
>> will cause the PCM mixer to not have any impact in *all* cases
> 
> ... except when that control is a hardware control.

Yes, of course. Sorry I should have included that :)

>>  4. When looking at only mixer elements (e.g. not opening any streams)
>> there is no way to know whether a given mixer is active or not (with
>> current APIs), i.e. From using only the mixer related API calls, the PCM
>> volume range is always presented as being 0 -> -51dB for the PCM
>> softvol, even when it actually has no effect (i.e. the information
>> presented is highly misleading).  Is there a way to know which mixers
>> are active when you open a pcm stream? (and this question applies to
>> both with and without using the SND_PCM_NO_SOFTVOL flag).
> 
> There is snd_ctl_elem_info_is_inactive(), but the softvol plugin never
> sets its control to inactive.
> 
> Since there is only one global control, any property of this control is
> not useful for applications like PA to determine whether its own stream
> is being affected.
> 
>> Potential solutions would include:
>>  1. If the "correct" solution is to just use SND_PCM_NO_AUTO in PA, and
>> then deliberately/actively ignore any softvol mixers, then nothing needs
>> done at the alsa level I guess.
> 
> Yes.
> 
> Use snd_ctl_elem_info_is_user() to check for the softvol mixer element.

Hmm, judging by the previous response to this suggestion, I'm not sure
this will work:

http://mailman.alsa-project.org/pipermail/alsa-devel/2007-December/004622.html

>>  2. Simply fixing things to NOT add the inactive PCM mixer when it's not
>> needed.
> 
> It was decided to store this control in the hardware device so that it
> is saved/restored together with the 'real' controls.

That as a principle makes sense but I still don't understand why it has
to be there when it's not active. I guess it's an implementation detail,
but from the outside, this doesn't look like a reason.

Also I said I'd refer back to [1] later, so here it is. I'm a little
confused as to why it's stored in asound.state, if, as you say, the
control is only created when something opens "front:" or similar. When
the asound.state is read and restored during boot (this is the only time
for 99% of users I believe - other than running it manually), would it
not be the case that nothing has yet opened "front:" and thus it will
not be restored? If that is the case then there is no reason to store it
in the asound.state. Of course if it is in asound.state then maybe that
is enough to create it for you at boot without opening "front:"?




Anyway, with all this in mind, the main problem I have now is not that
PA uses the softvols (I'm tending to side with the argument that it
*shouldn't* use them, but at present it does and they *are* active and
used, so it's not an issue for me), the problem is rather one of setting
Master (not PCM) to 0% aka -46.5dB causes some kind of auto-mute that
cuts off all sound. It shouldn't do that. I've not muted it. I've set it
to -46.5dB but it's decided to make it -infdB instead. That IMO is the
primary bug I'm seeing (and it's one I brought up on this list several
months ago, but managed to get sidetracked by Raymond talking about a
-48dB == -inf debate with no real action on the problem :()

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

Re: alsactl adds volume controls?

[Clemens Ladisch]

Colin Guthrie wrote:
> 'Twas brillig, and Clemens Ladisch at 30/09/10 12:03 did gyre and gimble:
>> Colin Guthrie wrote:

>> The hardware control is always used.  The user control created by
>> softvol is used when some application is using the softvol plugin.
>> (For an application using device names like "hw" or "plughw", there will
>> be not softvol plugin.)
> 
> OK. As pulse's mixer profiles *tries* to use "front" but will fall back
> to "hw", we can be pretty much certain that the softvol plugin will
> exist in all cases. The trick is knowing whether or not the control is
> active.

used by current stream

> (although the latency of updates is terrible for me when I adjust the
> alsamixer. I guess changing PCM directly in alsamixer it doesn't trigger
> an immediate rewind in PA so the buffer has to run out for the change to
> be heard.

Yes.  The softvol plugin could be changed to try to update the already-
written part of the buffer; so far, not many programs have used big
buffers.

>>> Potential solutions would include:
>>>  1. If the "correct" solution is to just use SND_PCM_NO_AUTO in PA, and
>>> then deliberately/actively ignore any softvol mixers, then nothing needs
>>> done at the alsa level I guess.
>> 
>> Yes.
>> 
>> Use snd_ctl_elem_info_is_user() to check for the softvol mixer element.
> 
> Hmm, judging by the previous response to this suggestion, I'm not sure
> this will work:
> 
> http://mailman.alsa-project.org/pipermail/alsa-devel/2007-December/004622.html

It would have worked if PA used the snd_ctl_* instead of the snd_mixer_*
functions.

In this special case, we know that the snd_ctl control "Playback PCM
Volume" maps to the snd_mixer "PCM" playback volume, but this would
still be a hack.

>> It was decided to store this control in the hardware device so that it
>> is saved/restored together with the 'real' controls.
> 
> That as a principle makes sense but I still don't understand why it has
> to be there when it's not active.

So that it behaves like a 'real' control, i.e., you can set (and restore)
it even when nothing is currently playing.

> Also I said I'd refer back to [1] later, so here it is. I'm a little
> confused as to why it's stored in asound.state, if, as you say, the
> control is only created when something opens "front:" or similar. When
> the asound.state is read and restored during boot (this is the only time
> for 99% of users I believe - other than running it manually), would it
> not be the case that nothing has yet opened "front:" and thus it will
> not be restored?

When alsactl restores a user control, it will automatically create it.
Thus, using the softvol plugin creates this control practically
permamently.

> setting Master (not PCM) to 0% aka -46.5dB causes some kind of auto-
> mute that cuts off all sound. It shouldn't do that.

Wasn't this a hardware error?
The driver should report correct dB information for this chip.


Regards,
Clemens

Re: alsactl adds volume controls?

[Mark Brown]

On Thu, Sep 30, 2010 at 04:09:56PM +0100, Colin Guthrie wrote:

> *shouldn't* use them, but at present it does and they *are* active and
> used, so it's not an issue for me), the problem is rather one of setting
> Master (not PCM) to 0% aka -46.5dB causes some kind of auto-mute that
> cuts off all sound. It shouldn't do that. I've not muted it. I've set it

Is this perhaps just an error in the TLV information - should it be
flagging that the minimim gain is mute but isn't?

Re: alsactl adds volume controls?

[Takashi Iwai]

At Thu, 30 Sep 2010 17:47:53 +0100,
Mark Brown wrote:
> 
> On Thu, Sep 30, 2010 at 04:09:56PM +0100, Colin Guthrie wrote:
> 
> > *shouldn't* use them, but at present it does and they *are* active and
> > used, so it's not an issue for me), the problem is rather one of setting
> > Master (not PCM) to 0% aka -46.5dB causes some kind of auto-mute that
> > cuts off all sound. It shouldn't do that. I've not muted it. I've set it
> 
> Is this perhaps just an error in the TLV information - should it be
> flagging that the minimim gain is mute but isn't?

There is no clear (or consistent) definition in HD-audio codec, I guess.
Some chips do mute at 0 and some not.  The capability bit shows only
whether it can mute or not -- not about whether it mutes at zero.


Takashi

Re: alsactl adds volume controls?

[Colin Guthrie]

'Twas brillig, and Takashi Iwai at 30/09/10 19:09 did gyre and gimble:
> At Thu, 30 Sep 2010 17:47:53 +0100,
> Mark Brown wrote:
>>
>> On Thu, Sep 30, 2010 at 04:09:56PM +0100, Colin Guthrie wrote:
>>
>>> *shouldn't* use them, but at present it does and they *are* active and
>>> used, so it's not an issue for me), the problem is rather one of setting
>>> Master (not PCM) to 0% aka -46.5dB causes some kind of auto-mute that
>>> cuts off all sound. It shouldn't do that. I've not muted it. I've set it
>>
>> Is this perhaps just an error in the TLV information - should it be
>> flagging that the minimim gain is mute but isn't?
> 
> There is no clear (or consistent) definition in HD-audio codec, I guess.
> Some chips do mute at 0 and some not.  The capability bit shows only
> whether it can mute or not -- not about whether it mutes at zero.

Is there some way I can force this metadata into the driver of files for
my h/w in such a way that PA will pick up on it and thus work correctly?

Col



-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

Re: alsactl adds volume controls?

[Mark Brown]

On Thu, Sep 30, 2010 at 08:09:32PM +0200, Takashi Iwai wrote:
> Mark Brown wrote:

> > Is this perhaps just an error in the TLV information - should it be
> > flagging that the minimim gain is mute but isn't?

> There is no clear (or consistent) definition in HD-audio codec, I guess.

Oh, fail.  Of course, a sufficient attenuation is indistinguishable from
mute anyway which complicates matters a little.

Re: alsactl adds volume controls?

[Raymond Yau]

2010/10/1 Mark Brown <broonie@opensource.wolfsonmicro.com>

> On Thu, Sep 30, 2010 at 04:09:56PM +0100, Colin Guthrie wrote:
>
> > *shouldn't* use them, but at present it does and they *are* active and
> > used, so it's not an issue for me), the problem is rather one of setting
> > Master (not PCM) to 0% aka -46.5dB causes some kind of auto-mute that
> > cuts off all sound. It shouldn't do that. I've not muted it. I've set it
>
> Is this perhaps just an error in the TLV information - should it be
> flagging that the minimim gain is mute but isn't?
>


For hda codec , the amplifiers can be found at [Audio Output], [Audio Mixer]
and [Pin complex]

Also the codec specification define which step is 0dB  , number of step and
dB for each step

Some codec can even be connected to a hardware volume knob

It also explicitly define a mute switch, so I don't think there is reason to
assume the minimum dB value is equal to mute ( -infinite dB )

In this case, the driver seem need to make some adjustment when there is no
volume knob connected , you may need to find another user with the same
codec connected to a volume knob or peform some calibration to find out how
to make the adjustment

Re: alsactl adds volume controls?

[Clemens Ladisch]

Takashi Iwai wrote:
> Mark Brown wrote:
> > On Thu, Sep 30, 2010 at 04:09:56PM +0100, Colin Guthrie wrote:
> > > *shouldn't* use them, but at present it does and they *are* active and
> > > used, so it's not an issue for me), the problem is rather one of setting
> > > Master (not PCM) to 0% aka -46.5dB causes some kind of auto-mute that
> > > cuts off all sound. It shouldn't do that.
> > 
> > Is this perhaps just an error in the TLV information - should it be
> > flagging that the minimim gain is mute but isn't?
> 
> There is no clear (or consistent) definition in HD-audio codec, I guess.

The HDA spec is quite clear that muting is done only with the mute bit.

> Some chips do mute at 0 and some not.

Those that do are violating the specification.

But we have to support them anyway.
Colin, please tell us the IDs of your codec so that we can add a TLV
workaround to the driver.


Regards,
Clemens

Re: alsactl adds volume controls?

[Colin Guthrie]

'Twas brillig, and Clemens Ladisch at 01/10/10 07:44 did gyre and gimble:
> Takashi Iwai wrote:
>> Mark Brown wrote:
>>> On Thu, Sep 30, 2010 at 04:09:56PM +0100, Colin Guthrie wrote:
>>>> *shouldn't* use them, but at present it does and they *are* active and
>>>> used, so it's not an issue for me), the problem is rather one of setting
>>>> Master (not PCM) to 0% aka -46.5dB causes some kind of auto-mute that
>>>> cuts off all sound. It shouldn't do that.
>>>
>>> Is this perhaps just an error in the TLV information - should it be
>>> flagging that the minimim gain is mute but isn't?
>>
>> There is no clear (or consistent) definition in HD-audio codec, I guess.
> 
> The HDA spec is quite clear that muting is done only with the mute bit.

Good :)

>> Some chips do mute at 0 and some not.
> 
> Those that do are violating the specification.
> 
> But we have to support them anyway.
> Colin, please tell us the IDs of your codec so that we can add a TLV
> workaround to the driver.

I presume the alsa-info.sh output is sufficient here?

http://colin.guthr.ie/alsa-info.txt

snd_hda_intel   : Intel Corporation|82801G (ICH7 Family) High Definition
Audio Controller (vendor:8086 device:27d8 subv:1028 subd:01bd) (rev: 01)


Many thanks

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

Re: alsactl adds volume controls?

[Clemens Ladisch]

Colin Guthrie wrote:
> 'Twas brillig, and Clemens Ladisch at 01/10/10 07:44 did gyre and gimble:
> > Colin, please tell us the IDs of your codec so that we can add a TLV
> > workaround to the driver.
> 
> I presume the alsa-info.sh output is sufficient here?

| Codec: SigmaTel STAC9200
| Vendor Id: 0x83847690

Yes.

| Node 0x0b [Audio Selector] wcaps 0x300105: Stereo Amp-Out
|   Control: name="Master Playback Volume", index=0, device=0
|     ControlAmp: chs=3, dir=Out, idx=0, ofs=0
|   Control: name="Master Playback Switch", index=0, device=0
|     ControlAmp: chs=3, dir=Out, idx=0, ofs=0
|   Amp-Out caps: N/A

Is this still "N/A" when you try again?


Regards,
Clemens

Re: alsactl adds volume controls?

[Raymond Yau]

2010/9/3 Jaroslav Kysela <perex@perex.cz>

> On Fri, 3 Sep 2010, David Henningsson wrote:
>
> > What would be really helpful would be if snd_mixer_open() took an
> > optional pcm handle, and then only returned the mixer controls that
> > affects the signal path of that pcm.
>
> This will be solved by another mechanism like ucm (use case manager). The
> idea is to return the PCM handle and associated mixer controls (master +
> pcm) for specified use case (like hdmi output etc.).
>
>                                        Jaroslav
>
>
How about those [Volume Knob Widget] , can the driver read back the step or
dB of the volume knob from the codec ?


Node 0x24 [Volume Knob Widget] wcaps 0x600000: Mono
  Volume-Knob: delta=1, steps=127, direct=0, val=127
  Connection: 4
     0x02 0x03 0x04 0x05

Re: alsactl adds volume controls?

[Raymond Yau]

2010/9/29 Colin Guthrie <gmane@colin.guthr.ie>

>
> 1. The point about opening "front" for both playback and capture in PA
> is valid but irrelevant in this case. We are, for the moment, only
> concerned about playback streams and ensuring that the mixers apparently
> used to control the volume for that stream are accurate.
>


PA open "front" device for playback and capture is one of the reason why so
many user complain about recording volume is too low since the softvol
plugin in front device only provide atteunation

It is possible for softvol plugin to reject a capture stream to use a name
containing "Playback" or a playback stream to use a name containing
"Capture"



    if (resolution <= 1 || resolution > 1024) {
        SNDERR("Invalid resolution value %d", resolution);
        return -EINVAL;
    }
+    if ( strstr(name, ((stream == SND_PCM_STREAM_PLAYBACK) ? "Capture":
"Playback")) > 0 ) {
+        SNDERR("Invalid name %s for %s stream", name,
+        stream ==  SND_PCM_STREAM_PLAYBACK ? "Playback" : "Capture" );
+       return -EINVAL;
+     }
    if (mode & SND_PCM_NO_SOFTVOL) {
        err = snd_pcm_slave_conf(root, slave, &sconf, 0);
        if (err < 0)
            return err;
        err = snd_pcm_open_named_slave(pcmp, name, root, sconf, stream,
                           mode, conf);
        snd_config_delete(sconf);

Re: alsactl adds volume controls?

[Raymond Yau]

2010/10/1 Clemens Ladisch <clemens@ladisch.de>

> Takashi Iwai wrote:
> > Mark Brown wrote:
> > > On Thu, Sep 30, 2010 at 04:09:56PM +0100, Colin Guthrie wrote:
> > > > *shouldn't* use them, but at present it does and they *are* active
> and
> > > > used, so it's not an issue for me), the problem is rather one of
> setting
> > > > Master (not PCM) to 0% aka -46.5dB causes some kind of auto-mute that
> > > > cuts off all sound. It shouldn't do that.
> > >
> > > Is this perhaps just an error in the TLV information - should it be
> > > flagging that the minimim gain is mute but isn't?
> >
> > There is no clear (or consistent) definition in HD-audio codec, I guess.
>
> The HDA spec is quite clear that muting is done only with the mute bit.
>
> > Some chips do mute at 0 and some not.
>
> Those that do are violating the specification.
>
> But we have to support them anyway.
> Colin, please tell us the IDs of your codec so that we can add a TLV
> workaround to the driver.
>
>
> Regards,
> Clemens
>
>
Actually, the softvol plugin behave as the same way as Colin describe since
when the resolution is 2 , the softvol become a mute switch

http://git.alsa-project.org/?p=alsa-lib.git;a=commit;h=f78af4ab0412052aabb74c9122a8d8f3ab6d45e6

So the question is why -51dB is selected as min_dB

Is this value enough for S16_LE or  S32_LE for hda-intel ?

http://git.alsa-project.org/?p=alsa-kernel.git;a=commitdiff;h=eacbb9dba6b4c982a0217ea2c7d15db88d4fda37;hp=d91b424d6d7bda0773b6b6b606d48d089c4f5115

As those DACs support -120dB to 0dB , but the driver can actually limit the
dB range to -60dB to 0dB . so the minimum volume -60dB is definitly not mute
in this case

why -60dB is selected  ?

Re: alsactl adds volume controls?

[Colin Guthrie]

'Twas brillig, and Clemens Ladisch at 01/10/10 10:02 did gyre and gimble:
> | Node 0x0b [Audio Selector] wcaps 0x300105: Stereo Amp-Out
> |   Control: name="Master Playback Volume", index=0, device=0
> |     ControlAmp: chs=3, dir=Out, idx=0, ofs=0
> |   Control: name="Master Playback Switch", index=0, device=0
> |     ControlAmp: chs=3, dir=Out, idx=0, ofs=0
> |   Amp-Out caps: N/A
> 
> Is this still "N/A" when you try again?

Yeah, I've run the script a few times and this has always been N/A.



As a more general question, how is the quirk for fixing the 0==mute
thing added? Is it a kernel patch or some tweak in the /usr/share/alsa/
tree (i.e. alsalib based quirk?)

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

Re: alsactl adds volume controls?

[Colin Guthrie]

'Twas brillig, and Raymond Yau at 04/10/10 12:09 did gyre and gimble:
> 2010/10/1 Clemens Ladisch <clemens@ladisch.de>
> 
>> Takashi Iwai wrote:
>>> Mark Brown wrote:
>>>> On Thu, Sep 30, 2010 at 04:09:56PM +0100, Colin Guthrie wrote:
>>>>> *shouldn't* use them, but at present it does and they *are* active
>> and
>>>>> used, so it's not an issue for me), the problem is rather one of
>> setting
>>>>> Master (not PCM) to 0% aka -46.5dB causes some kind of auto-mute that
>>>>> cuts off all sound. It shouldn't do that.
>>>>
>>>> Is this perhaps just an error in the TLV information - should it be
>>>> flagging that the minimim gain is mute but isn't?
>>>
>>> There is no clear (or consistent) definition in HD-audio codec, I guess.
>>
>> The HDA spec is quite clear that muting is done only with the mute bit.
>>
>>> Some chips do mute at 0 and some not.
>>
>> Those that do are violating the specification.
>>
>> But we have to support them anyway.
>> Colin, please tell us the IDs of your codec so that we can add a TLV
>> workaround to the driver.
>>
>>
>> Regards,
>> Clemens
>>
>>
> Actually, the softvol plugin behave as the same way as Colin describe since
> when the resolution is 2 , the softvol become a mute switch
> 
> http://git.alsa-project.org/?p=alsa-lib.git;a=commit;h=f78af4ab0412052aabb74c9122a8d8f3ab6d45e6
> 
> So the question is why -51dB is selected as min_dB
> 
> Is this value enough for S16_LE or  S32_LE for hda-intel ?
> 
> http://git.alsa-project.org/?p=alsa-kernel.git;a=commitdiff;h=eacbb9dba6b4c982a0217ea2c7d15db88d4fda37;hp=d91b424d6d7bda0773b6b6b606d48d089c4f5115
> 
> As those DACs support -120dB to 0dB , but the driver can actually limit the
> dB range to -60dB to 0dB . so the minimum volume -60dB is definitly not mute
> in this case
> 
> why -60dB is selected  ?


Just for clarity, the 0 -> -51dB range is for the PCM control (i.e.
softvol) only. The Master control gives me -46.5dB in addtiion to that
giving a total of -97.5dB. This still isn't as high as the -120dB you
are mentioning, but it's a lot closer.

Of course I am lucky in that my Master apparently works fine but for
those souls without any Master control, I presume the full range should
be offered by the PCM softvol?

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

Re: alsactl adds volume controls?

[Clemens Ladisch]

Colin Guthrie wrote:
> 'Twas brillig, and Clemens Ladisch at 01/10/10 10:02 did gyre and gimble:
> > |   Amp-Out caps: N/A
> > 
> > Is this still "N/A" when you try again?
> 
> Yeah, I've run the script a few times and this has always been N/A.

No problem; according to the datasheet, this node does not have amp-out
caps, and the driver has to read them from the default node instead.
But this appears to work correctly, or you wouldn't have any control for
this node.

> As a more general question, how is the quirk for fixing the 0==mute
> thing added? Is it a kernel patch or some tweak in the /usr/share/alsa/
> tree (i.e. alsalib based quirk?)

At the moment, no working mechanism for changing control information in
user space exists.  (But it should be possible to make the "default"
control device some new plugin that redirects to the "hw" device while
changing some entries.)


Regards,
Clemens

Re: alsactl adds volume controls?

[Takashi Iwai]

At Mon, 04 Oct 2010 14:26:56 +0200,
Clemens Ladisch wrote:
> 
> Colin Guthrie wrote:
> > 'Twas brillig, and Clemens Ladisch at 01/10/10 10:02 did gyre and gimble:
> > > |   Amp-Out caps: N/A
> > > 
> > > Is this still "N/A" when you try again?
> > 
> > Yeah, I've run the script a few times and this has always been N/A.
> 
> No problem; according to the datasheet, this node does not have amp-out
> caps, and the driver has to read them from the default node instead.

Yes, "N/A" is a valid information here.  The default amp-out cap is
taken in this case.

> But this appears to work correctly, or you wouldn't have any control for
> this node.
> 
> > As a more general question, how is the quirk for fixing the 0==mute
> > thing added? Is it a kernel patch or some tweak in the /usr/share/alsa/
> > tree (i.e. alsalib based quirk?)
> 
> At the moment, no working mechanism for changing control information in
> user space exists.  (But it should be possible to make the "default"
> control device some new plugin that redirects to the "hw" device while
> changing some entries.)

Right, it'd be tricky, so I don't think we go for this.
Adding a quirk to the driver would be much simpler in such a case.


Takashi

Re: alsactl adds volume controls?

[Alexander E. Patrakov]

[-- Attachment #1: Type: text/plain, Size: 632 bytes --]

01.10.2010 14:19, Colin Guthrie wrote:
>> Colin, please tell us the IDs of your codec so that we can add a TLV
>> workaround to the driver.
>
> I presume the alsa-info.sh output is sufficient here?
>
> http://colin.guthr.ie/alsa-info.txt
>
> snd_hda_intel   : Intel Corporation|82801G (ICH7 Family) High Definition
> Audio Controller (vendor:8086 device:27d8 subv:1028 subd:01bd) (rev: 01)

Could you please also add this bad guy [info attached] to whatever 
lists? This card mutes the sound when Master == 0% and also needs a 
model=ref-no-jd quirk to get a working front-panel connector for headphones.

-- 
Alexander E. Patrakov

[-- Attachment #2: alsa-info.txt.dilyghwSDc --]
[-- Type: text/plain, Size: 36777 bytes --]

upload=true&script=true&cardinfo=
!!################################
!!ALSA Information Script v 0.4.59
!!################################

!!Script ran on: Mon Oct  4 14:14:49 UTC 2010


!!Linux Distribution
!!------------------

Gentoo Base System release 2.0.1 DISTRIB_ID="Gentoo"


!!DMI Information
!!---------------

Manufacturer:              
Product Name:              


!!Kernel Information
!!------------------

Kernel release:    2.6.34-gentoo-r11
Operating System:  GNU/Linux
Architecture:      x86_64
Processor:         Intel(R) Core(TM)2 CPU 6420 @ 2.13GHz
SMP Enabled:       Yes


!!ALSA Version
!!------------

Driver version:     1.0.22.1
Library version:    1.0.23
Utilities version:  1.0.23


!!Loaded ALSA modules
!!-------------------

snd_hda_intel
saa7134_alsa
snd_pcsp


!!Sound Servers on this system
!!----------------------------

Jack:
      Installed - Yes (/usr/bin/jackd)
      Running - No


!!Soundcards recognised by ALSA
!!-----------------------------

 0 [Intel          ]: HDA-Intel - HDA Intel
                      HDA Intel at 0x90420000 irq 32
 1 [SAA7134        ]: SAA7134 - SAA7134
                      saa7133[0] at 0x90004800 irq 22
 2 [pcsp           ]: PC-Speaker - pcsp
                      Internal PC-Speaker at port 0x61


!!PCI Soundcards installed in the system
!!--------------------------------------

00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 02)
06:01.0 Multimedia controller: Philips Semiconductors SAA7131/SAA7133/SAA7135 Video Broadcast Decoder (rev d1)


!!Advanced information - PCI Vendor/Device/Susbsystem ID's
!!--------------------------------------------------------

00:1b.0 0403: 8086:284b (rev 02)
	Subsystem: 8086:2114


!!Modprobe options (Sound related)
!!--------------------------------

snd-hda-intel: model=ref-no-jd


!!Loaded sound module options
!!--------------------------

!!Module: snd_hda_intel
	bdl_pos_adj : 1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
	beep_mode : 2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2
	enable : Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y
	enable_msi : -1
	id : (null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null)
	index : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
	model : ref-no-jd,(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null)
	patch : (null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null)
	position_fix : 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
	probe_mask : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
	probe_only : N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N
	single_cmd : N

!!Module: saa7134_alsa
	debug : 0
	enable : 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
	index : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1

!!Module: snd_pcsp
	enable : Y
	id : (null)
	index : -1
	nforce_wa : N
	nopcm : N


!!HDA-Intel Codec information
!!---------------------------
--startcollapse--

Codec: SigmaTel STAC9227
Address: 2
Function Id: 0x1
Vendor Id: 0x83847618
Subsystem Id: 0x80862114
Revision Id: 0x100201
No Modem Function Group found
Default PCM:
    rates [0x7e0]: 44100 48000 88200 96000 176400 192000
    bits [0xe]: 16 20 24
    formats [0x1]: PCM
Default Amp-In caps: ofs=0x00, nsteps=0x0e, stepsize=0x05, mute=0
Default Amp-Out caps: ofs=0x7f, nsteps=0x7f, stepsize=0x02, mute=1
GPIO: io=3, o=0, i=0, unsolicited=1, wake=1
  IO[0]: enable=1, dir=1, wake=0, sticky=0, data=1, unsol=0
  IO[1]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
  IO[2]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
Analog Loopback: 0x00
Node 0x02 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out R/L
  Control: name="Front Playback Volume", index=0, device=0
    ControlAmp: chs=3, dir=Out, idx=0, ofs=63
  Control: name="Front Playback Switch", index=0, device=0
    ControlAmp: chs=3, dir=Out, idx=0, ofs=0
  Device: name="STAC92xx Analog", type="Audio", device=0
  Amp-Out caps: N/A
  Amp-Out vals:  [0x58 0x58]
  Converter: stream=0, channel=0
  Power: setting=D0, actual=D0
  Delay: 13 samples
Node 0x03 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out R/L
  Control: name="Side Playback Volume", index=0, device=0
    ControlAmp: chs=3, dir=Out, idx=0, ofs=63
  Control: name="Side Playback Switch", index=0, device=0
    ControlAmp: chs=3, dir=Out, idx=0, ofs=0
  Amp-Out caps: N/A
  Amp-Out vals:  [0x58 0x58]
  Converter: stream=0, channel=0
  Power: setting=D0, actual=D0
  Delay: 13 samples
Node 0x04 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out R/L
  Control: name="Center Playback Volume", index=0, device=0
    ControlAmp: chs=1, dir=Out, idx=0, ofs=63
  Control: name="Center Playback Switch", index=0, device=0
    ControlAmp: chs=1, dir=Out, idx=0, ofs=0
  Control: name="LFE Playback Volume", index=0, device=0
    ControlAmp: chs=2, dir=Out, idx=0, ofs=63
  Control: name="LFE Playback Switch", index=0, device=0
    ControlAmp: chs=2, dir=Out, idx=0, ofs=0
  Control: name="Swap Center/LFE Playback Switch", index=0, device=0
    ControlAmp: chs=0, dir=In, idx=0, ofs=0
  Amp-Out caps: N/A
  Amp-Out vals:  [0x58 0x58]
  Converter: stream=0, channel=0
  Power: setting=D0, actual=D0
  Delay: 13 samples
Node 0x05 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out R/L
  Control: name="Surround Playback Volume", index=0, device=0
    ControlAmp: chs=3, dir=Out, idx=0, ofs=63
  Control: name="Surround Playback Switch", index=0, device=0
    ControlAmp: chs=3, dir=Out, idx=0, ofs=0
  Amp-Out caps: N/A
  Amp-Out vals:  [0x58 0x58]
  Converter: stream=0, channel=0
  Power: setting=D0, actual=D0
  Delay: 13 samples
Node 0x06 [Vendor Defined Widget] wcaps 0xfd0c05: Stereo Amp-Out R/L
  Amp-Out caps: N/A
  Amp-Out vals:  [0xff 0xff]
  Power: setting=D3, actual=D3
  Delay: 13 samples
Node 0x07 [Audio Input] wcaps 0x1d0541: Stereo
  Device: name="STAC92xx Analog", type="Audio", device=0
  Converter: stream=0, channel=0
  SDI-Select: 0
  Power: setting=D0, actual=D0
  Delay: 13 samples
  Connection: 1
     0x1b
  Processing caps: benign=0, ncoeff=0
Node 0x08 [Audio Input] wcaps 0x1d0541: Stereo
  Converter: stream=0, channel=0
  SDI-Select: 0
  Power: setting=D0, actual=D0
  Delay: 13 samples
  Connection: 1
     0x1c
  Processing caps: benign=0, ncoeff=0
Node 0x09 [Audio Input] wcaps 0x1d0541: Stereo
  Converter: stream=0, channel=0
  SDI-Select: 0
  Power: setting=D0, actual=D0
  Delay: 13 samples
  Connection: 1
     0x1d
  Processing caps: benign=0, ncoeff=0
Node 0x0a [Pin Complex] wcaps 0x400181: Stereo
  Pincap 0x0000173f: IN OUT HP Detect Trigger ImpSense
    Vref caps: HIZ 50 GRD 80
  Pin Default 0x02214020: [Jack] HP Out at Ext Front
    Conn = 1/8, Color = Green
    DefAssociation = 0x2, Sequence = 0x0
  Pin-ctls: 0xc0: OUT HP VREF_HIZ
  Unsolicited: tag=00, enabled=0
  Connection: 2
     0x02* 0x03
Node 0x0b [Pin Complex] wcaps 0x400181: Stereo
  Control: name="Front Mic Jack Mode", index=0, device=0
    ControlAmp: chs=0, dir=In, idx=0, ofs=0
  Pincap 0x0000173f: IN OUT HP Detect Trigger ImpSense
    Vref caps: HIZ 50 GRD 80
  Pin Default 0x02a19080: [Jack] Mic at Ext Front
    Conn = 1/8, Color = Pink
    DefAssociation = 0x8, Sequence = 0x0
  Pin-ctls: 0x24: IN VREF_80
  Unsolicited: tag=02, enabled=1
  Connection: 2
     0x02* 0x03
Node 0x0c [Pin Complex] wcaps 0x400181: Stereo
  Control: name="Line Jack Mode", index=0, device=0
    ControlAmp: chs=0, dir=In, idx=0, ofs=0
  Pincap 0x00001737: IN OUT Detect Trigger ImpSense
    Vref caps: HIZ 50 GRD 80
  Pin Default 0x0181304e: [Jack] Line In at Ext Rear
    Conn = 1/8, Color = Blue
    DefAssociation = 0x4, Sequence = 0xe
  Pin-ctls: 0x20: IN VREF_HIZ
  Unsolicited: tag=03, enabled=1
  Connection: 1
     0x03
Node 0x0d [Pin Complex] wcaps 0x400181: Stereo
  Pincap 0x0000173f: IN OUT HP Detect Trigger ImpSense
    Vref caps: HIZ 50 GRD 80
  Pin Default 0x01014010: [Jack] Line Out at Ext Rear
    Conn = 1/8, Color = Green
    DefAssociation = 0x1, Sequence = 0x0
  Pin-ctls: 0x40: OUT VREF_HIZ
  Unsolicited: tag=00, enabled=0
  Connection: 1
     0x02
Node 0x0e [Pin Complex] wcaps 0x400181: Stereo
  Control: name="Mic Jack Mode", index=0, device=0
    ControlAmp: chs=0, dir=In, idx=0, ofs=0
  Pincap 0x00001737: IN OUT Detect Trigger ImpSense
    Vref caps: HIZ 50 GRD 80
  Pin Default 0x01a19040: [Jack] Mic at Ext Rear
    Conn = 1/8, Color = Pink
    DefAssociation = 0x4, Sequence = 0x0
  Pin-ctls: 0x24: IN VREF_80
  Unsolicited: tag=01, enabled=1
  Connection: 1
     0x04
Node 0x0f [Pin Complex] wcaps 0x400181: Stereo
  Pincap 0x00001737: IN OUT Detect Trigger ImpSense
    Vref caps: HIZ 50 GRD 80
  Pin Default 0x01011012: [Jack] Line Out at Ext Rear
    Conn = 1/8, Color = Black
    DefAssociation = 0x1, Sequence = 0x2
  Pin-ctls: 0x40: OUT VREF_HIZ
  Unsolicited: tag=00, enabled=0
  Connection: 1
     0x05
Node 0x10 [Pin Complex] wcaps 0x400181: Stereo
  Pincap 0x00000037: IN OUT Detect Trigger ImpSense
  Pin Default 0x01016011: [Jack] Line Out at Ext Rear
    Conn = 1/8, Color = Orange
    DefAssociation = 0x1, Sequence = 0x1
  Pin-ctls: 0x40: OUT
  Unsolicited: tag=00, enabled=0
  Connection: 1
     0x04
Node 0x11 [Pin Complex] wcaps 0x400181: Stereo
  Pincap 0x00000037: IN OUT Detect Trigger ImpSense
  Pin Default 0x0101201f: [Jack] Line Out at Ext Rear
    Conn = 1/8, Color = Grey
    DefAssociation = 0x1, Sequence = 0xf
  Pin-ctls: 0x40: OUT
  Unsolicited: tag=00, enabled=0
  Connection: 1
     0x03
Node 0x12 [Pin Complex] wcaps 0x400001: Stereo
  Pincap 0x00000020: IN
  Pin Default 0x183301f0: [Jack] CD at Int HDMI
    Conn = ATAPI, Color = Unknown
    DefAssociation = 0xf, Sequence = 0x0
    Misc = NO_PRESENCE
  Pin-ctls: 0x20: IN
Node 0x13 [Vendor Defined Widget] wcaps 0xf00001: Stereo
Node 0x14 [Vendor Defined Widget] wcaps 0xf00001: Stereo
Node 0x15 [Audio Selector] wcaps 0x30010d: Stereo Amp-Out
  Control: name="Mux Capture Volume", index=0, device=0
    ControlAmp: chs=3, dir=Out, idx=0, ofs=0
  Amp-Out caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0
  Amp-Out vals:  [0x03 0x03]
  Connection: 9
     0x0e* 0x12 0x0f 0x0b 0x0c 0x0d 0x0a 0x10 0x11
Node 0x16 [Audio Selector] wcaps 0x30010d: Stereo Amp-Out
  Control: name="Mux Capture Volume", index=1, device=0
    ControlAmp: chs=3, dir=Out, idx=0, ofs=0
  Amp-Out caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0
  Amp-Out vals:  [0x00 0x00]
  Connection: 9
     0x0e* 0x12 0x0f 0x0b 0x0c 0x0d 0x0a 0x10 0x11
Node 0x17 [Audio Selector] wcaps 0x30010d: Stereo Amp-Out
  Control: name="Mux Capture Volume", index=2, device=0
    ControlAmp: chs=3, dir=Out, idx=0, ofs=0
  Amp-Out caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0
  Amp-Out vals:  [0x00 0x00]
  Connection: 9
     0x0e* 0x12 0x0f 0x0b 0x0c 0x0d 0x0a 0x10 0x11
Node 0x18 [Audio Selector] wcaps 0x300103: Stereo Amp-In
  Control: name="Capture Volume", index=0, device=0
    ControlAmp: chs=3, dir=In, idx=0, ofs=0
  Amp-In caps: N/A
  Amp-In vals:  [0x0e 0x0e]
  Connection: 1
     0x15
Node 0x19 [Audio Selector] wcaps 0x300103: Stereo Amp-In
  Control: name="Capture Volume", index=1, device=0
    ControlAmp: chs=3, dir=In, idx=0, ofs=0
  Amp-In caps: N/A
  Amp-In vals:  [0x00 0x00]
  Connection: 1
     0x16
Node 0x1a [Audio Selector] wcaps 0x300103: Stereo Amp-In
  Control: name="Capture Volume", index=2, device=0
    ControlAmp: chs=3, dir=In, idx=0, ofs=0
  Amp-In caps: N/A
  Amp-In vals:  [0x00 0x00]
  Connection: 1
     0x17
Node 0x1b [Audio Selector] wcaps 0x30090d: Stereo Amp-Out R/L
  Control: name="Capture Switch", index=0, device=0
    ControlAmp: chs=3, dir=Out, idx=0, ofs=0
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x00 0x00]
  Connection: 1
     0x18
Node 0x1c [Audio Selector] wcaps 0x30090d: Stereo Amp-Out R/L
  Control: name="Capture Switch", index=1, device=0
    ControlAmp: chs=3, dir=Out, idx=0, ofs=0
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x80 0x80]
  Connection: 1
     0x19
Node 0x1d [Audio Selector] wcaps 0x30090d: Stereo Amp-Out R/L
  Control: name="Capture Switch", index=2, device=0
    ControlAmp: chs=3, dir=Out, idx=0, ofs=0
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x80 0x80]
  Connection: 1
     0x1a
Node 0x1e [Audio Output] wcaps 0x40211: Stereo Digital
  Control: name="IEC958 Playback Con Mask", index=0, device=0
  Control: name="IEC958 Playback Pro Mask", index=0, device=0
  Control: name="IEC958 Playback Default", index=0, device=0
  Control: name="IEC958 Playback Switch", index=0, device=0
  Control: name="IEC958 Default PCM Playback Switch", index=0, device=0
  Device: name="STAC92xx Digital", type="SPDIF", device=1
  Converter: stream=0, channel=0
  Digital:
  Digital category: 0x0
  PCM:
    rates [0x7e0]: 44100 48000 88200 96000 176400 192000
    bits [0xe]: 16 20 24
    formats [0x5]: PCM AC3
  Delay: 4 samples
Node 0x1f [Vendor Defined Widget] wcaps 0xf30201: Stereo Digital
  Delay: 3 samples
Node 0x20 [Audio Input] wcaps 0x140311: Stereo Digital
  Device: name="STAC92xx Digital", type="SPDIF", device=1
  Converter: stream=0, channel=0
  SDI-Select: 0
  Digital:
  Digital category: 0x0
  PCM:
    rates [0x160]: 44100 48000 96000
    bits [0xe]: 16 20 24
    formats [0x5]: PCM AC3
  Delay: 4 samples
  Connection: 1
     0x22
Node 0x21 [Pin Complex] wcaps 0x400301: Stereo Digital
  Pincap 0x00000010: OUT
  Pin Default 0x01442070: [Jack] SPDIF Out at Ext Rear
    Conn = RCA, Color = Grey
    DefAssociation = 0x7, Sequence = 0x0
  Pin-ctls: 0x40: OUT
  Connection: 5
     0x1e* 0x1f 0x1b 0x1c 0x1d
Node 0x22 [Pin Complex] wcaps 0x430681: Stereo Digital
  Pincap 0x00010024: IN EAPD Detect
  EAPD 0x0:
  Pin Default 0x01c42190: [Jack] SPDIF In at Ext Rear
    Conn = RCA, Color = Grey
    DefAssociation = 0x9, Sequence = 0x0
    Misc = NO_PRESENCE
  Pin-ctls: 0x20: IN
  Unsolicited: tag=00, enabled=0
  Power: setting=D0, actual=D0
  Delay: 3 samples
Node 0x23 [Beep Generator Widget] wcaps 0x70000c: Mono Amp-Out
  Control: name="Beep Playback Volume", index=0, device=0
    ControlAmp: chs=1, dir=Out, idx=0, ofs=0
  Amp-Out caps: ofs=0x03, nsteps=0x03, stepsize=0x17, mute=0
  Amp-Out vals:  [0x00]
Node 0x24 [Volume Knob Widget] wcaps 0x600000: Mono
  Volume-Knob: delta=1, steps=127, direct=1, val=127
  Connection: 4
     0x02 0x03 0x04 0x05
--endcollapse--


!!ALSA Device nodes
!!-----------------

crw-rw----+ 1 root audio 116, 10 Oct  4 19:17 /dev/snd/controlC0
crw-rw----+ 1 root audio 116, 12 Oct  4 19:17 /dev/snd/controlC1
crw-rw----+ 1 root audio 116,  4 Oct  4 19:17 /dev/snd/controlC2
crw-rw----+ 1 root audio 116,  9 Oct  4 19:17 /dev/snd/hwC0D2
crw-rw----+ 1 root audio 116,  8 Oct  4 19:18 /dev/snd/pcmC0D0c
crw-rw----+ 1 root audio 116,  7 Oct  4 19:18 /dev/snd/pcmC0D0p
crw-rw----+ 1 root audio 116,  6 Oct  4 19:17 /dev/snd/pcmC0D1c
crw-rw----+ 1 root audio 116,  5 Oct  4 19:17 /dev/snd/pcmC0D1p
crw-rw----+ 1 root audio 116, 11 Oct  4 19:17 /dev/snd/pcmC1D0c
crw-rw----+ 1 root audio 116,  3 Oct  4 19:18 /dev/snd/pcmC2D0p
crw-rw----+ 1 root audio 116, 13 Oct  4 19:17 /dev/snd/seq
crw-rw----+ 1 root audio 116,  2 Oct  4 19:17 /dev/snd/timer

/dev/snd/by-path:
total 0
drwxr-xr-x 2 root root 100 Oct  4 19:17 .
drwxr-xr-x 3 root root 300 Oct  4 19:17 ..
lrwxrwxrwx 1 root root  12 Oct  4 19:17 pci-0000:00:1b.0 -> ../controlC0
lrwxrwxrwx 1 root root  12 Oct  4 19:17 pci-0000:06:01.0 -> ../controlC1
lrwxrwxrwx 1 root root  12 Oct  4 19:17 platform-pcspkr -> ../controlC2


!!Aplay/Arecord output
!!------------

APLAY

**** List of PLAYBACK Hardware Devices ****
card 0: Intel [HDA Intel], device 0: STAC92xx Analog [STAC92xx Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: Intel [HDA Intel], device 1: STAC92xx Digital [STAC92xx Digital]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 2: pcsp [pcsp], device 0: pcspeaker [pcsp]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

ARECORD

**** List of CAPTURE Hardware Devices ****
card 0: Intel [HDA Intel], device 0: STAC92xx Analog [STAC92xx Analog]
  Subdevices: 3/3
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2
card 0: Intel [HDA Intel], device 1: STAC92xx Digital [STAC92xx Digital]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: SAA7134 [SAA7134], device 0: SAA7134 PCM [SAA7134 PCM]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

!!Amixer output
!!-------------

!!-------Mixer controls for card 0 [Intel]

Card hw:0 'Intel'/'HDA Intel at 0x90420000 irq 32'
  Mixer name	: 'SigmaTel STAC9227'
  Components	: 'HDA:83847618,80862114,00100201'
  Controls      : 38
  Simple ctrls  : 25
Simple mixer control 'Master',0
  Capabilities: pvolume pvolume-joined pswitch pswitch-joined penum
  Playback channels: Mono
  Limits: Playback 0 - 64
  Mono: Playback 25 [39%] [-29.25dB] [on]
Simple mixer control 'PCM',0
  Capabilities: pvolume penum
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 255
  Mono:
  Front Left: Playback 255 [100%] [0.00dB]
  Front Right: Playback 255 [100%] [0.00dB]
Simple mixer control 'Front',0
  Capabilities: pvolume pswitch penum
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 64
  Mono:
  Front Left: Playback 64 [100%] [0.00dB] [on]
  Front Right: Playback 64 [100%] [0.00dB] [on]
Simple mixer control 'Front Mic Jack Mode',0
  Capabilities: enum
  Items: 'Mic In' 'Line In'
  Item0: 'Mic In'
Simple mixer control 'Surround',0
  Capabilities: pvolume pswitch penum
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 64
  Mono:
  Front Left: Playback 64 [100%] [0.00dB] [on]
  Front Right: Playback 64 [100%] [0.00dB] [on]
Simple mixer control 'Center',0
  Capabilities: pvolume pvolume-joined pswitch pswitch-joined penum
  Playback channels: Mono
  Limits: Playback 0 - 64
  Mono: Playback 64 [100%] [0.00dB] [on]
Simple mixer control 'LFE',0
  Capabilities: pvolume pvolume-joined pswitch pswitch-joined penum
  Playback channels: Mono
  Limits: Playback 0 - 64
  Mono: Playback 64 [100%] [0.00dB] [on]
Simple mixer control 'Side',0
  Capabilities: pvolume pswitch penum
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 64
  Mono:
  Front Left: Playback 64 [100%] [0.00dB] [on]
  Front Right: Playback 64 [100%] [0.00dB] [on]
Simple mixer control 'Line Jack Mode',0
  Capabilities: enum
  Items: 'Mic In' 'Line In'
  Item0: 'Line In'
Simple mixer control 'Mic Jack Mode',0
  Capabilities: enum
  Items: 'Mic In' 'Line In'
  Item0: 'Mic In'
Simple mixer control 'IEC958',0
  Capabilities: pswitch pswitch-joined penum
  Playback channels: Mono
  Mono: Playback [off]
Simple mixer control 'IEC958 Default PCM',0
  Capabilities: pswitch pswitch-joined penum
  Playback channels: Mono
  Mono: Playback [off]
Simple mixer control 'IEC958 Playback Source',0
  Capabilities: enum
  Items: 'Digital Playback' 'ADAT' 'Analog Mux 1' 'Analog Mux 2' 'Analog Mux 3'
  Item0: 'Digital Playback'
Simple mixer control 'Beep',0
  Capabilities: pvolume pvolume-joined pswitch pswitch-joined penum
  Playback channels: Mono
  Limits: Playback 0 - 3
  Mono: Playback 0 [0%] [-18.00dB] [off]
Simple mixer control 'Capture',0
  Capabilities: cvolume cswitch penum
  Capture channels: Front Left - Front Right
  Limits: Capture 0 - 14
  Front Left: Capture 14 [100%] [21.00dB] [on]
  Front Right: Capture 14 [100%] [21.00dB] [on]
Simple mixer control 'Capture',1
  Capabilities: cvolume cswitch penum
  Capture channels: Front Left - Front Right
  Limits: Capture 0 - 14
  Front Left: Capture 0 [0%] [0.00dB] [off]
  Front Right: Capture 0 [0%] [0.00dB] [off]
Simple mixer control 'Capture',2
  Capabilities: cvolume cswitch penum
  Capture channels: Front Left - Front Right
  Limits: Capture 0 - 14
  Front Left: Capture 0 [0%] [0.00dB] [off]
  Front Right: Capture 0 [0%] [0.00dB] [off]
Simple mixer control 'Digital',0
  Capabilities: cvolume penum
  Capture channels: Front Left - Front Right
  Limits: Capture 0 - 120
  Front Left: Capture 62 [52%] [1.00dB]
  Front Right: Capture 62 [52%] [1.00dB]
Simple mixer control 'Input Source',0
  Capabilities: cenum
  Items: 'Mic' 'Front Mic' 'Line' 'CD'
  Item0: 'Mic'
Simple mixer control 'Input Source',1
  Capabilities: cenum
  Items: 'Mic' 'Front Mic' 'Line' 'CD'
  Item0: 'Mic'
Simple mixer control 'Input Source',2
  Capabilities: cenum
  Items: 'Mic' 'Front Mic' 'Line' 'CD'
  Item0: 'Mic'
Simple mixer control 'Mux',0
  Capabilities: cvolume penum
  Capture channels: Front Left - Front Right
  Limits: Capture 0 - 4
  Front Left: Capture 3 [75%] [30.00dB]
  Front Right: Capture 3 [75%] [30.00dB]
Simple mixer control 'Mux',1
  Capabilities: cvolume penum
  Capture channels: Front Left - Front Right
  Limits: Capture 0 - 4
  Front Left: Capture 0 [0%] [0.00dB]
  Front Right: Capture 0 [0%] [0.00dB]
Simple mixer control 'Mux',2
  Capabilities: cvolume penum
  Capture channels: Front Left - Front Right
  Limits: Capture 0 - 4
  Front Left: Capture 0 [0%] [0.00dB]
  Front Right: Capture 0 [0%] [0.00dB]
Simple mixer control 'Swap Center/LFE',0
  Capabilities: pswitch pswitch-joined penum
  Playback channels: Mono
  Mono: Playback [off]

!!-------Mixer controls for card 1 [SAA7134]

Card hw:1 'SAA7134'/'saa7133[0] at 0x90004800 irq 22'
  Mixer name	: 'SAA7134 Mixer'
  Components	: ''
  Controls      : 6
  Simple ctrls  : 3
Simple mixer control 'Line',1
  Capabilities: volume cswitch penum
  Playback channels: Front Left - Front Right
  Capture channels: Front Left - Front Right
  Limits: 0 - 20
  Front Left: 0 [0%] Capture [off]
  Front Right: 0 [0%] Capture [off]
Simple mixer control 'Line',2
  Capabilities: volume cswitch penum
  Playback channels: Front Left - Front Right
  Capture channels: Front Left - Front Right
  Limits: 0 - 20
  Front Left: 0 [0%] Capture [off]
  Front Right: 0 [0%] Capture [off]
Simple mixer control 'Video',0
  Capabilities: volume cswitch penum
  Playback channels: Front Left - Front Right
  Capture channels: Front Left - Front Right
  Limits: 0 - 20
  Front Left: 0 [0%] Capture [on]
  Front Right: 0 [0%] Capture [on]

!!-------Mixer controls for card 2 [pcsp]

Card hw:2 'pcsp'/'Internal PC-Speaker at port 0x61'
  Mixer name	: 'PC-Speaker'
  Components	: ''
  Controls      : 4
  Simple ctrls  : 3
Simple mixer control 'Master',0
  Capabilities: pvolume pswitch pswitch-joined penum
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 255
  Mono:
  Front Left: Playback 196 [77%] [11.56dB] [on]
  Front Right: Playback 196 [77%] [11.56dB] [on]
Simple mixer control 'Beep',0
  Capabilities: pswitch pswitch-joined penum
  Playback channels: Mono
  Mono: Playback [off]
Simple mixer control 'BaseFRQ',0
  Capabilities: penum
  Items: '18643' '37286'
  Item0: '37286'


!!Alsactl output
!!-------------

--startcollapse--
state.Intel {
	control.1 {
		comment.access 'read write'
		comment.type INTEGER
		comment.count 2
		comment.range '0 - 64'
		comment.dbmin -4800
		comment.dbmax 0
		iface MIXER
		name 'Front Playback Volume'
		value.0 64
		value.1 64
	}
	control.2 {
		comment.access 'read write'
		comment.type BOOLEAN
		comment.count 2
		iface MIXER
		name 'Front Playback Switch'
		value.0 true
		value.1 true
	}
	control.3 {
		comment.access 'read write'
		comment.type INTEGER
		comment.count 2
		comment.range '0 - 64'
		comment.dbmin -4800
		comment.dbmax 0
		iface MIXER
		name 'Surround Playback Volume'
		value.0 64
		value.1 64
	}
	control.4 {
		comment.access 'read write'
		comment.type BOOLEAN
		comment.count 2
		iface MIXER
		name 'Surround Playback Switch'
		value.0 true
		value.1 true
	}
	control.5 {
		comment.access 'read write'
		comment.type INTEGER
		comment.count 1
		comment.range '0 - 64'
		comment.dbmin -4800
		comment.dbmax 0
		iface MIXER
		name 'Center Playback Volume'
		value 64
	}
	control.6 {
		comment.access 'read write'
		comment.type BOOLEAN
		comment.count 1
		iface MIXER
		name 'Center Playback Switch'
		value true
	}
	control.7 {
		comment.access 'read write'
		comment.type INTEGER
		comment.count 1
		comment.range '0 - 64'
		comment.dbmin -4800
		comment.dbmax 0
		iface MIXER
		name 'LFE Playback Volume'
		value 64
	}
	control.8 {
		comment.access 'read write'
		comment.type BOOLEAN
		comment.count 1
		iface MIXER
		name 'LFE Playback Switch'
		value true
	}
	control.9 {
		comment.access 'read write'
		comment.type BOOLEAN
		comment.count 1
		iface MIXER
		name 'Swap Center/LFE Playback Switch'
		value false
	}
	control.10 {
		comment.access 'read write'
		comment.type INTEGER
		comment.count 2
		comment.range '0 - 64'
		comment.dbmin -4800
		comment.dbmax 0
		iface MIXER
		name 'Side Playback Volume'
		value.0 64
		value.1 64
	}
	control.11 {
		comment.access 'read write'
		comment.type BOOLEAN
		comment.count 2
		iface MIXER
		name 'Side Playback Switch'
		value.0 true
		value.1 true
	}
	control.12 {
		comment.access 'read write'
		comment.type ENUMERATED
		comment.count 1
		comment.item.0 'Mic In'
		comment.item.1 'Line In'
		iface MIXER
		name 'Mic Jack Mode'
		value 'Mic In'
	}
	control.13 {
		comment.access 'read write'
		comment.type ENUMERATED
		comment.count 1
		comment.item.0 'Mic In'
		comment.item.1 'Line In'
		iface MIXER
		name 'Front Mic Jack Mode'
		value 'Mic In'
	}
	control.14 {
		comment.access 'read write'
		comment.type ENUMERATED
		comment.count 1
		comment.item.0 'Mic In'
		comment.item.1 'Line In'
		iface MIXER
		name 'Line Jack Mode'
		value 2
	}
	control.15 {
		comment.access 'read write'
		comment.type INTEGER
		comment.count 1
		comment.range '0 - 3'
		comment.dbmin -1800
		comment.dbmax 0
		iface MIXER
		name 'Beep Playback Volume'
		value 0
	}
	control.16 {
		comment.access 'read write'
		comment.type BOOLEAN
		comment.count 1
		iface MIXER
		name 'Beep Playback Switch'
		value false
	}
	control.17 {
		comment.access 'read write'
		comment.type INTEGER
		comment.count 2
		comment.range '0 - 14'
		comment.dbmin 0
		comment.dbmax 2100
		iface MIXER
		name 'Capture Volume'
		value.0 14
		value.1 14
	}
	control.18 {
		comment.access 'read write'
		comment.type BOOLEAN
		comment.count 2
		iface MIXER
		name 'Capture Switch'
		value.0 true
		value.1 true
	}
	control.19 {
		comment.access 'read write'
		comment.type INTEGER
		comment.count 2
		comment.range '0 - 14'
		comment.dbmin 0
		comment.dbmax 2100
		iface MIXER
		name 'Capture Volume'
		index 1
		value.0 0
		value.1 0
	}
	control.20 {
		comment.access 'read write'
		comment.type BOOLEAN
		comment.count 2
		iface MIXER
		name 'Capture Switch'
		index 1
		value.0 false
		value.1 false
	}
	control.21 {
		comment.access 'read write'
		comment.type INTEGER
		comment.count 2
		comment.range '0 - 14'
		comment.dbmin 0
		comment.dbmax 2100
		iface MIXER
		name 'Capture Volume'
		index 2
		value.0 0
		value.1 0
	}
	control.22 {
		comment.access 'read write'
		comment.type BOOLEAN
		comment.count 2
		iface MIXER
		name 'Capture Switch'
		index 2
		value.0 false
		value.1 false
	}
	control.23 {
		comment.access 'read write'
		comment.type INTEGER
		comment.count 2
		comment.range '0 - 4'
		comment.dbmin 0
		comment.dbmax 4000
		iface MIXER
		name 'Mux Capture Volume'
		value.0 3
		value.1 3
	}
	control.24 {
		comment.access 'read write'
		comment.type INTEGER
		comment.count 2
		comment.range '0 - 4'
		comment.dbmin 0
		comment.dbmax 4000
		iface MIXER
		name 'Mux Capture Volume'
		index 1
		value.0 0
		value.1 0
	}
	control.25 {
		comment.access 'read write'
		comment.type INTEGER
		comment.count 2
		comment.range '0 - 4'
		comment.dbmin 0
		comment.dbmax 4000
		iface MIXER
		name 'Mux Capture Volume'
		index 2
		value.0 0
		value.1 0
	}
	control.26 {
		comment.access 'read write'
		comment.type ENUMERATED
		comment.count 1
		comment.item.0 Mic
		comment.item.1 'Front Mic'
		comment.item.2 Line
		comment.item.3 CD
		iface MIXER
		name 'Input Source'
		value Mic
	}
	control.27 {
		comment.access 'read write'
		comment.type ENUMERATED
		comment.count 1
		comment.item.0 Mic
		comment.item.1 'Front Mic'
		comment.item.2 Line
		comment.item.3 CD
		iface MIXER
		name 'Input Source'
		index 1
		value Mic
	}
	control.28 {
		comment.access 'read write'
		comment.type ENUMERATED
		comment.count 1
		comment.item.0 Mic
		comment.item.1 'Front Mic'
		comment.item.2 Line
		comment.item.3 CD
		iface MIXER
		name 'Input Source'
		index 2
		value Mic
	}
	control.29 {
		comment.access 'read write'
		comment.type ENUMERATED
		comment.count 1
		comment.item.0 'Digital Playback'
		comment.item.1 ADAT
		comment.item.2 'Analog Mux 1'
		comment.item.3 'Analog Mux 2'
		comment.item.4 'Analog Mux 3'
		iface MIXER
		name 'IEC958 Playback Source'
		value 'Digital Playback'
	}
	control.30 {
		comment.access read
		comment.type IEC958
		comment.count 1
		iface MIXER
		name 'IEC958 Playback Con Mask'
		value '0fff000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
	}
	control.31 {
		comment.access read
		comment.type IEC958
		comment.count 1
		iface MIXER
		name 'IEC958 Playback Pro Mask'
		value '0f00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
	}
	control.32 {
		comment.access 'read write'
		comment.type IEC958
		comment.count 1
		iface MIXER
		name 'IEC958 Playback Default'
		value '0400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
	}
	control.33 {
		comment.access 'read write'
		comment.type BOOLEAN
		comment.count 1
		iface MIXER
		name 'IEC958 Playback Switch'
		value false
	}
	control.34 {
		comment.access 'read write'
		comment.type BOOLEAN
		comment.count 1
		iface MIXER
		name 'IEC958 Default PCM Playback Switch'
		value false
	}
	control.35 {
		comment.access 'read write'
		comment.type INTEGER
		comment.count 1
		comment.range '0 - 64'
		comment.dbmin -4800
		comment.dbmax 0
		iface MIXER
		name 'Master Playback Volume'
		value 25
	}
	control.36 {
		comment.access 'read write'
		comment.type BOOLEAN
		comment.count 1
		iface MIXER
		name 'Master Playback Switch'
		value true
	}
	control.37 {
		comment.access 'read write user'
		comment.type INTEGER
		comment.count 2
		comment.range '0 - 255'
		comment.tlv '0000000100000008ffffec1400000014'
		comment.dbmin -5100
		comment.dbmax 0
		iface MIXER
		name 'PCM Playback Volume'
		value.0 255
		value.1 255
	}
	control.38 {
		comment.access 'read write user'
		comment.type INTEGER
		comment.count 2
		comment.range '0 - 120'
		comment.tlv '0000000100000008fffff44800000032'
		comment.dbmin -3000
		comment.dbmax 3000
		iface MIXER
		name 'Digital Capture Volume'
		value.0 62
		value.1 62
	}
}
state.SAA7134 {
	control.1 {
		comment.access 'read write'
		comment.type INTEGER
		comment.count 2
		comment.range '0 - 20'
		iface MIXER
		name 'Video Volume'
		value.0 0
		value.1 0
	}
	control.2 {
		comment.access 'read write'
		comment.type INTEGER
		comment.count 2
		comment.range '0 - 20'
		iface MIXER
		name 'Line Volume'
		index 1
		value.0 0
		value.1 0
	}
	control.3 {
		comment.access 'read write'
		comment.type INTEGER
		comment.count 2
		comment.range '0 - 20'
		iface MIXER
		name 'Line Volume'
		index 2
		value.0 0
		value.1 0
	}
	control.4 {
		comment.access 'read write'
		comment.type BOOLEAN
		comment.count 2
		iface MIXER
		name 'Video Capture Switch'
		value.0 true
		value.1 true
	}
	control.5 {
		comment.access 'read write'
		comment.type BOOLEAN
		comment.count 2
		iface MIXER
		name 'Line Capture Switch'
		index 1
		value.0 false
		value.1 false
	}
	control.6 {
		comment.access 'read write'
		comment.type BOOLEAN
		comment.count 2
		iface MIXER
		name 'Line Capture Switch'
		index 2
		value.0 false
		value.1 false
	}
}
state.pcsp {
	control.1 {
		comment.access 'read write'
		comment.type BOOLEAN
		comment.count 1
		iface MIXER
		name 'Master Playback Switch'
		value true
	}
	control.2 {
		comment.access 'read write'
		comment.type ENUMERATED
		comment.count 1
		comment.item.0 '18643'
		comment.item.1 '37286'
		iface MIXER
		name 'BaseFRQ Playback Volume'
		value '37286'
	}
	control.3 {
		comment.access 'read write'
		comment.type BOOLEAN
		comment.count 1
		iface MIXER
		name 'Beep Playback Switch'
		value false
	}
	control.4 {
		comment.access 'read write user'
		comment.type INTEGER
		comment.count 2
		comment.range '0 - 255'
		comment.tlv '0000000100000008fffffc180000000b'
		comment.dbmin -1000
		comment.dbmax 1805
		iface MIXER
		name 'Master Playback Volume'
		value.0 196
		value.1 196
	}
}
--endcollapse--


!!All Loaded Modules
!!------------------

Module
xt_state
iptable_filter
iptable_mangle
ipv6
ipt_MASQUERADE
iptable_nat
nf_nat
nf_conntrack_ipv4
nf_defrag_ipv4
xt_DSCP
xt_dscp
xt_string
xt_owner
xt_NFQUEUE
xt_multiport
xt_MARK
xt_mark
xt_iprange
xt_hashlimit
xt_conntrack
xt_CONNMARK
xt_connmark
ip_tables
x_tables
snd_seq
snd_seq_device
ext3
jbd
kvm_intel
kvm
saa7134_alsa
tda1004x
saa7134_dvb
videobuf_dvb
dvb_core
ir_kbd_i2c
tda827x
tda8290
tuner
snd_hda_codec_idt
snd_hda_intel
saa7134
ir_common
v4l2_common
snd_pcsp
videodev
snd_hda_codec
snd_hwdep
snd_pcm
v4l1_compat
v4l2_compat_ioctl32
videobuf_dma_sg
videobuf_core
ir_core
snd_timer
tveeprom
snd
e1000e
firewire_ohci
soundcore
snd_page_alloc
firewire_core
parport_pc
crc_itu_t
parport


!!Sysfs Files
!!-----------

/sys/class/sound/hwC0D2/init_pin_configs:
0x0a 0x0221421f
0x0b 0x01a19023
0x0c 0x01813221
0x0d 0x01114210
0x0e 0x40f0f0f0
0x0f 0x40f0f0f1
0x10 0x40f0f0f2
0x11 0x40f0f0f3
0x12 0x503301f0
0x21 0x01442170
0x22 0x81c42090

/sys/class/sound/hwC0D2/driver_pin_configs:
0x0a 0x02214020
0x0b 0x02a19080
0x0c 0x0181304e
0x0d 0x01014010
0x0e 0x01a19040
0x0f 0x01011012
0x10 0x01016011
0x11 0x0101201f
0x12 0x183301f0
0x21 0x01442070
0x22 0x01c42190

/sys/class/sound/hwC0D2/user_pin_configs:

/sys/class/sound/hwC0D2/init_verbs:


!!ALSA/HDA dmesg
!!------------------

[    7.219628] IRQ 22/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs
[    7.229380] HDA Intel 0000:00:1b.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
[    7.229422] HDA Intel 0000:00:1b.0: irq 32 for MSI/MSI-X
[    7.229444] HDA Intel 0000:00:1b.0: setting latency timer to 64
[    7.239073] firewire_core: created device fw0: GUID 0090270001b8b988, S400
[    7.322155] saa7133[0]: i2c eeprom read error (err=-5)
[    7.336858] input: HDA Intel CD at Int HDMI Jack as /devices/pci0000:00/0000:00:1b.0/sound/card0/input5
[    7.336909] input: HDA Intel Line In at Ext Rear Jack as /devices/pci0000:00/0000:00:1b.0/sound/card0/input6
[    7.336952] input: HDA Intel Mic at Ext Front Jack as /devices/pci0000:00/0000:00:1b.0/sound/card0/input7
[    7.336994] input: HDA Intel Mic at Ext Rear Jack as /devices/pci0000:00/0000:00:1b.0/sound/card0/input8
[    7.337037] input: HDA Intel Line Out at Ext Rear Jack as /devices/pci0000:00/0000:00:1b.0/sound/card0/input9
[    7.337078] input: HDA Intel Line Out at Ext Rear Jack as /devices/pci0000:00/0000:00:1b.0/sound/card0/input10
[    7.337122] input: HDA Intel Line Out at Ext Rear Jack as /devices/pci0000:00/0000:00:1b.0/sound/card0/input11
[    7.337174] input: HDA Intel Line Out at Ext Rear Jack as /devices/pci0000:00/0000:00:1b.0/sound/card0/input12
[    7.393077] tuner 5-004b: chip found @ 0x96 (saa7133[0])
--
[   18.789013] tda1004x: found firmware revision 29 -- ok
[   18.951567] saa7134 ALSA driver for DMA sound loaded
[   18.951579] IRQ 22/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs



[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: alsactl adds volume controls?

[Raymond Yau]

2010/10/4 Colin Guthrie <gmane@colin.guthr.ie>

> 'Twas brillig, and Raymond Yau at 04/10/10 12:09 did gyre and gimble:
> > 2010/10/1 Clemens Ladisch <clemens@ladisch.de>
> >
> >> Takashi Iwai wrote:
> >>> Mark Brown wrote:
> >>>> On Thu, Sep 30, 2010 at 04:09:56PM +0100, Colin Guthrie wrote:
> >>>>> *shouldn't* use them, but at present it does and they *are* active
> >> and
> >>>>> used, so it's not an issue for me), the problem is rather one of
> >> setting
> >>>>> Master (not PCM) to 0% aka -46.5dB causes some kind of auto-mute that
> >>>>> cuts off all sound. It shouldn't do that.
> >>>>
> >>>> Is this perhaps just an error in the TLV information - should it be
> >>>> flagging that the minimim gain is mute but isn't?
> >>>
> >>> There is no clear (or consistent) definition in HD-audio codec, I
> guess.
> >>
> >> The HDA spec is quite clear that muting is done only with the mute bit.
> >>
> >>> Some chips do mute at 0 and some not.
> >>
> >> Those that do are violating the specification.
> >>
> >> But we have to support them anyway.
> >> Colin, please tell us the IDs of your codec so that we can add a TLV
> >> workaround to the driver.
> >>
> >>
> >> Regards,
> >> Clemens
> >>
> >>
> > Actually, the softvol plugin behave as the same way as Colin describe
> since
> > when the resolution is 2 , the softvol become a mute switch
> >
> >
> http://git.alsa-project.org/?p=alsa-lib.git;a=commit;h=f78af4ab0412052aabb74c9122a8d8f3ab6d45e6
> >
> > So the question is why -51dB is selected as min_dB
> >
> > Is this value enough for S16_LE or  S32_LE for hda-intel ?
> >
> >
> http://git.alsa-project.org/?p=alsa-kernel.git;a=commitdiff;h=eacbb9dba6b4c982a0217ea2c7d15db88d4fda37;hp=d91b424d6d7bda0773b6b6b606d48d089c4f5115
> >
> > As those DACs support -120dB to 0dB , but the driver can actually limit
> the
> > dB range to -60dB to 0dB . so the minimum volume -60dB is definitly not
> mute
> > in this case
> >
> > why -60dB is selected  ?
>
>
> Just for clarity, the 0 -> -51dB range is for the PCM control (i.e.
> softvol) only. The Master control gives me -46.5dB in addtiion to that
> giving a total of -97.5dB. This still isn't as high as the -120dB you
> are mentioning, but it's a lot closer.
>
> Of course I am lucky in that my Master apparently works fine but for
> those souls without any Master control, I presume the full range should
> be offered by the PCM softvol?
>
> Col
>
>
Did it happen on both channels or only left channel ?

The workaround mentioned in errata is to lock the sample rate

Re: alsactl adds volume controls?

[Colin Guthrie]

'Twas brillig, and Raymond Yau at 06/10/10 01:05 did gyre and gimble:
> 2010/10/4 Colin Guthrie <gmane@colin.guthr.ie>
>> Just for clarity, the 0 -> -51dB range is for the PCM control (i.e.
>> softvol) only. The Master control gives me -46.5dB in addtiion to that
>> giving a total of -97.5dB. This still isn't as high as the -120dB you
>> are mentioning, but it's a lot closer.
>>
>> Of course I am lucky in that my Master apparently works fine but for
>> those souls without any Master control, I presume the full range should
>> be offered by the PCM softvol?
>>
>> Col
>>
>>
> Did it happen on both channels or only left channel ?
> 
> The workaround mentioned in errata is to lock the sample rate

Did what happen? I was talking about dB ranges, not an event.

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

Re: alsactl adds volume controls?

[Clemens Ladisch]

Please try this patch.

--- a/sound/pci/hda/patch_sigmatel.c
+++ b/sound/pci/hda/patch_sigmatel.c
@@ -606,6 +606,24 @@ static hda_nid_t stac9205_pin_nids[12] = {
 	0x21, 0x22,
 };
 
+static int stac92xx_minmute_volume_tlv(struct snd_kcontrol *control,
+				       int op_flag, unsigned int size,
+				       unsigned int __user *_tlv)
+{
+	int ret;
+	unsigned int val;
+
+	ret = snd_hda_mixer_amp_tlv(control, op_flag, size, _tlv);
+	if (ret >= 0) {
+		if (get_user(val, _tlv + 3))
+			return -EFAULT;
+		val |= 0x10000; /* min is mute */
+		if (put_user(val, _tlv + 3))
+			return -EFAULT;
+	}
+	return ret;
+}
+
 static int stac92xx_dmux_enum_info(struct snd_kcontrol *kcontrol,
 				   struct snd_ctl_elem_info *uinfo)
 {
@@ -959,6 +977,21 @@ static struct hda_verb stac9205_core_init[] = {
 	{}
 };
 
+#define STAC_MINMUTE_VOLUME(xname, xnid) \
+	{ \
+		.iface = SNDRV_CTL_ELEM_IFACE_MIXER, \
+		.name = xname, \
+		.subdevice = HDA_SUBDEV_AMP_FLAG, \
+		.access = SNDRV_CTL_ELEM_ACCESS_READWRITE | \
+			  SNDRV_CTL_ELEM_ACCESS_TLV_READ | \
+			  SNDRV_CTL_ELEM_ACCESS_TLV_CALLBACK, \
+		.info = snd_hda_mixer_amp_volume_info, \
+		.get = snd_hda_mixer_amp_volume_get, \
+		.put = snd_hda_mixer_amp_volume_put, \
+		.tlv = { .c = stac92xx_minmute_volume_tlv }, \
+		.private_value = HDA_COMPOSE_AMP_VAL(xnid, 3, 0, HDA_OUTPUT), \
+	}
+
 #define STAC_MONO_MUX \
 	{ \
 		.iface = SNDRV_CTL_ELEM_IFACE_MIXER, \
@@ -992,7 +1025,7 @@ static struct hda_verb stac9205_core_init[] = {
 	}
 
 static struct snd_kcontrol_new stac9200_mixer[] = {
-	HDA_CODEC_VOLUME("Master Playback Volume", 0xb, 0, HDA_OUTPUT),
+	STAC_MINMUTE_VOLUME("Master Playback Volume", 0xb),
 	HDA_CODEC_MUTE("Master Playback Switch", 0xb, 0, HDA_OUTPUT),
 	HDA_CODEC_VOLUME("Capture Volume", 0x0a, 0, HDA_OUTPUT),
 	HDA_CODEC_MUTE("Capture Switch", 0x0a, 0, HDA_OUTPUT),

Re: alsactl adds volume controls?

[Colin Guthrie]

'Twas brillig, and Clemens Ladisch at 07/10/10 09:05 did gyre and gimble:
> Please try this patch.
> 
> --- a/sound/pci/hda/patch_sigmatel.c
> +++ b/sound/pci/hda/patch_sigmatel.c
> @@ -606,6 +606,24 @@ static hda_nid_t stac9205_pin_nids[12] = {
>  	0x21, 0x22,
>  };
>  
> +static int stac92xx_minmute_volume_tlv(struct snd_kcontrol *control,
> +				       int op_flag, unsigned int size,
> +				       unsigned int __user *_tlv)
> +{
> +	int ret;
> +	unsigned int val;
> +
> +	ret = snd_hda_mixer_amp_tlv(control, op_flag, size, _tlv);
> +	if (ret >= 0) {
> +		if (get_user(val, _tlv + 3))
> +			return -EFAULT;
> +		val |= 0x10000; /* min is mute */
> +		if (put_user(val, _tlv + 3))
> +			return -EFAULT;
> +	}
> +	return ret;
> +}
> +
>  static int stac92xx_dmux_enum_info(struct snd_kcontrol *kcontrol,
>  				   struct snd_ctl_elem_info *uinfo)
>  {
> @@ -959,6 +977,21 @@ static struct hda_verb stac9205_core_init[] = {
>  	{}
>  };
>  
> +#define STAC_MINMUTE_VOLUME(xname, xnid) \
> +	{ \
> +		.iface = SNDRV_CTL_ELEM_IFACE_MIXER, \
> +		.name = xname, \
> +		.subdevice = HDA_SUBDEV_AMP_FLAG, \
> +		.access = SNDRV_CTL_ELEM_ACCESS_READWRITE | \
> +			  SNDRV_CTL_ELEM_ACCESS_TLV_READ | \
> +			  SNDRV_CTL_ELEM_ACCESS_TLV_CALLBACK, \
> +		.info = snd_hda_mixer_amp_volume_info, \
> +		.get = snd_hda_mixer_amp_volume_get, \
> +		.put = snd_hda_mixer_amp_volume_put, \
> +		.tlv = { .c = stac92xx_minmute_volume_tlv }, \
> +		.private_value = HDA_COMPOSE_AMP_VAL(xnid, 3, 0, HDA_OUTPUT), \
> +	}
> +
>  #define STAC_MONO_MUX \
>  	{ \
>  		.iface = SNDRV_CTL_ELEM_IFACE_MIXER, \
> @@ -992,7 +1025,7 @@ static struct hda_verb stac9205_core_init[] = {
>  	}
>  
>  static struct snd_kcontrol_new stac9200_mixer[] = {
> -	HDA_CODEC_VOLUME("Master Playback Volume", 0xb, 0, HDA_OUTPUT),
> +	STAC_MINMUTE_VOLUME("Master Playback Volume", 0xb),
>  	HDA_CODEC_MUTE("Master Playback Switch", 0xb, 0, HDA_OUTPUT),
>  	HDA_CODEC_VOLUME("Capture Volume", 0x0a, 0, HDA_OUTPUT),
>  	HDA_CODEC_MUTE("Capture Switch", 0x0a, 0, HDA_OUTPUT),


Seemed to do something. Now, rather than printing -46.5dB then the
Master slider is down at 0, it prints "mute".

Is this the extent of the fix? i.e. to correctly report that the bottom
value is muted?

If so, then is there a way to tell this via an API so that I can tell PA
to not control the slider down to it's 0 value in order to avoid the
auto mute?

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

Re: alsactl adds volume controls?

[Clemens Ladisch]

Colin Guthrie wrote:
> 'Twas brillig, and Clemens Ladisch at 07/10/10 09:05 did gyre and gimble:
> > Please try this patch.
> > 
> > +++ b/sound/pci/hda/patch_sigmatel.c
> > ...
> 
> Seemed to do something. Now, rather than printing -46.5dB then the
> Master slider is down at 0, it prints "mute".
> 
> Is this the extent of the fix? i.e. to correctly report that the bottom
> value is muted?

Yes.

> If so, then is there a way to tell this via an API so that I can tell PA
> to not control the slider down to it's 0 value in order to avoid the
> auto mute?

Alsamixer uses the standard dB information that should also be used by PA.


Regards,
Clemens

Re: alsactl adds volume controls?

[Colin Guthrie]

'Twas brillig, and Clemens Ladisch at 08/10/10 14:41 did gyre and gimble:
> Colin Guthrie wrote:
>> 'Twas brillig, and Clemens Ladisch at 07/10/10 09:05 did gyre and gimble:
>>> Please try this patch.
>>>
>>> +++ b/sound/pci/hda/patch_sigmatel.c
>>> ...
>>
>> Seemed to do something. Now, rather than printing -46.5dB then the
>> Master slider is down at 0, it prints "mute".
>>
>> Is this the extent of the fix? i.e. to correctly report that the bottom
>> value is muted?
> 
> Yes.

Cool.

>> If so, then is there a way to tell this via an API so that I can tell PA
>> to not control the slider down to it's 0 value in order to avoid the
>> auto mute?
> 
> Alsamixer uses the standard dB information that should also be used by PA.

I think something in there is busted, but it's likely at the PA end.

This is the debug from a volume that is ultimately less than the min dB
(i.e. ~50dB or there about - certainly more attenuation than -46.5dB) (I
should really make it so it prints the dB volume here too)

D: alsa-sink.c: Requested volume: 0:  13% 1:  13%
D: alsa-sink.c: Got hardware volume: 0:   0% 1:   0%
D: alsa-sink.c: Calculated software volume: 0:   0% 1:   0%
(accurate-enough=no)

And here is something for ~40dB:

D: alsa-sink.c: Requested volume: 0:  19% 1:  19%
D: alsa-sink.c: Got hardware volume: 0:  19% 1:  19%
D: alsa-sink.c: Calculated software volume: 0:  99% 1:  99%
(accurate-enough=yes)

In this case the accurate-enough checks succeed vs before when they fail.


D: alsa-mixer.c: Activating path analog-output
D: alsa-mixer.c: Path analog-output (Analog Output), direction=1,
priority=99, probed=yes, supported=yes, has_mute=yes, has_volume=yes,
has_dB=yes, min_volume=0, max_volume=31, min_dB=-97.5, max_dB=0
D: alsa-mixer.c: Element Master, direction=1, switch=1, volume=1,
enumeration=0, required=0, required_absent=0, mask=0x3600000000f66,
n_channels=2, override_map=yes
D: alsa-mixer.c: Element PCM, direction=1, switch=0, volume=1,
enumeration=0, required=0, required_absent=0, mask=0x3600000000f66,
n_channels=2, override_map=yes
I: alsa-sink.c: Hardware volume ranges from -97.50 dB to 0.00 dB.
I: alsa-sink.c: No particular base volume set, fixing to 0 dB
I: alsa-sink.c: Using hardware volume control. Hardware dB scale supported.
I: alsa-sink.c: Using hardware mute control.
D: alsa-util.c: snd_pcm_dump():
D: alsa-util.c: Soft volume PCM
D: alsa-util.c: Control: PCM Playback Volume
D: alsa-util.c: min_dB: -51
D: alsa-util.c: max_dB: 0
D: alsa-util.c: resolution: 256
D: alsa-util.c: Its setup is:
D: alsa-util.c:   stream       : PLAYBACK
D: alsa-util.c:   access       : MMAP_INTERLEAVED
D: alsa-util.c:   format       : S16_LE
D: alsa-util.c:   subformat    : STD
D: alsa-util.c:   channels     : 2
D: alsa-util.c:   rate         : 44100
D: alsa-util.c:   exact rate   : 44100 (44100/1)
D: alsa-util.c:   msbits       : 16
D: alsa-util.c:   buffer_size  : 16384
D: alsa-util.c:   period_size  : 8192
D: alsa-util.c:   period_time  : 185759
D: alsa-util.c:   tstamp_mode  : ENABLE
D: alsa-util.c:   period_step  : 1
D: alsa-util.c:   avail_min    : 15502
D: alsa-util.c:   period_event : 0
D: alsa-util.c:   start_threshold  : -1
D: alsa-util.c:   stop_threshold   : 4611686018427387904
D: alsa-util.c:   silence_threshold: 0
D: alsa-util.c:   silence_size : 0
D: alsa-util.c:   boundary     : 4611686018427387904
D: alsa-util.c: Slave: Hardware PCM card 1 'HDA Intel' device 0 subdevice 0
D: alsa-util.c: Its setup is:
D: alsa-util.c:   stream       : PLAYBACK
D: alsa-util.c:   access       : MMAP_INTERLEAVED
D: alsa-util.c:   format       : S16_LE
D: alsa-util.c:   subformat    : STD
D: alsa-util.c:   channels     : 2
D: alsa-util.c:   rate         : 44100
D: alsa-util.c:   exact rate   : 44100 (44100/1)
D: alsa-util.c:   msbits       : 16
D: alsa-util.c:   buffer_size  : 16384
D: alsa-util.c:   period_size  : 8192
D: alsa-util.c:   period_time  : 185759
D: alsa-util.c:   tstamp_mode  : ENABLE
D: alsa-util.c:   period_step  : 1
D: alsa-util.c:   avail_min    : 15502
D: alsa-util.c:   period_event : 0
D: alsa-util.c:   start_threshold  : -1
D: alsa-util.c:   stop_threshold   : 4611686018427387904
D: alsa-util.c:   silence_threshold: 0
D: alsa-util.c:   silence_size : 0
D: alsa-util.c:   boundary     : 4611686018427387904
D: alsa-util.c:   appl_ptr     : 0
D: alsa-util.c:   hw_ptr       : 0




I'll try and work out why PA still insists on setting Master to 0 aka
-99999.99dB :D

Many thanks for the patch.

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

Re: alsactl adds volume controls?

[Colin Guthrie]

'Twas brillig, and Colin Guthrie at 08/10/10 15:05 did gyre and gimble:
> 'Twas brillig, and Clemens Ladisch at 08/10/10 14:41 did gyre and gimble:
>> Colin Guthrie wrote:
>>> 'Twas brillig, and Clemens Ladisch at 07/10/10 09:05 did gyre and gimble:
>>>> Please try this patch.
>>>>
>>>> +++ b/sound/pci/hda/patch_sigmatel.c
>>>> ...
>>>
>>> Seemed to do something. Now, rather than printing -46.5dB then the
>>> Master slider is down at 0, it prints "mute".
>>>
>>> Is this the extent of the fix? i.e. to correctly report that the bottom
>>> value is muted?
>>
>> Yes.
> 
> Cool.
> 
>>> If so, then is there a way to tell this via an API so that I can tell PA
>>> to not control the slider down to it's 0 value in order to avoid the
>>> auto mute?
>>
>> Alsamixer uses the standard dB information that should also be used by PA.
> 
> I think something in there is busted, but it's likely at the PA end.
> 
> This is the debug from a volume that is ultimately less than the min dB
> (i.e. ~50dB or there about - certainly more attenuation than -46.5dB) (I
> should really make it so it prints the dB volume here too)
> 
> D: alsa-sink.c: Requested volume: 0:  13% 1:  13%
> D: alsa-sink.c: Got hardware volume: 0:   0% 1:   0%
> D: alsa-sink.c: Calculated software volume: 0:   0% 1:   0%
> (accurate-enough=no)
> 
> And here is something for ~40dB:
> 
> D: alsa-sink.c: Requested volume: 0:  19% 1:  19%
> D: alsa-sink.c: Got hardware volume: 0:  19% 1:  19%
> D: alsa-sink.c: Calculated software volume: 0:  99% 1:  99%
> (accurate-enough=yes)
> 
> In this case the accurate-enough checks succeed vs before when they fail.
> 
> 
> D: alsa-mixer.c: Activating path analog-output
> D: alsa-mixer.c: Path analog-output (Analog Output), direction=1,
> priority=99, probed=yes, supported=yes, has_mute=yes, has_volume=yes,
> has_dB=yes, min_volume=0, max_volume=31, min_dB=-97.5, max_dB=0
> D: alsa-mixer.c: Element Master, direction=1, switch=1, volume=1,
> enumeration=0, required=0, required_absent=0, mask=0x3600000000f66,
> n_channels=2, override_map=yes
> D: alsa-mixer.c: Element PCM, direction=1, switch=0, volume=1,
> enumeration=0, required=0, required_absent=0, mask=0x3600000000f66,
> n_channels=2, override_map=yes
> I: alsa-sink.c: Hardware volume ranges from -97.50 dB to 0.00 dB.
> I: alsa-sink.c: No particular base volume set, fixing to 0 dB
> I: alsa-sink.c: Using hardware volume control. Hardware dB scale supported.
> I: alsa-sink.c: Using hardware mute control.
> D: alsa-util.c: snd_pcm_dump():
> D: alsa-util.c: Soft volume PCM
> D: alsa-util.c: Control: PCM Playback Volume
> D: alsa-util.c: min_dB: -51
> D: alsa-util.c: max_dB: 0
> D: alsa-util.c: resolution: 256
> D: alsa-util.c: Its setup is:
> D: alsa-util.c:   stream       : PLAYBACK
> D: alsa-util.c:   access       : MMAP_INTERLEAVED
> D: alsa-util.c:   format       : S16_LE
> D: alsa-util.c:   subformat    : STD
> D: alsa-util.c:   channels     : 2
> D: alsa-util.c:   rate         : 44100
> D: alsa-util.c:   exact rate   : 44100 (44100/1)
> D: alsa-util.c:   msbits       : 16
> D: alsa-util.c:   buffer_size  : 16384
> D: alsa-util.c:   period_size  : 8192
> D: alsa-util.c:   period_time  : 185759
> D: alsa-util.c:   tstamp_mode  : ENABLE
> D: alsa-util.c:   period_step  : 1
> D: alsa-util.c:   avail_min    : 15502
> D: alsa-util.c:   period_event : 0
> D: alsa-util.c:   start_threshold  : -1
> D: alsa-util.c:   stop_threshold   : 4611686018427387904
> D: alsa-util.c:   silence_threshold: 0
> D: alsa-util.c:   silence_size : 0
> D: alsa-util.c:   boundary     : 4611686018427387904
> D: alsa-util.c: Slave: Hardware PCM card 1 'HDA Intel' device 0 subdevice 0
> D: alsa-util.c: Its setup is:
> D: alsa-util.c:   stream       : PLAYBACK
> D: alsa-util.c:   access       : MMAP_INTERLEAVED
> D: alsa-util.c:   format       : S16_LE
> D: alsa-util.c:   subformat    : STD
> D: alsa-util.c:   channels     : 2
> D: alsa-util.c:   rate         : 44100
> D: alsa-util.c:   exact rate   : 44100 (44100/1)
> D: alsa-util.c:   msbits       : 16
> D: alsa-util.c:   buffer_size  : 16384
> D: alsa-util.c:   period_size  : 8192
> D: alsa-util.c:   period_time  : 185759
> D: alsa-util.c:   tstamp_mode  : ENABLE
> D: alsa-util.c:   period_step  : 1
> D: alsa-util.c:   avail_min    : 15502
> D: alsa-util.c:   period_event : 0
> D: alsa-util.c:   start_threshold  : -1
> D: alsa-util.c:   stop_threshold   : 4611686018427387904
> D: alsa-util.c:   silence_threshold: 0
> D: alsa-util.c:   silence_size : 0
> D: alsa-util.c:   boundary     : 4611686018427387904
> D: alsa-util.c:   appl_ptr     : 0
> D: alsa-util.c:   hw_ptr       : 0
> 
> 
> 
> 
> I'll try and work out why PA still insists on setting Master to 0 aka
> -99999.99dB :D
> 
> Many thanks for the patch.
> 
> Col
> 

Hmm, just thinking about this (as I don't know the volume control logic
particularly well in PA), the call snd_mixer_selem_set_playback_dB() is
used with a dir argument of +1.

>From what I understand, this would allow me to say "set the volume to
50dB" and due to the +1 dir, it should select -46.499999 ( because -46.5
mutes it).

In this case however, the value of -99999.999dB is ultimately selected
(aka 0).

I'm wondering if the TLV fix actually affects how
snd_mixer_selem_set_playback_dB() call works with the dir argument.

Am I way off base here or is it conceivable that this is still broken
even with your patch?

Col



-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

Re: alsactl adds volume controls?

[Clemens Ladisch]

Colin Guthrie wrote:
> Hmm, just thinking about this (as I don't know the volume control logic
> particularly well in PA), the call snd_mixer_selem_set_playback_dB() is
> used with a dir argument of +1.
> 
> From what I understand, this would allow me to say "set the volume to
> 50dB" and due to the +1 dir, it should select -46.499999 ( because -46.5
> mutes it).
> 
> In this case however, the value of -99999.999dB is ultimately selected
> (aka 0).
> 
> I'm wondering if the TLV fix actually affects how
> snd_mixer_selem_set_playback_dB() call works with the dir argument.

Uh, oh.  snd_tlv_convert_from_dB() ignores the minimum-is-mute flag.
Please try this hack:

--- alsa-lib/src/control/tlv.c
+++ alsa-lib/src/control/tlv.c
@@ -335,6 +335,9 @@ int snd_tlv_convert_from_dB(unsigned int *tlv, long rangemin, long rangemax,
 			if (xdir > 0)
 				v += (max - min) - 1;
 			v = v / (max - min) + rangemin;
+			if (v == rangemin && xdir > 0 && (tlv[3] & 0x10000) &&
+			    db_gain > SND_CTL_TLV_DB_GAIN_MUTE)
+				v++;
 			*value = v;
 		}
 		return 0;

Re: alsactl adds volume controls?

[Colin Guthrie]

'Twas brillig, and Clemens Ladisch at 08/10/10 15:42 did gyre and gimble:
> Colin Guthrie wrote:
>> Hmm, just thinking about this (as I don't know the volume control logic
>> particularly well in PA), the call snd_mixer_selem_set_playback_dB() is
>> used with a dir argument of +1.
>>
>> From what I understand, this would allow me to say "set the volume to
>> 50dB" and due to the +1 dir, it should select -46.499999 ( because -46.5
>> mutes it).
>>
>> In this case however, the value of -99999.999dB is ultimately selected
>> (aka 0).
>>
>> I'm wondering if the TLV fix actually affects how
>> snd_mixer_selem_set_playback_dB() call works with the dir argument.
> 
> Uh, oh.  snd_tlv_convert_from_dB() ignores the minimum-is-mute flag.

Ahh good, I analysed that kinda correctly then :D

> Please try this hack:
> 
> --- alsa-lib/src/control/tlv.c
> +++ alsa-lib/src/control/tlv.c
> @@ -335,6 +335,9 @@ int snd_tlv_convert_from_dB(unsigned int *tlv, long rangemin, long rangemax,
>  			if (xdir > 0)
>  				v += (max - min) - 1;
>  			v = v / (max - min) + rangemin;
> +			if (v == rangemin && xdir > 0 && (tlv[3] & 0x10000) &&
> +			    db_gain > SND_CTL_TLV_DB_GAIN_MUTE)
> +				v++;
>  			*value = v;
>  		}
>  		return 0;


Didn't help sadly, but then looking at the code there it seems a little odd.

Firstly I tried this (extended) patch - I'm not sure it's needed but
when the first one didn't work I tried to experiment a bit:

--- a/src/control/tlv.c
+++ b/src/control/tlv.c
@@ -323,15 +323,20 @@ int snd_tlv_convert_from_dB(unsigned int *tlv,
long rangemin, long rangemax,
                int min, max;
                min = tlv[2];
                max = tlv[3];
-               if (db_gain <= min)
+               if (db_gain <= min) {
                        *value = rangemin;
-               else if (db_gain >= max)
+                       if (xdir > 0 && (tlv[3] & 0x10000) && db_gain >
SND_CTL_TLV_DB_GAIN_MUTE)
+                               *value = rangemin + 1;
+               } else if (db_gain >= max)
                        *value = rangemax;
                else {
                        long v = (db_gain - min) * (rangemax - rangemin);
                        if (xdir > 0)
                                v += (max - min) - 1;
                        v = v / (max - min) + rangemin;
+                       if (v == rangemin && xdir > 0 && (tlv[3] &
0x10000) &&
+                           db_gain > SND_CTL_TLV_DB_GAIN_MUTE)
+                               v++;
                        *value = v;
                }
                return 0;


This also catches the case when I try to set the volume to e.g. -5000
(-50.00dB) as it is < min (which I presume is still -4650, but actually
didn't check) then it will be set to rangemin and no further checks are
done.

What is odd about this tho', is that the flag for min is mute (0x10000)
is checked on tlv[3] which is also used here for the "max" value.

Is the use of position 3 correct (both here and on the kernel side) or
perhaps the max line needs to be:

                max = (tlv[3] & 0xffff);

instead? Either way it didn't help, but I thought the strangeness with
the tlv[3] value was worth pointing out.

Many thanks for debugging this with me :)

Col

PS, happy to chat on IRC if you prefer - coling


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

Re: alsactl adds volume controls?

[Colin Guthrie]

'Twas brillig, and Colin Guthrie at 08/10/10 16:25 did gyre and gimble:
> 'Twas brillig, and Clemens Ladisch at 08/10/10 15:42 did gyre and gimble:
>> Colin Guthrie wrote:
>>> Hmm, just thinking about this (as I don't know the volume control logic
>>> particularly well in PA), the call snd_mixer_selem_set_playback_dB() is
>>> used with a dir argument of +1.
>>>
>>> From what I understand, this would allow me to say "set the volume to
>>> 50dB" and due to the +1 dir, it should select -46.499999 ( because -46.5
>>> mutes it).
>>>
>>> In this case however, the value of -99999.999dB is ultimately selected
>>> (aka 0).
>>>
>>> I'm wondering if the TLV fix actually affects how
>>> snd_mixer_selem_set_playback_dB() call works with the dir argument.
>>
>> Uh, oh.  snd_tlv_convert_from_dB() ignores the minimum-is-mute flag.
> 
> Ahh good, I analysed that kinda correctly then :D
> 
>> Please try this hack:
>>
>> --- alsa-lib/src/control/tlv.c
>> +++ alsa-lib/src/control/tlv.c
>> @@ -335,6 +335,9 @@ int snd_tlv_convert_from_dB(unsigned int *tlv, long rangemin, long rangemax,
>>  			if (xdir > 0)
>>  				v += (max - min) - 1;
>>  			v = v / (max - min) + rangemin;
>> +			if (v == rangemin && xdir > 0 && (tlv[3] & 0x10000) &&
>> +			    db_gain > SND_CTL_TLV_DB_GAIN_MUTE)
>> +				v++;
>>  			*value = v;
>>  		}
>>  		return 0;
> 
> 
> Didn't help sadly, but then looking at the code there it seems a little odd.
> 
> Firstly I tried this (extended) patch - I'm not sure it's needed but
> when the first one didn't work I tried to experiment a bit:
> 
> --- a/src/control/tlv.c
> +++ b/src/control/tlv.c
> @@ -323,15 +323,20 @@ int snd_tlv_convert_from_dB(unsigned int *tlv,
> long rangemin, long rangemax,
>                 int min, max;
>                 min = tlv[2];
>                 max = tlv[3];
> -               if (db_gain <= min)
> +               if (db_gain <= min) {
>                         *value = rangemin;
> -               else if (db_gain >= max)
> +                       if (xdir > 0 && (tlv[3] & 0x10000) && db_gain >
> SND_CTL_TLV_DB_GAIN_MUTE)
> +                               *value = rangemin + 1;
> +               } else if (db_gain >= max)
>                         *value = rangemax;
>                 else {
>                         long v = (db_gain - min) * (rangemax - rangemin);
>                         if (xdir > 0)
>                                 v += (max - min) - 1;
>                         v = v / (max - min) + rangemin;
> +                       if (v == rangemin && xdir > 0 && (tlv[3] &
> 0x10000) &&
> +                           db_gain > SND_CTL_TLV_DB_GAIN_MUTE)
> +                               v++;
>                         *value = v;
>                 }
>                 return 0;
> 
> 
> This also catches the case when I try to set the volume to e.g. -5000
> (-50.00dB) as it is < min (which I presume is still -4650, but actually
> didn't check) then it will be set to rangemin and no further checks are
> done.
> 
> What is odd about this tho', is that the flag for min is mute (0x10000)
> is checked on tlv[3] which is also used here for the "max" value.
> 
> Is the use of position 3 correct (both here and on the kernel side) or
> perhaps the max line needs to be:
> 
>                 max = (tlv[3] & 0xffff);
> 
> instead? Either way it didn't help, but I thought the strangeness with
> the tlv[3] value was worth pointing out.
> 
> Many thanks for debugging this with me :)
> 
> Col
> 
> PS, happy to chat on IRC if you prefer - coling

Ignore this mail... I applied the patch to the wrong tree and it put the
hunks in a different place as the context was a 100% match...

I'll retest with this applied correctly! Sorry :D

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

Re: alsactl adds volume controls?

[Colin Guthrie]

[-- Attachment #1: Type: text/plain, Size: 4527 bytes --]

'Twas brillig, and Colin Guthrie at 08/10/10 16:29 did gyre and gimble:
> 'Twas brillig, and Colin Guthrie at 08/10/10 16:25 did gyre and gimble:
>> 'Twas brillig, and Clemens Ladisch at 08/10/10 15:42 did gyre and gimble:
>>> Colin Guthrie wrote:
>>>> Hmm, just thinking about this (as I don't know the volume control logic
>>>> particularly well in PA), the call snd_mixer_selem_set_playback_dB() is
>>>> used with a dir argument of +1.
>>>>
>>>> From what I understand, this would allow me to say "set the volume to
>>>> 50dB" and due to the +1 dir, it should select -46.499999 ( because -46.5
>>>> mutes it).
>>>>
>>>> In this case however, the value of -99999.999dB is ultimately selected
>>>> (aka 0).
>>>>
>>>> I'm wondering if the TLV fix actually affects how
>>>> snd_mixer_selem_set_playback_dB() call works with the dir argument.
>>>
>>> Uh, oh.  snd_tlv_convert_from_dB() ignores the minimum-is-mute flag.
>>
>> Ahh good, I analysed that kinda correctly then :D
>>
>>> Please try this hack:
>>>
>>> --- alsa-lib/src/control/tlv.c
>>> +++ alsa-lib/src/control/tlv.c
>>> @@ -335,6 +335,9 @@ int snd_tlv_convert_from_dB(unsigned int *tlv, long rangemin, long rangemax,
>>>  			if (xdir > 0)
>>>  				v += (max - min) - 1;
>>>  			v = v / (max - min) + rangemin;
>>> +			if (v == rangemin && xdir > 0 && (tlv[3] & 0x10000) &&
>>> +			    db_gain > SND_CTL_TLV_DB_GAIN_MUTE)
>>> +				v++;
>>>  			*value = v;
>>>  		}
>>>  		return 0;
>>
>>
>> Didn't help sadly, but then looking at the code there it seems a little odd.
>>
>> Firstly I tried this (extended) patch - I'm not sure it's needed but
>> when the first one didn't work I tried to experiment a bit:
>>
>> --- a/src/control/tlv.c
>> +++ b/src/control/tlv.c
>> @@ -323,15 +323,20 @@ int snd_tlv_convert_from_dB(unsigned int *tlv,
>> long rangemin, long rangemax,
>>                 int min, max;
>>                 min = tlv[2];
>>                 max = tlv[3];
>> -               if (db_gain <= min)
>> +               if (db_gain <= min) {
>>                         *value = rangemin;
>> -               else if (db_gain >= max)
>> +                       if (xdir > 0 && (tlv[3] & 0x10000) && db_gain >
>> SND_CTL_TLV_DB_GAIN_MUTE)
>> +                               *value = rangemin + 1;
>> +               } else if (db_gain >= max)
>>                         *value = rangemax;
>>                 else {
>>                         long v = (db_gain - min) * (rangemax - rangemin);
>>                         if (xdir > 0)
>>                                 v += (max - min) - 1;
>>                         v = v / (max - min) + rangemin;
>> +                       if (v == rangemin && xdir > 0 && (tlv[3] &
>> 0x10000) &&
>> +                           db_gain > SND_CTL_TLV_DB_GAIN_MUTE)
>> +                               v++;
>>                         *value = v;
>>                 }
>>                 return 0;
>>
>>
>> This also catches the case when I try to set the volume to e.g. -5000
>> (-50.00dB) as it is < min (which I presume is still -4650, but actually
>> didn't check) then it will be set to rangemin and no further checks are
>> done.
>>
>> What is odd about this tho', is that the flag for min is mute (0x10000)
>> is checked on tlv[3] which is also used here for the "max" value.
>>
>> Is the use of position 3 correct (both here and on the kernel side) or
>> perhaps the max line needs to be:
>>
>>                 max = (tlv[3] & 0xffff);
>>
>> instead? Either way it didn't help, but I thought the strangeness with
>> the tlv[3] value was worth pointing out.
>>
>> Many thanks for debugging this with me :)
>>
>> Col
>>
>> PS, happy to chat on IRC if you prefer - coling
> 
> Ignore this mail... I applied the patch to the wrong tree and it put the
> hunks in a different place as the context was a 100% match...
> 
> I'll retest with this applied correctly! Sorry :D

OK, applying the patch correctly helps a lot :D

This is now working perfectly thanks.

I've attached the final patch I used. I modified your one slightly to
correct case when passing in a value that is <= min (e.g. -5000dB on my
setup) to also fix that up. As I'm not 100% sure it's needed, I'll leave
it up to you to decide which patch to apply.

Many thanks once again.

Col




-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

[-- Attachment #2: 0103-tlv-Ensure-that-min-is-mute-flag-is-honored-in-snd_t.patch --]
[-- Type: text/plain, Size: 1482 bytes --]

From 3a8e7005a980bcbdca7c56b2c236ecbcb6b0b7ca Mon Sep 17 00:00:00 2001
From: Colin Guthrie <cguthrie@mandriva.org>
Date: Fri, 8 Oct 2010 16:46:43 +0100
Subject: [PATCH] tlv: Ensure that min-is-mute flag is honored in snd_tlv_convert_from_dB()

Thanks to Clemens Ladisch for identifying the issue and the original patch.
Discussion here: http://thread.gmane.org/gmane.linux.alsa.devel/77688
---
 src/control/tlv.c |   21 +++++++++++++--------
 1 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/src/control/tlv.c b/src/control/tlv.c
index ba52752..d525f29 100644
--- a/src/control/tlv.c
+++ b/src/control/tlv.c
@@ -326,16 +326,21 @@ int snd_tlv_convert_from_dB(unsigned int *tlv, long rangemin, long rangemax,
 		min = tlv[2];
 		step = (tlv[3] & 0xffff);
 		max = min + (int)(step * (rangemax - rangemin));
-		if (db_gain <= min)
-			*value = rangemin;
-		else if (db_gain >= max)
+		if (db_gain >= max)
 			*value = rangemax;
 		else {
-			long v = (db_gain - min) * (rangemax - rangemin);
-			if (xdir > 0)
-				v += (max - min) - 1;
-			v = v / (max - min) + rangemin;
-			*value = v;
+			if (db_gain <= min)
+				*value = rangemin;
+			else {
+				long v = (db_gain - min) * (rangemax - rangemin);
+				if (xdir > 0)
+					v += (max - min) - 1;
+				v = v / (max - min) + rangemin;
+				*value = v;
+			}
+			if (*value == rangemin && xdir > 0 && (tlv[3] & 0x10000) &&
+			    db_gain > SND_CTL_TLV_DB_GAIN_MUTE)
+				(*value)++;
 		}
 		return 0;
 	}
-- 
1.7.3.1


[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: alsactl adds volume controls?

[Clemens Ladisch]

Colin Guthrie wrote:
> What is odd about this tho', is that the flag for min is mute (0x10000)
> is checked on tlv[3] which is also used here for the "max" value.

SND_CTL_TLVT_DB_SCALE uses a flag in tlv[3] to indicate min-is-mute, but
SND_CTL_TLVT_DB_MINMAX has a variant SND_CTL_TLVT_DB_MINMAX_MUTE.
(The HDA driver uses DB_SCALE).

> +       if (db_gain <= min) {
>                 *value = rangemin;
> +               if (xdir > 0 && (tlv[3] & 0x10000) && db_gain > SND_CTL_TLV_DB_GAIN_MUTE)
> +                       *value = rangemin + 1;

This should go at the same place in the SND_CTL_TLVT_DB_SCALE branch.


Regards,
Clemens

Re: alsactl adds volume controls?

[Raymond Yau]

2010/10/8 Clemens Ladisch <clemens@ladisch.de>

> Colin Guthrie wrote:
> > What is odd about this tho', is that the flag for min is mute (0x10000)
> > is checked on tlv[3] which is also used here for the "max" value.
>
> SND_CTL_TLVT_DB_SCALE uses a flag in tlv[3] to indicate min-is-mute, but
> SND_CTL_TLVT_DB_MINMAX has a variant SND_CTL_TLVT_DB_MINMAX_MUTE.
> (The HDA driver uses DB_SCALE).
>
> > +       if (db_gain <= min) {
> >                 *value = rangemin;
> > +               if (xdir > 0 && (tlv[3] & 0x10000) && db_gain >
> SND_CTL_TLV_DB_GAIN_MUTE)
> > +                       *value = rangemin + 1;
>
> This should go at the same place in the SND_CTL_TLVT_DB_SCALE branch.
>
>
> Regards,
> Clemens
>


How about softvol plugin , the dB scale seem wrong, it alwaysl mute at
min_dB even if I change min_dB to -21 ?

> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>

Re: alsactl adds volume controls?

[Colin Guthrie]

'Twas brillig, and Raymond Yau at 11/10/10 02:34 did gyre and gimble:
> How about softvol plugin , the dB scale seem wrong, it alwaysl mute at
> min_dB even if I change min_dB to -21 ?

I would suspect that this needs fixed also. David's alsamixertest does
indeed report when PCM mutes at min, to identify this error case.

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

Re: alsactl adds volume controls?

[Raymond Yau]

2010/10/11 Colin Guthrie <gmane@colin.guthr.ie>

> 'Twas brillig, and Raymond Yau at 11/10/10 02:34 did gyre and gimble:
> > How about softvol plugin , the dB scale seem wrong, it alwaysl mute at
> > min_dB even if I change min_dB to -21 ?
>
> I would suspect that this needs fixed also. David's alsamixertest does
> indeed report when PCM mutes at min, to identify this error case.
>
> Col
>
>
if you look at the 16bits preset_dB_value table , the minimum value is not
zero and it is strange that it mute at min_dB -51dB

static const unsigned int preset_dB_value[PRESET_RESOLUTION] = {
	0x00b8, 0x00bd, 0x00c1, 0x00c5, 0x00ca, 0x00cf, 0x00d4, 0x00d9,
	0x00de, 0x00e3, 0x00e8, 0x00ed, 0x00f3, 0x00f9, 0x00fe, 0x0104,
	0x010a, 0x0111, 0x0117, 0x011e, 0x0124, 0x012b, 0x0132, 0x0139,
	0x0140, 0x0148, 0x0150, 0x0157, 0x015f, 0x0168, 0x0170, 0x0179,
	0x0181, 0x018a, 0x0194, 0x019d, 0x01a7, 0x01b0, 0x01bb, 0x01c5,
	0x01cf, 0x01da, 0x01e5, 0x01f1, 0x01fc, 0x0208, 0x0214, 0x0221,
	0x022d, 0x023a, 0x0248, 0x0255, 0x0263, 0x0271, 0x0280, 0x028f,
	0x029e, 0x02ae, 0x02be, 0x02ce, 0x02df, 0x02f0, 0x0301, 0x0313,
	0x0326, 0x0339, 0x034c, 0x035f, 0x0374, 0x0388, 0x039d, 0x03b3,
	0x03c9, 0x03df, 0x03f7, 0x040e, 0x0426, 0x043f, 0x0458, 0x0472,
	0x048d, 0x04a8, 0x04c4, 0x04e0, 0x04fd, 0x051b, 0x053a, 0x0559,
	0x0579, 0x0599, 0x05bb, 0x05dd, 0x0600, 0x0624, 0x0648, 0x066e,
	0x0694, 0x06bb, 0x06e3, 0x070c, 0x0737, 0x0762, 0x078e, 0x07bb,
	0x07e9, 0x0818, 0x0848, 0x087a, 0x08ac, 0x08e0, 0x0915, 0x094b,
	0x0982, 0x09bb, 0x09f5, 0x0a30, 0x0a6d, 0x0aab, 0x0aeb, 0x0b2c,
	0x0b6f, 0x0bb3, 0x0bf9, 0x0c40, 0x0c89, 0x0cd4, 0x0d21, 0x0d6f,
	0x0dbf, 0x0e11, 0x0e65, 0x0ebb, 0x0f12, 0x0f6c, 0x0fc8, 0x1026,
	0x1087, 0x10e9, 0x114e, 0x11b5, 0x121f, 0x128b, 0x12fa, 0x136b,
	0x13df, 0x1455, 0x14ce, 0x154a, 0x15c9, 0x164b, 0x16d0, 0x1758,
	0x17e4, 0x1872, 0x1904, 0x1999, 0x1a32, 0x1ace, 0x1b6e, 0x1c11,
	0x1cb9, 0x1d64, 0x1e13, 0x1ec7, 0x1f7e, 0x203a, 0x20fa, 0x21bf,
	0x2288, 0x2356, 0x2429, 0x2500, 0x25dd, 0x26bf, 0x27a6, 0x2892,
	0x2984, 0x2a7c, 0x2b79, 0x2c7c, 0x2d85, 0x2e95, 0x2fab, 0x30c7,
	0x31ea, 0x3313, 0x3444, 0x357c, 0x36bb, 0x3801, 0x394f, 0x3aa5,
	0x3c02, 0x3d68, 0x3ed6, 0x404d, 0x41cd, 0x4355, 0x44e6, 0x4681,
	0x4826, 0x49d4, 0x4b8c, 0x4d4f, 0x4f1c, 0x50f3, 0x52d6, 0x54c4,
	0x56be, 0x58c3, 0x5ad4, 0x5cf2, 0x5f1c, 0x6153, 0x6398, 0x65e9,
	0x6849, 0x6ab7, 0x6d33, 0x6fbf, 0x7259, 0x7503, 0x77bd, 0x7a87,
	0x7d61, 0x804d, 0x834a, 0x8659, 0x897a, 0x8cae, 0x8ff5, 0x934f,
	0x96bd, 0x9a40, 0x9dd8, 0xa185, 0xa548, 0xa922, 0xad13, 0xb11b,
	0xb53b, 0xb973, 0xbdc5, 0xc231, 0xc6b7, 0xcb58, 0xd014, 0xd4ed,
	0xd9e3, 0xdef6, 0xe428, 0xe978, 0xeee8, 0xf479, 0xfa2b, 0xffff,
}

Re: alsactl adds volume controls?

[Colin Guthrie]

'Twas brillig, and Colin Guthrie at 08/10/10 16:49 did gyre and gimble:
> I've attached the final patch I used. I modified your one slightly to
> correct case when passing in a value that is <= min (e.g. -5000dB on my
> setup) to also fix that up. As I'm not 100% sure it's needed, I'll leave
> it up to you to decide which patch to apply.
> 
> Many thanks once again.

Clemens, are you able to commit the two patches here (my modification of
your alsa-lib patch and your kernel patch).

Or should I resubmit them as new threads here for Takashi or Jaroslav to
commit? I suspect they are somewhat lost at the end of this thread.

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

Re: alsactl adds volume controls?

[Clemens Ladisch]

Colin Guthrie wrote:
> Clemens, are you able to commit the two patches here (my modification of
> your alsa-lib patch and your kernel patch).

I would be able to commit them, but I've rewritten them.
Please test again.


Regards,
Clemens

[PATCH 1/2] ALSA: HDA: Sigmatel: work around incorrect master muting

[Clemens Ladisch]

The HDA specification does not allow for a codec to mute itself just
because the volume is reduced, so _of course_ somebody had to go and do
it.  This wouldn'\''t hurt too much when the volume is adjusted by hand,
but programs like PA that try to set the volume automatically could
inadvertently mute the output.

To work around this, change the TLV dB information for the Master volume
on all Sigmatel HDA codecs to indicate the the minimal volume setting
actually mutes.

Reported-by: Colin Guthrie <gmane@colin.guthr.ie>
Reported-by: "Alexander E. Patrakov" <patrakov@gmail.com>
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>

--- linux-2.6/sound/pci/hda/hda_local.h
+++ linux-2.6/sound/pci/hda/hda_local.h
@@ -38,10 +38,11 @@
  */
 #define HDA_COMPOSE_AMP_VAL_OFS(nid,chs,idx,dir,ofs)		\
 	((nid) | ((chs)<<16) | ((dir)<<18) | ((idx)<<19) | ((ofs)<<23))
+#define HDA_AMP_VAL_MIN_MUTE (1<<29)
 #define HDA_COMPOSE_AMP_VAL(nid,chs,idx,dir) \
 	HDA_COMPOSE_AMP_VAL_OFS(nid, chs, idx, dir, 0)
 /* mono volume with index (index=0,1,...) (channel=1,2) */
-#define HDA_CODEC_VOLUME_MONO_IDX(xname, xcidx, nid, channel, xindex, direction) \
+#define HDA_CODEC_VOLUME_MONO_IDX(xname, xcidx, nid, channel, xindex, dir, flags) \
 	{ .iface = SNDRV_CTL_ELEM_IFACE_MIXER, .name = xname, .index = xcidx,  \
 	  .subdevice = HDA_SUBDEV_AMP_FLAG, \
 	  .access = SNDRV_CTL_ELEM_ACCESS_READWRITE | \
@@ -51,16 +52,20 @@
 	  .get = snd_hda_mixer_amp_volume_get, \
 	  .put = snd_hda_mixer_amp_volume_put, \
 	  .tlv = { .c = snd_hda_mixer_amp_tlv },		\
-	  .private_value = HDA_COMPOSE_AMP_VAL(nid, channel, xindex, direction) }
+	  .private_value = HDA_COMPOSE_AMP_VAL(nid, channel, xindex, dir) | flags }
 /* stereo volume with index */
 #define HDA_CODEC_VOLUME_IDX(xname, xcidx, nid, xindex, direction) \
-	HDA_CODEC_VOLUME_MONO_IDX(xname, xcidx, nid, 3, xindex, direction)
+	HDA_CODEC_VOLUME_MONO_IDX(xname, xcidx, nid, 3, xindex, direction, 0)
 /* mono volume */
 #define HDA_CODEC_VOLUME_MONO(xname, nid, channel, xindex, direction) \
-	HDA_CODEC_VOLUME_MONO_IDX(xname, 0, nid, channel, xindex, direction)
+	HDA_CODEC_VOLUME_MONO_IDX(xname, 0, nid, channel, xindex, direction, 0)
 /* stereo volume */
 #define HDA_CODEC_VOLUME(xname, nid, xindex, direction) \
 	HDA_CODEC_VOLUME_MONO(xname, nid, 3, xindex, direction)
+/* stereo volume with min=mute */
+#define HDA_CODEC_VOLUME_MIN_MUTE(xname, nid, xindex, direction) \
+	HDA_CODEC_VOLUME_MONO_IDX(xname, 0, nid, 3, xindex, direction, \
+				  HDA_AMP_VAL_MIN_MUTE)
 /* mono mute switch with index (index=0,1,...) (channel=1,2) */
 #define HDA_CODEC_MUTE_MONO_IDX(xname, xcidx, nid, channel, xindex, direction) \
 	{ .iface = SNDRV_CTL_ELEM_IFACE_MIXER, .name = xname, .index = xcidx, \
@@ -581,6 +586,7 @@ int snd_hda_check_amp_list_power(struct
 #define get_amp_direction(kc)	(((kc)->private_value >> 18) & 0x1)
 #define get_amp_index(kc)	(((kc)->private_value >> 19) & 0xf)
 #define get_amp_offset(kc)	(((kc)->private_value >> 23) & 0x3f)
+#define get_amp_min_mute(kc)	(((kc)->private_value >> 29) & 0x1)
 
 /*
  * CEA Short Audio Descriptor data
--- linux-2.6/sound/pci/hda/hda_codec.c
+++ linux-2.6/sound/pci/hda/hda_codec.c
@@ -1831,6 +1831,7 @@ int snd_hda_mixer_amp_tlv(struct snd_kco
 	hda_nid_t nid = get_amp_nid(kcontrol);
 	int dir = get_amp_direction(kcontrol);
 	unsigned int ofs = get_amp_offset(kcontrol);
+	bool min_mute = get_amp_min_mute(kcontrol);
 	u32 caps, val1, val2;
 
 	if (size < 4 * sizeof(unsigned int))
@@ -1841,6 +1842,8 @@ int snd_hda_mixer_amp_tlv(struct snd_kco
 	val1 = -((caps & AC_AMPCAP_OFFSET) >> AC_AMPCAP_OFFSET_SHIFT);
 	val1 += ofs;
 	val1 = ((int)val1) * ((int)val2);
+	if (min_mute)
+		val2 |= 0x10000;
 	if (put_user(SNDRV_CTL_TLVT_DB_SCALE, _tlv))
 		return -EFAULT;
 	if (put_user(2 * sizeof(unsigned int), _tlv + 1))
--- linux-2.6/sound/pci/hda/patch_sigmatel.c
+++ linux-2.6/sound/pci/hda/patch_sigmatel.c
@@ -992,7 +992,7 @@ static struct hda_verb stac9205_core_ini
 	}
 
 static struct snd_kcontrol_new stac9200_mixer[] = {
-	HDA_CODEC_VOLUME("Master Playback Volume", 0xb, 0, HDA_OUTPUT),
+	HDA_CODEC_VOLUME_MIN_MUTE("Master Playback Volume", 0xb, 0, HDA_OUTPUT),
 	HDA_CODEC_MUTE("Master Playback Switch", 0xb, 0, HDA_OUTPUT),
 	HDA_CODEC_VOLUME("Capture Volume", 0x0a, 0, HDA_OUTPUT),
 	HDA_CODEC_MUTE("Capture Switch", 0x0a, 0, HDA_OUTPUT),
@@ -1020,7 +1020,7 @@ static struct snd_kcontrol_new stac92hd7
 };
 
 static struct snd_kcontrol_new stac925x_mixer[] = {
-	HDA_CODEC_VOLUME("Master Playback Volume", 0x0e, 0, HDA_OUTPUT),
+	HDA_CODEC_VOLUME_MIN_MUTE("Master Playback Volume", 0xe, 0, HDA_OUTPUT),
 	HDA_CODEC_MUTE("Master Playback Switch", 0x0e, 0, HDA_OUTPUT),
 	{ } /* end */
 };
@@ -1144,6 +1144,8 @@ static int stac92xx_build_controls(struc
 					HDA_OUTPUT, vmaster_tlv);
 		/* correct volume offset */
 		vmaster_tlv[2] += vmaster_tlv[3] * spec->volume_offset;
+		/* minimum value is actually mute */
+		vmaster_tlv[3] |= 0x1000;
 		err = snd_hda_add_vmaster(codec, "Master Playback Volume",
 					  vmaster_tlv, slave_vols);
 		if (err < 0)

[PATCH 2/2] tlv: fix returned dB information for min-is-mute controls

[Clemens Ladisch]

For TLV information that indicates that the minimum value is actually
muted, the returned range used the wrong minimum dB value, and
converting dB values to raw control values did not round up correctly
near the minimum.

Signed-off-by: Clemens Ladisch <clemens@ladisch.de>

--- alsa-lib/src/control/tlv.c
+++ alsa-lib/src/control/tlv.c
@@ -167,17 +167,23 @@ int snd_tlv_get_dB_range(unsigned int *t
 	}
 	case SND_CTL_TLVT_DB_SCALE: {
 		int step;
-		*min = (int)tlv[2];
+		if (tlv[3] & 0x10000)
+			*min = SND_CTL_TLV_DB_GAIN_MUTE;
+		else
+			*min = (int)tlv[2];
 		step = (tlv[3] & 0xffff);
-		*max = *min + (long)(step * (rangemax - rangemin));
+		*max = (int)tlv[2] + step * (rangemax - rangemin);
 		return 0;
 	}
 	case SND_CTL_TLVT_DB_MINMAX:
-	case SND_CTL_TLVT_DB_MINMAX_MUTE:
 	case SND_CTL_TLVT_DB_LINEAR:
 		*min = (int)tlv[2];
 		*max = (int)tlv[3];
 		return 0;
+	case SND_CTL_TLVT_DB_MINMAX_MUTE:
+		*min = SND_CTL_TLV_DB_GAIN_MUTE;
+		*max = (int)tlv[3];
+		return 0;
 	}
 	return -EINVAL;
 }
@@ -217,7 +223,7 @@ int snd_tlv_convert_to_dB(unsigned int *
 		min = tlv[2];
 		step = (tlv[3] & 0xffff);
 		mute = (tlv[3] >> 16) & 1;
-		if (mute && volume == rangemin)
+		if (mute && volume <= rangemin)
 			*db_gain = SND_CTL_TLV_DB_GAIN_MUTE;
 		else
 			*db_gain = (volume - rangemin) * step + min;
@@ -327,7 +333,11 @@ int snd_tlv_convert_from_dB(unsigned int
 		step = (tlv[3] & 0xffff);
 		max = min + (int)(step * (rangemax - rangemin));
 		if (db_gain <= min)
-			*value = rangemin;
+			if (db_gain > SND_CTL_TLV_DB_GAIN_MUTE && xdir > 0 &&
+			    (tlv[3] & 0x10000))
+				*value = rangemin + 1;
+			else
+				*value = rangemin;
 		else if (db_gain >= max)
 			*value = rangemax;
 		else {
@@ -345,7 +355,11 @@ int snd_tlv_convert_from_dB(unsigned int
 		min = tlv[2];
 		max = tlv[3];
 		if (db_gain <= min)
-			*value = rangemin;
+			if (db_gain > SND_CTL_TLV_DB_GAIN_MUTE && xdir > 0 &&
+			    tlv[0] == SND_CTL_TLVT_DB_MINMAX_MUTE)
+				*value = rangemin + 1;
+			else
+				*value = rangemin;
 		else if (db_gain >= max)
 			*value = rangemax;
 		else {

Re: alsactl adds volume controls?

[Colin Guthrie]

'Twas brillig, and Clemens Ladisch at 15/10/10 09:32 did gyre and gimble:
> Colin Guthrie wrote:
>> Clemens, are you able to commit the two patches here (my modification of
>> your alsa-lib patch and your kernel patch).
> 
> I would be able to commit them, but I've rewritten them.
> Please test again.

Sure thanks. I should be able to take a look over the weekend.

Cheers

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

Re: alsactl adds volume controls?

[Colin Guthrie]

'Twas brillig, and Colin Guthrie at 15/10/10 09:39 did gyre and gimble:
> 'Twas brillig, and Clemens Ladisch at 15/10/10 09:32 did gyre and gimble:
>> Colin Guthrie wrote:
>>> Clemens, are you able to commit the two patches here (my modification of
>>> your alsa-lib patch and your kernel patch).
>>
>> I would be able to commit them, but I've rewritten them.
>> Please test again.
> 
> Sure thanks. I should be able to take a look over the weekend.

Tested-by: Colin Guthrie <cguthrie@mandriva.org>

Tested and confirmed

Many thanks again.

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

Re: alsactl adds volume controls?

[Raymond Yau]

2010/10/8 Colin Guthrie <gmane@colin.guthr.ie>

> D: alsa-mixer.c: Activating path analog-output
> D: alsa-mixer.c: Path analog-output (Analog Output), direction=1,
> priority=99, probed=yes, supported=yes, has_mute=yes, has_volume=yes,
> has_dB=yes, min_volume=0, max_volume=31, min_dB=-97.5, max_dB=0
> D: alsa-mixer.c: Element Master, direction=1, switch=1, volume=1,
> enumeration=0, required=0, required_absent=0, mask=0x3600000000f66,
> n_channels=2, override_map=yes
> D: alsa-mixer.c: Element PCM, direction=1, switch=0, volume=1,
> enumeration=0, required=0, required_absent=0, mask=0x3600000000f66,
> n_channels=2, override_map=yes
> I: alsa-sink.c: Hardware volume ranges from -97.50 dB to 0.00 dB.
> I: alsa-sink.c: No particular base volume set, fixing to 0 dB
> I: alsa-sink.c: Using hardware volume control. Hardware dB scale supported.
> I: alsa-sink.c: Using hardware mute control.
>

If step 0 of the Master Volume control is SND_CTL_TLV_DB_GAIN_MUTE (i.e.
-99999dB) , step 1 is -45dB and step 31 is 0dB

does it mean that the mixer application can no longer rely on
snd_mixer_selem_get_playback_dB_range() to get the correct min dB at min
step from snd_mixer_selem_set_playback_volume_range() ?

the dB range of PCM soft is -51dB to 0dB

how do PA calculate the range -97.5dB to -dB as it is not possible to set
total dB value to -97.5dB any more ?

Re: alsactl adds volume controls?

[Takashi Iwai]

At Sat, 16 Oct 2010 16:49:21 +0100,
Colin Guthrie wrote:
> 
> 'Twas brillig, and Colin Guthrie at 15/10/10 09:39 did gyre and gimble:
> > 'Twas brillig, and Clemens Ladisch at 15/10/10 09:32 did gyre and gimble:
> >> Colin Guthrie wrote:
> >>> Clemens, are you able to commit the two patches here (my modification of
> >>> your alsa-lib patch and your kernel patch).
> >>
> >> I would be able to commit them, but I've rewritten them.
> >> Please test again.
> > 
> > Sure thanks. I should be able to take a look over the weekend.
> 
> Tested-by: Colin Guthrie <cguthrie@mandriva.org>
> 
> Tested and confirmed

Thanks for testing.
I applied Clemens' patch to sound git tree.
(And applied to alsa-lib, too.)

I guess there are still other codecs showing the same behavior.
I wonder whether other STAC/IDT codecs show the same behavior.
Will check some others in the next week.


Takashi

Re: alsactl adds volume controls?

[Colin Guthrie]

'Twas brillig, and Raymond Yau at 17/10/10 04:39 did gyre and gimble:
> 2010/10/8 Colin Guthrie <gmane@colin.guthr.ie>
> 
>> D: alsa-mixer.c: Activating path analog-output
>> D: alsa-mixer.c: Path analog-output (Analog Output), direction=1,
>> priority=99, probed=yes, supported=yes, has_mute=yes, has_volume=yes,
>> has_dB=yes, min_volume=0, max_volume=31, min_dB=-97.5, max_dB=0
>> D: alsa-mixer.c: Element Master, direction=1, switch=1, volume=1,
>> enumeration=0, required=0, required_absent=0, mask=0x3600000000f66,
>> n_channels=2, override_map=yes
>> D: alsa-mixer.c: Element PCM, direction=1, switch=0, volume=1,
>> enumeration=0, required=0, required_absent=0, mask=0x3600000000f66,
>> n_channels=2, override_map=yes
>> I: alsa-sink.c: Hardware volume ranges from -97.50 dB to 0.00 dB.
>> I: alsa-sink.c: No particular base volume set, fixing to 0 dB
>> I: alsa-sink.c: Using hardware volume control. Hardware dB scale supported.
>> I: alsa-sink.c: Using hardware mute control.
>>
> 
> If step 0 of the Master Volume control is SND_CTL_TLV_DB_GAIN_MUTE (i.e.
> -99999dB) , step 1 is -45dB and step 31 is 0dB
> 
> does it mean that the mixer application can no longer rely on
> snd_mixer_selem_get_playback_dB_range() to get the correct min dB at min
> step from snd_mixer_selem_set_playback_volume_range() ?
> 
> the dB range of PCM soft is -51dB to 0dB
> 
> how do PA calculate the range -97.5dB to -dB as it is not possible to set
> total dB value to -97.5dB any more ?

PA uses the call snd_mixer_selem_set_playback_dB() with a dir argument
of +1. This means that it wont go lower than the dB value it asks for.

After calling this, we check what the value really was set to then go on
and make further adjustment to other elements (e.g. PCM) to get the
needed accuracy. If all mixer elements are exhausted and the final dB
value is still not accurate enough, we do the remainder in software.

So while the range is "interesting", it's not absolutely essential as PA
will always extend the range in software when needed.

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

Re: alsactl adds volume controls?

[Colin Guthrie]

'Twas brillig, and Takashi Iwai at 17/10/10 09:50 did gyre and gimble:
> At Sat, 16 Oct 2010 16:49:21 +0100,
> Colin Guthrie wrote:
>>
>> 'Twas brillig, and Colin Guthrie at 15/10/10 09:39 did gyre and gimble:
>>> 'Twas brillig, and Clemens Ladisch at 15/10/10 09:32 did gyre and gimble:
>>>> Colin Guthrie wrote:
>>>>> Clemens, are you able to commit the two patches here (my modification of
>>>>> your alsa-lib patch and your kernel patch).
>>>>
>>>> I would be able to commit them, but I've rewritten them.
>>>> Please test again.
>>>
>>> Sure thanks. I should be able to take a look over the weekend.
>>
>> Tested-by: Colin Guthrie <cguthrie@mandriva.org>
>>
>> Tested and confirmed
> 
> Thanks for testing.
> I applied Clemens' patch to sound git tree.
> (And applied to alsa-lib, too.)
> 
> I guess there are still other codecs showing the same behavior.
> I wonder whether other STAC/IDT codecs show the same behavior.
> Will check some others in the next week.

Ahh fantastic. Thanks Takashi. Any help in fixing these volume range
issues is very much appreciated.

Thanks Clemens for kicking this off :)


Col
-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

Re: alsactl adds volume controls?

[Raymond Yau]

2010/8/27 Clemens Ladisch <clemens@ladisch.de>

> David Henningsson wrote:
> > So I've discovered that my sound card has a "PCM Playback Volume"
> > control, but changing that control does not alter the volume.
> >
> > Interestingly enough, this control does not come from the HDA parser, it
> > is added by alsactl at boot time...!
>
> This control was created by the software volume plugin.  When not using
> this plugin, the control does not have any effect.
>
> To get rid of it, delete its entry from /etc/asound.state.
>

May be the problem is related to those virtual Master Playback Volume /
Playback Switch

If the user has set the volume of slave controls to different level and use
alsactl to store the values in /etc/asound.state

Those slaves of the virtual master volumes are restored before the virtual
Master Volume
but the restore of virtual master volume set the volume control of all
slaves to same level

Is this the reason why kmix remove the left/right balance control ?

Re: alsactl adds volume controls?

[Colin Guthrie]

'Twas brillig, and Raymond Yau at 23/10/10 12:51 did gyre and gimble:
> Is this the reason why kmix remove the left/right balance control ?

Not sure what you mean by this... kmix can still control left and right
independently... just right click and chose "split channels".... but
perhaps I've misinterpreted what you are saying.

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

Re: alsactl adds volume controls?

[Raymond Yau]

2010/10/23 Colin Guthrie <gmane@colin.guthr.ie>

> 'Twas brillig, and Raymond Yau at 23/10/10 12:51 did gyre and gimble:
> > Is this the reason why kmix remove the left/right balance control ?
>
> Not sure what you mean by this... kmix can still control left and right
> independently... just right click and chose "split channels".... but
> perhaps I've misinterpreted what you are saying.
>
> Col
>
>
Not sure that your case are similar to the issue described in table 2 of
stac9200 errata and known issues since alsamixertest use a mono sine wave
with sample rate 48000Hz the recorded signal is also mono through plughw, so
it is unlikely for alsamixertest to know whether there is a phase shift in
the left channel

There is a change in DAC sample rates since PA use 44100Hz to probe your
codec and alsamixertest use 48000Hz to play the sine wav

Changes in the DAC sample rates between 44.1 kHz multiples and 48 kHz
multiples can cause attenuation and phase shift in the left channel of the
DAC

S/W workaround exists, but doesn't provide 100% coverage.
The only totally effective method is to lock the sample rate to a given
value.