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