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