[alsa-devel] alsactl adds volume controls?
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 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
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?
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
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
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
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
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.
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
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?
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
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
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!
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
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.
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.
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
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:
- you're opening "front:x" (or the "surround:x" variants), not
"plughw:x", "hw:x", "default:x", "dmix:x" or anything else.
you have no playback volume what so ever
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%
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.
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
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.
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
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.
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.
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
On Wed, Sep 29, 2010 at 03:26:38PM +0100, Colin Guthrie wrote:
- 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.
...
- 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.
2010/9/29 Colin Guthrie gmane@colin.guthr.ie
From what I understand:
- *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
Colin Guthrie wrote:
- *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.)
- 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.)
- 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.
- 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:
- 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.
- 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
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:
- *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.
- 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.
- 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 :)
- 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:
- 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.ht...
- 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 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:
- 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.ht...
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
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?
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
'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
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.
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
'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 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
'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 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
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
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),
'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 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
'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
'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 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;
'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;
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
'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;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
'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;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
'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
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)
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 {
'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
'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
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
'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 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
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
'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
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, }
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 ?
'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
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.
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=f78af4ab0412052aabb74...
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=eacbb9dba6b4c9...
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 ?
'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=f78af4ab0412052aabb74...
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=eacbb9dba6b4c9...
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
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=f78af4ab0412052aabb74...
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=eacbb9dba6b4c9...
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
'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
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
2010/9/29 Colin Guthrie gmane@colin.guthr.ie
- 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);
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 ?
'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
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.
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)
participants (9)
-
Alexander E. Patrakov -
Clemens Ladisch -
Colin Guthrie -
David Henningsson -
Jaroslav Kysela -
Mark Brown -
Raymond Yau -
Sebastian H. -
Takashi Iwai