Comment 72 for bug 994685

Yes, that's expected. The "fixed" kernel in fact uses a different DAC in the codec to output sound to first connected speakers, not sharing with headphone, so you get two volume controls. On the "bad" kernel, one DAC is used, and the volume control controls the Amp in the DAC (Speaker Volume slider controls this DAC), which is shared between the headphone and speaker pins, but the name of the slider is misleading.

This behaviour confirms what I had found earlier when playing with codec file in hda-emu. Just the lack of sound was weird, as the kernel isn't touching volumes. So when you plug the headphone, something else (pulse?) goes there and turns down the volume all the way down, probably thinking it just controls the speaker volume. When the new kernel starts to use a new DAC, and creates for it also a new volume slider, this problem is avoided. Problem is that the commit for the kernel which results in a new headphone slider/dac used is a bit too intrusive for an stable release.

At least there is a workaround with using alsamixer. But not sure what to do or the best solution here yet, have to think/investigate more about it. The kernel certainly doesn't touch the volume sliders, when checking this with hda-emu, and I always wonder why something else wants to touch this when kernel usually is doing or should do automute properly already...