[alsa-devel] 1.0.15: volume levels drift on HDA with STAC92XX codec
cebbert at redhat.com
Fri Nov 16 19:48:46 CET 2007
On 11/16/2007 10:50 AM, 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:
>>>> This is with kernel 2.6.23 plus the two ALSA merge patches from
>>>> Alsa-devel mailing list
>>>> Alsa-devel at alsa-project.org
>>> 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.
>> Maybe we need add whitelist / blacklist for this feature?
>> On which codec/machine is this feature confirmed to work?
> 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
> 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
I reverted the change in Fedora 8 and it fixed things:
More information about the Alsa-devel