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

[Takashi Iwai]

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.

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

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


Takashi