[alsa-devel] 1.0.15: volume levels drift on HDA with STAC92XX codec
maximlevitsky at gmail.com
Sat Nov 17 11:36:32 CET 2007
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 at alsa-project.org
> > > > > 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
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 :-)
More information about the Alsa-devel