Re: 1.0.15: volume levels drift on HDA with STAC92XX codec

[Maxim Levitsky <maximlevitsky@gmail.com>]

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@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
> 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