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@xxxxxxxxxxxxx> > >>>>>> > >>>>>>> 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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
