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

[Maxim Levitsky]

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.
2) Make a module param that will enable/disable it
3) Remove it completly, OK, but probably the #1 is better

All depends on whenever this is a specific stac model bug
Like I thought STAC9205, or this is the 'external volume' problem.

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

If not, then it is better  to remove it/remame to VolumeKnob


Best regards,
	Maxim Levitsky