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@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:
- 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.
- Make a module param that will enable/disable it
I don't like to add a codec-specific module option, so far.
- 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