At Tue, 30 Dec 2014 19:13:14 +0100 (CET), Jan Engelhardt wrote:
On Tuesday 2014-12-30 17:20, Takashi Iwai wrote:
Ah, I see you disable the automute. So the headphone plug shouldn't matter.
Changing the "Auto-Mute" control does not do anything; the system always exhibits Automute behavior (if that's a bug, it's one which I did not care about so far).
Oh, that's really interesting. I didn't expect such a hardware-controlled automute nowadays. We need to investigate this more.
Could you try hda_analyzer or hda-jack-retask (see HD-Audio.txt) to change the control of pins 0x14 and 0x15 on the fly? Do they influence on the output for the speaker (0x14) and the headphone (0x15)? Also, check alsa-info.sh output (or alsactl store) whether "Headphone Jack" gives the right value per the headphone jack plug state.
Hm, then there is nothing obvious wrong there at a quick glance. Maybe there is an implicit fixed connection between a DAC and a pin? Try the patch below.
With your patch, I get a system which still has two issues that were not there in 3.17:
- the "Headphone" control is present but has no volume bar
- the "PCM" control does not affect the Speaker volume
These are expected behavior (side-effects). It's because of the shared volume control between the headpohne and the dock output. On 3.18, "PCM" is assigned to this shared volume control as a fallback. In your case, "PCM" was used by alsa-lib softvol plugin, and this is no longer taken when a hardware volume control is present. That's the reason for the second item.
On 3.19, this was renamed differently, so that "PCM" can appear again by a softvol item like before.
In anyway, beware that changing "PCM" softvol volume isn't wise at all. Better to keep this as unmodified (0dB, 100%) and use only "Master" volume so that you can avoid unnecessary sample manipulations in software.
Takashi