Could you bisect, or at least find out which 3.0.x kernel starts showing the problem?

(In reply to comment #1)
> Could you bisect, or at least find out which 3.0.x kernel starts showing the
> problem?

I will, but I've got a question - what's the stable tree GIT url?

git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git

You can find a branch for each kernel version (e.g. linux-3.0.y).

(In reply to comment #3)
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
> 
> You can find a branch for each kernel version (e.g. linux-3.0.y).

My findings so far.

$ git bisect log

git bisect start
# good: [02f8c6aee8df3cdc935e9bdd4f2d020306035dbe] Linux 3.0
git bisect good 02f8c6aee8df3cdc935e9bdd4f2d020306035dbe
# bad: [7a576d2dcd5807a7310032b380442eeba8c1c293] Linux 3.0.11
git bisect bad 7a576d2dcd5807a7310032b380442eeba8c1c293
# bad: [9185560808a0dc0432b130ca9d9965cb7ce052a6] isci: fix event-get pointer increment
git bisect bad 9185560808a0dc0432b130ca9d9965cb7ce052a6
# good: [b3ff2fd377a0b593678af0082b6a2e4ecc3eec84] possible memory corruption on mount
git bisect good b3ff2fd377a0b593678af0082b6a2e4ecc3eec84
# good: [a0be78ef93e0656339bf14feddc0e8afb2a86894] fs/9p: Fid is not valid after a failed clunk.
git bisect good a0be78ef93e0656339bf14feddc0e8afb2a86894

Now quite randomly I hear quiet cracks so I'm not sure where to go from now, with the previous git session I didn't have them, but the original bug symptoms are worse then what I'm having right now.

I guess it'll be `git bisect good/bad`? But how can I limit it to ALSA - there are just too many commits pending in `bisect`? - it can take ages to try the remaining ones.

You can limit the commits by specifying the paths.  Start git-bisect with sound and include/sound paths.
    % git bisect start v3.0.11 v3.0 -- sound include/sound

See git-bsect man page for details.

I considered that option, but there's one caveat I mentally bump into - what if some other changes in other kernel subsystems could cause these symptoms?

Then you'll lose ;)  It might not be the exact cause.  It can be a help to narrow down the area, though.

With bisect, usually there aren't so many differences whether you specify the paths or not.  Even without specifying paths, it'll up to 9 steps.  So, not too many commits.  The bisection in the stable tree is far much easier than the bisection during rc phase.

Damn, I arrive at the wrong commit:

git bisect log
git bisect start
# good: [02f8c6aee8df3cdc935e9bdd4f2d020306035dbe] Linux 3.0
git bisect good 02f8c6aee8df3cdc935e9bdd4f2d020306035dbe

# bad: [7a576d2dcd5807a7310032b380442eeba8c1c293] Linux 3.0.11
git bisect bad 7a576d2dcd5807a7310032b380442eeba8c1c293

# bad: [9185560808a0dc0432b130ca9d9965cb7ce052a6] isci: fix event-get pointer increment
git bisect bad 9185560808a0dc0432b130ca9d9965cb7ce052a6

# good: [b3ff2fd377a0b593678af0082b6a2e4ecc3eec84] possible memory corruption on mount
git bisect good b3ff2fd377a0b593678af0082b6a2e4ecc3eec84

# good: [a0be78ef93e0656339bf14feddc0e8afb2a86894] fs/9p: Fid is not valid after a failed clunk.
git bisect good a0be78ef93e0656339bf14feddc0e8afb2a86894

# bad: [b73077a5fce232f3e95099f3bd9c084ab320aa85] ixgbe: fix possible null buffer error
git bisect bad b73077a5fce232f3e95099f3bd9c084ab320aa85

# good: [7edcab441920647c6ffec304451e11bc18ff1b11] mfd: Fix value of WM8994_CONFIGURE_GPIO
git bisect good 7edcab441920647c6ffec304451e11bc18ff1b11

# good: [d5b1a08d0d0a73c716766275eb0c5648e143ca85] workqueue: lock cwq access in drain_workqueue
git bisect good d5b1a08d0d0a73c716766275eb0c5648e143ca85

# good: [c3c24ca5a0a6bf57b2685c159e5c9c01df76dddb] USB: xhci: Set change bit when warm reset change is set.
git bisect good c3c24ca5a0a6bf57b2685c159e5c9c01df76dddb

# bad: [562960c731b9ffba8cd200be8d38f5f793b23d74] Fix the conflict between rwpidforward and rw mount options
git bisect bad 562960c731b9ffba8cd200be8d38f5f793b23d74

from now on - everything is bad.

# bad: [e9bfcbffb7b26065a2b467e29bb6c7ec83d17646] ALSA: hda/realtek - Fix auto-mute with HP+LO configuration
git bisect bad e9bfcbffb7b26065a2b467e29bb6c7ec83d17646

# bad: [bdba777a08cfe193f8c4a5cbb8382549db932171] iwlagn: fix command queue timeout
git bisect bad bdba777a08cfe193f8c4a5cbb8382549db932171

which gives me:

git bisect bad
bdba777a08cfe193f8c4a5cbb8382549db932171 is the first bad commit
commit bdba777a08cfe193f8c4a5cbb8382549db932171
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Mon Sep 12 12:09:10 2011 -0700

    iwlagn: fix command queue timeout

At this point I don't know what to do :(

I bet you can check what commits are included in the last three "bads" by following the same git bisect procedure.

Are you using the headphone/line-out auto-mute feature?
The commit [e9bfcbffb: ALSA: hda/realtek - Fix auto-mute with HP+LO configuration] fixes the line-out auto-mute, but when the machine has a bad jack-detection mechanism in hardware, it can lead to the bogus auto-mute behavior.

Try to turn off "Auto-Mute Mode".

(In reply to comment #9)
> Are you using the headphone/line-out auto-mute feature?
> The commit [e9bfcbffb: ALSA: hda/realtek - Fix auto-mute with HP+LO
> configuration] fixes the line-out auto-mute, but when the machine has a bad
> jack-detection mechanism in hardware, it can lead to the bogus auto-mute
> behavior.
> 
> Try to turn off "Auto-Mute Mode".

You were right, this option is enabled here (but I never enabled it manually so it looks like it's driver's defaults) but I have usual speakers connected to the green audio output of my motherboard so I'm kinda surprised that this bug affects me.

Besides those clicks, pops and pauses occur _during_ playback, so I cannot understand what the point of this (mis)feature is if it interferes with things it shouldn't affect in the first place.

This bug report can be safely closed, even though the corresponding feature (auto mute) wreaks havoc with audio playback on my sound card.

Now what about bug 42654?

The auto-mute feature is useful on most of machines (especially laptops) where the jack-detection unsolicited events are properly sent and handled.  But some machines have bad hardware implementations, unfortunately, resulting in the flickering outputs due to frequent bogus jack-detection events.

The bug 42654 can't be resolved unless you get Windows source code :)
You don't know whether the volume attenuation is done in software or not.
There might be some special vendor-specific verbs, but it's vendor's secret and never published.

The current Linux driver provides what the codec gives generically.  If it has to be more, blame the codec chip vendor not to provide the hardware attributes correctly.

FWIW, I fixed the upstream code (for 3.4 kernel) not to create this superfluous auto-mute switch for your device.

(In reply to comment #12)
> FWIW, I fixed the upstream code (for 3.4 kernel) not to create this
> superfluous
> auto-mute switch for your device.

Thank you! Even though I've fixed this problem for myself by turning off the auto-mute switch, other people with similar configurations will be relieved when their audio playback gets automagically fixed. ))

A patch referencing this bug report has been merged in Linux v3.4-rc1:

commit 1565cc358585be40608b46f18f7ac431a1aae2bc
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Feb 13 12:03:25 2012 +0100

    ALSA: hda - Add another jack-detection suppression for ASUS ALC892