Created attachment 343814 [details] alsa-info Hi, I'm reporting my mixer issues after reading www.redhat.com/archives/rhl-devel-list/2009-April/msg02321.html. Some background first: - my laptop is an HP Pavillion dv2172ea with a hda-intel based soundcard (codec: conexant CX20551 (waikiki), model number 5047) - sound didn't worked because of mixer issues until about 2 years ago when Tobin Davis received some support (datasheets, test boards) from Conexant to improve this codec (and 5045 as far as I remember but I could be wrong) support. At that time I helped him testing his patches and we (together with several other testers) managed to get it fully supported. IIRC alsa 1.0.14 has been the first release to get everything right. Bigger issues were: 2 separate independent PCM channels (which he fixed binding them into a single control), master muting when headphones connected not working, some other stuff with mic volume. Now, since about a year almost everything he fixed at that time has been reverted or anyway some change in alsa drivers introduced some big regression: - I have again 2 PCM channels - There is no master channel but only a Speaker one - Headphone channel doesn't control headphone volume at all, PCM (the first, PCM-2 has no effect) does it instead - When headphones are connected Speaker channel stop acting as Master and the only way to control volume is to act directly on PCM I tried to contact Tobin again but he's not hacking on alsa anymore. I also tried to bisect what changed but alsa git server is painfully slow (1Kb/s here) and I never had the patience (nor the time) to wait for git clone to complete. How Pulseaudio is involved? With the new volume applet there is no more chance to select which channel the volume actually controls. It controls PCM channel instead of Speaker as it should (well it should control Master but there is no more Master..) I'm posting this bug here since reading that mail in fedora-devel I felt there is finally someone willing to fix alsa bugs. I didn't report those bugs before because I'm a quite lazy and with the gstreamer applet (I switched recently from ubuntu), where I could select which channel to control, it worked "good enough". I'm opening the bug against pulseaudio as suggested in the mail. Please reassign it if this is not the right product to bug.
Created attachment 343815 [details] mixer channel pulseaudio should control
That diff is a bit too short. Please use -N7 or so on diff. Are you saying that 'Master' is not the control PA should be controlling on your device?
(In reply to comment #2) > That diff is a bit too short. Please use -N7 or so on diff. Ok, new one attached. Not sure it adds any useful info though. > Are you saying that 'Master' is not the control PA should be controlling on > your device? Not exactly. At the moment PA controls 'PCM' channel (as labeled in alsamixer), there is no 'Master', the control that mostly resembles 'Master' functionality is called 'Speaker'. Mostly, because ideally there should be a 'Master' channel that controls the 'Speaker' channel when no headphone is attached and the 'Headphone' one when they are. Right now 'Headphone' channel has no effect at all and headphone volume seems to be controlled by 'PCM-2'. Making PA control the 'Speaker' channel would probably be enough on the PA side but all other alsa issues will still stand.
Created attachment 344003 [details] new bigger diff
(In reply to comment #3) > they are. Right now 'Headphone' channel has no effect at all and headphone > volume seems to be controlled by 'PCM-2'. s/PCM-2/PCM, sorry.
Reassigning the bug to the kernel guys. I just tested alsa 1.0.20 from the alsa-driver tarball. All mixer issues seems solved there, I now have a Master channel, a single PCM, Speaker control speakers and Headphone controls headphones, Master controls both as it should. The new 'Master' channel fixes the previous pulseaudio issue too. I believe the actual fixes come from this commit [1] and some other one around March. I could try to bisect it better if needed. So, I'm not so familiar with alsa release process and how long does it takes to enter the kernel. Is there any chance to have it before Fedora 11 or with the early upgrades? 1. http://git.alsa-project.org/?p=alsa-kernel.git;a=commit;h=5b3a7440cbabdda07cfb3dcf4a07e0115a3dff9a
Lennart, I'm going to re-assign to Jaroslav for now and CC Chuck. Once the ALSA-level stuff is sorted to Filippo's satisfaction, we can work on the Pulse side of things. Sound good?
Why reassign to Jaroslav? The issues are fixed in ALSA, so they will end up in Fedora eventually anyway. PA needs to do something about the Speaker slider I guess, I'd rather see this bug reassigned to PA. Any maybe have a seperate bug opened that asks for backporting of that alsa patch.
Just to make it clear, PA won't need any fix. When those drivers will end up in fedora it will just use the Master channel as it should and everything will work out of the box. Maybe you could want to apply a temporary fix that makes it control the Speaker channel meanwhile but I don't think it's worth. A separate backporting patch would need some more work to find which commit are actually interesting, I don't think it's just that single commit. So IMHO, this bug should stay opened just as a memorandum about a regression currently in fedora and waiting to be fixed.
lennart: well, it will be fixed in Fedora 'eventually' but it isn't now :) hence it's appropriate to have it assigned to our ALSA guy as long as it's still open...as Filippo says PA behaves fine with a fixed ALSA, I guess there's nothing for you to do here.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
The fix from alsa upstream finally landed in fedora 11 with the 2.6.30 kernel. This bug can be closed for me.