On 11/16/2007 10:50 AM, Maxim Levitsky wrote: > On Friday 16 November 2007 17:02, Takashi Iwai wrote: >> At Thu, 1 Nov 2007 20:17:30 +0200, >> >> Maxim Levitsky wrote: >>> On Thursday 01 November 2007 19:47:39 Chuck Ebbert wrote: >>>> We have two reports now of unstable volume levels: >>>> >>>> https://bugzilla.redhat.com/show_bug.cgi?id=361051 >>>> https://bugzilla.redhat.com/show_bug.cgi?id=354981 >>>> >>>> This is with kernel 2.6.23 plus the two ALSA merge patches from >>>> 2.6.23-rc1. >>>> _______________________________________________ >>>> Alsa-devel mailing list >>>> Alsa-devel@xxxxxxxxxxxxxxxx >>>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel >>> Probably this isn't a software bug. >>> Probably this chip country to datasheet doesn't have usable "Master >>> Volume" (volume knob) control. >> I got a bug report that the same symptom appears also with STAC9221. >> >> http://bugzilla.kernel.org/show_bug.cgi?id=9374 >> >> Maybe we need add whitelist / blacklist for this feature? >> >> On which codec/machine is this feature confirmed to work? >> >> >> thanks, >> >> Takashi > > Hi, > > Yes, it seems that volume knob has troubles. > > I have it with STAC9227. Obivosly it works > > I know a user that first complained about some problems, > but then he found that everything works ok, probably including the volknob. > > He has STAC9274, and we had a long disscussion about new features I > intruduced, > He said that everything is OK. > I ask him explictly about that. > > Now remember the report about conflict between my > 'Master Volume' and already existing one? > > This was a STAC922x, and the autor said that now > his mulimedia keys can again control the volume > (Probably this indicates that volumekknob is working) > > > Thus we have 4 groups of STACS: > > 1 - STAC9250 - lot of troubles - (I would be very happpy to hear from anybody > here that has it) > > 2- STAC9221/2 - I thought that it works, but not anymore > 3- STAC9227/8/9 - I have it, so I hope that it works > 4- STAC927x - very simular to above, and one user that tells that it works. > > > I suggest to wait a bit more to see the scale of this bug > (After all it isn't that big bug, it is just a feature :-) that isn't working) > > The datasheets mention briefly that an external volume control can be > connected to the chip. Maybe it affects the volumeknob. > If this is the case, then probably we ether need to detect it, or drop the > whole thing. > (Those external pins probably are just connected to the groung or somethibg > like that so no real external volumeknob is present, but they still mess the > internal VolumeKnob) > > > Blacklist can help, but it is probably too much for that feature, since > the VolumeKnob doesn't add anything very special, and can be emulated > with SoftVol plugin, like it is done now. > > There are several solutions: > > 1) Rename it to say 'VolumeKnob", so the users that have it broken won't > notice , but still driver will expose all controls of hardware. > 2) Make a module param that will enable/disable it > 3) Remove it completly, OK, but probably the #1 is better > > All depends on whenever this is a specific stac model bug > Like I thought STAC9205, or this is the 'external volume' problem. > > If this is just STAC9205 and STAC9221 then we can make a module param, > and make it enabled by default for STAC9227/8/9 STAC927x, but make it > disabled for STAC9205 and STAC9221 > > If not, then it is better to remove it/remame to VolumeKnob > I reverted the change in Fedora 8 and it fixed things: http://cvs.fedora.redhat.com/viewcvs/*checkout*/rpms/kernel/F-8/linux-2.6-alsa-revert-hda-stac-volume.patch?root=extras _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
