On Saturday 17 November 2007 12:10, Takashi Iwai wrote: > At Fri, 16 Nov 2007 17:50:09 +0200, > > 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. > > But even a different name control may have a similar effect. > After all, it's exposed as a mixer element, and the mixer app may > choose it as well. > > > 2) Make a module param that will enable/disable it > > I don't like to add a codec-specific module option, so far. > > > 3) Remove it completly, OK, but probably the #1 is better > > I think the safest way at this moment is to revert that once. Then > we'll have a stable state as on 2.6.23. > > On my local tree, there is a patch to add a virtual "Master" control > to bind all volume controls. It's a driver-side implementation (no > softvol plugin). So, when this patch is merged, we'll have a master > control for STAC, anyway. > > > All depends on whenever this is a specific stac model bug > > Like I thought STAC9205, or this is the 'external volume' problem. > > Or, it might be the conflict (a kind of race) between the software > vol knob change and the hardware vol knob change. If so, it can > explain why one STAC9221 works and another STAC9221 doesn't. Thats exactly what I have said, but this is only a guess, I didn't see a statetment about that in datasheet. > > > 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 > > I got a bug report (from Linus himself) that once the driver with 9227 > didn't work during 2.6.24-rc1 update. And magically started again > working during bisecting. I couldn't spot the culprit (the volknob > value looked OK), but my suspect is the volknob, judging from the > situation. You mean it was connected to instable volume too? If that is true, and due to the fact that I have STAC9227, probably it is a conflict with hardware volume. > > > If not, then it is better to remove it/remame to VolumeKnob > > Agreed. I'd like to take a safer way if you don't insist... Great, it is probably the best to have a virtual master volume. Just one question, it will be probably enabled for devices that don't have a master volume (or have it broken like the STAC), right?, And when you expect it to be merged? So I agree completly, revert it, and lets forget about that VolumeKnob. Sorry for the trouble :-) Best regards, Maxim Levitsky > > > Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
