[alsa-devel] [PATCH fixed bug 4032 1/1] Fixed bug 4032.

[Takashi Iwai]

At Mon, 14 Dec 2009 13:49:33 -0700,
Steve Soule wrote:
> 
> On 12/14/2009 12:01 PM, Takashi Iwai wrote:
> > At Mon, 14 Dec 2009 11:41:55 -0700,
> > Steve Soule wrote:
> >>
> >> >From c3387a767f827f57a6b1f6b772d3d7a1b6b39942 Mon Sep 17 00:00:00 2001
> >> From: Steve Soule <sts11dbxr at gmail.com>
> >> Date: Mon, 14 Dec 2009 11:06:03 -0700
> >> Subject: [PATCH fixed bug 4032 1/1] Fixed bug 4032.
> >>
> >>
> >> Signed-off-by: Steve Soule <sts11dbxr at gmail.com>
> > 
> > Could you give a bit more changelog text?
> > It's not sure what bug 4032 indicates, and more importantly, why this
> > change is needed for fixing what.
> 
> Okay.  Here is a thorough changelog:
> 
> This is a fix of a bug in ac97_codec.c. This bug has existed for many
> years in many versions of alsa and versions of the kernel.  The bug
> appears with a Soundblaster 16PCI sound card.  With this card, sometimes
> the driver works correctly, and sometimes it doesn't.  When it doesn't
> work correctly, the driver prints the error message:
> 
> AC'97 0 analog subsections not ready
> 
> and fails to detect the complete set of sound controls.  In particular,
> the driver fails to detect the "Master Playback Volume" control, and so
> the sound card volume level is arbitrary--usually very low.
> 
> As far as I can tell, the problem is in the function snd_ac97_mixer() in
> ac97_codec.c, in the lines immediately before the error message is
> printed.  These lines appear to be waiting for the card to come out of
> powerdown mode.  If the card does not come up within a timeout, the
> error message is printed, and the controls are not detected correctly.
> 
> The timeout in the latest version is 120 ms (though it was 100 ms when I
> first reported this bug a year and a half ago).  I experimented with
> different timeout values, and found that 1 second was not sufficient,
> and that 5 seconds is sufficient.

Hrm, usually 1 second is really long enough for any operations.
And 5 seconds is already a history since genesis.  If it takes so
long, something other is fishy.

Although extending the timeout would be relatively harmless, I still
don't think this is the point to fix.  More likely the problem is in
the codec accessor side...


thanks,

Takashi