At Sat, 17 Nov 2007 12:36:32 +0200, Maxim Levitsky wrote: > > 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. I'm not 100% sure about it but just a wild guess. The volume knob and the analog loopback were only changes that may affect, and from the nature of the problem, the volknob looks more suspicious. > > > 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? Hopefully will be posted in this week after a small brush up. > So I agree completly, revert it, and lets forget about that VolumeKnob. > Sorry for the trouble :-) OK, now reverted on HG tree. This should be really go to 2.6.24... Jaroslav, could you take any action please? thanks, Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
