Colin Guthrie wrote: > 'Twas brillig, and Clemens Ladisch at 30/09/10 12:03 did gyre and gimble: >> Colin Guthrie wrote: >> The hardware control is always used. The user control created by >> softvol is used when some application is using the softvol plugin. >> (For an application using device names like "hw" or "plughw", there will >> be not softvol plugin.) > > OK. As pulse's mixer profiles *tries* to use "front" but will fall back > to "hw", we can be pretty much certain that the softvol plugin will > exist in all cases. The trick is knowing whether or not the control is > active. used by current stream > (although the latency of updates is terrible for me when I adjust the > alsamixer. I guess changing PCM directly in alsamixer it doesn't trigger > an immediate rewind in PA so the buffer has to run out for the change to > be heard. Yes. The softvol plugin could be changed to try to update the already- written part of the buffer; so far, not many programs have used big buffers. >>> Potential solutions would include: >>> 1. If the "correct" solution is to just use SND_PCM_NO_AUTO in PA, and >>> then deliberately/actively ignore any softvol mixers, then nothing needs >>> done at the alsa level I guess. >> >> Yes. >> >> Use snd_ctl_elem_info_is_user() to check for the softvol mixer element. > > Hmm, judging by the previous response to this suggestion, I'm not sure > this will work: > > http://mailman.alsa-project.org/pipermail/alsa-devel/2007-December/004622.html It would have worked if PA used the snd_ctl_* instead of the snd_mixer_* functions. In this special case, we know that the snd_ctl control "Playback PCM Volume" maps to the snd_mixer "PCM" playback volume, but this would still be a hack. >> It was decided to store this control in the hardware device so that it >> is saved/restored together with the 'real' controls. > > That as a principle makes sense but I still don't understand why it has > to be there when it's not active. So that it behaves like a 'real' control, i.e., you can set (and restore) it even when nothing is currently playing. > Also I said I'd refer back to [1] later, so here it is. I'm a little > confused as to why it's stored in asound.state, if, as you say, the > control is only created when something opens "front:" or similar. When > the asound.state is read and restored during boot (this is the only time > for 99% of users I believe - other than running it manually), would it > not be the case that nothing has yet opened "front:" and thus it will > not be restored? When alsactl restores a user control, it will automatically create it. Thus, using the softvol plugin creates this control practically permamently. > setting Master (not PCM) to 0% aka -46.5dB causes some kind of auto- > mute that cuts off all sound. It shouldn't do that. Wasn't this a hardware error? The driver should report correct dB information for this chip. Regards, Clemens _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
