[alsa-devel] 1.0.15: volume levels drift on HDA with STAC92XX codec

[Takashi Iwai]

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