[alsa-devel] [PATCH fixed bug 4032 1/1] Fixed bug 4032.
tiwai at suse.de
Tue Dec 15 10:21:47 CET 2009
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...
More information about the Alsa-devel