[alsa-devel] alsactl adds volume controls?

Fri Sep 3 09:03:15 CEST 2010

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

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

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

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

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

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

2) you have no playback volume what so ever

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

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

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

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

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