Description of problem: Sound card controls are incorrect. I get no audio unless I set master volume above 70% kde using sound widget. I noticed when I lower kde volume below 70% PCM level goes to 0 when watching with "alsamixer -c 0" I have no sound problems running Mandriva 2011 on this hardware. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Clean install, apply all updates, reboot 2. mcc->Hardware->Sound Configuration 3. Log out/in 4. click up a terminal 5. alsamixer -c 0 6. Left click kde speaker icon/widget in task bar. 7. Move slider up/down Note: PCM slider goes to 0 in the alsamixer terminal when kde widget slider is below 70% :( This happens on one of my three machines with a cauldron install.
Created attachment 1331 [details] output from system files and compairson between Mageia and Mandriva
Source RPM: (none) => pulseaudio-1.1-3.mga2.src.rpm
Hi, thanks for reporting this bug. Assigned to the package maintainer. (Please set the status to 'assigned' if you are working on it)
Assignee: bugsquad => mageiaKeywords: (none) => Triaged
Smells like invalid dB info. Can you supply the output from the alsa-info.sh script? http://www.alsa-project.org/alsa-info.sh
Status: NEW => ASSIGNED
Only if you can point me to an alpha2.iso. alpha3 will not install on two of my three systems, one of which has the audio problem. <a href="show_bug.cgi?id=4144" title="X-based window system">bug 4144</a>
(In reply to comment #4) > Only if you can point me to an alpha2.iso. alpha3 will not install on two of my > three systems, one of which has the audio problem. > <a href="show_bug.cgi?id=4144" title="X-based window system">bug 4144</a> Torrents are still there: http://linuxtracker.org/index.php?page=torrents&search=mageia+alpha2&category=0&active=1&tracker=0 (may take some time to load).
CC: (none) => sander.lepik
Created attachment 1379 [details] alsa-info.sh results
Yeah the dB values look pretty zany... Simple mixer control 'Master',0 Capabilities: pvolume pvolume-joined pswitch pswitch-joined penum Playback channels: Mono Limits: Playback 0 - 64 Mono: Playback 25 [39%] [6.25dB] [on] at 39% it's saying it's +6.25dB i.e. it's amplifying... this should result in a *lot* of distortion, but if it's not, then the the values are clearly just wrong. Because this control is bust, PA will mostly use the PCM slider to control the volumes and thus it will ultimately reach 0% there pretty quickly (around 70% seems sensible enough to me). When PCM is 0% does the sound completely cut off or is it still audible? It *should* still be audible, because even when PCM is at 0 it'll still be some reasonable dB level. (you can find out the value via: amixer -c0 set PCM 0; amixer -c0 get PCM). If it's totally inaudable, then it seems like another bug where "min-is-mute" quirk needs to be set in the driver.
(In reply to comment #7) <snip> > then it > seems like another bug where "min-is-mute" quirk needs to be set in the driver. My WAG is a pulse audio detection problem. I noticed audio was working correctly on first login after a clean install of Mageia-2-alpha2-x86_64-DVD.iso yesterday. Install all up updates, reboot, login and audio setting is dinked up. Where/what can I look/compare to see what needs to be configured correctly? I have a script which dump output from aplay, cards, lsmod, lspci, modprobe, pacmd, arecord, chkconfig, lspcidrake, mixer, modules when it was working correctly.
People seem to be suffering from a permissions problem right now (no ACLs on /dev/snd/* among other things). This is likely the short term problem, but lets not bother discussing it here and keep this bug on topic :) I'll post on the cauldron list when the perms probs are tracked down.
(In reply to comment #9) > People seem to be suffering from a permissions problem right now (no ACLs on > /dev/snd/* among other things). This is likely the short term problem, but lets > not bother discussing it here and keep this bug on topic :) I'll post on the > cauldron list when the perms probs are tracked down. Dang, I hoping to do some more troubleshooting to help narrow down the problem. I noticed without updates, a log out/in would toggle to the problem. I already do a usermod -a -G audio userid_here, as root, just after install reboot and before user logs in for the first time.
Users should not be added to the audio group unless you have very specific needs. Otherwise you will at times be going specifically against all the access rules put in place for users. So unless you really need to (i.e. not just temporarily to solve a transient problem) it's best not to add users to special groups.
Severity: normal => major
Just saw your comment on another bug. Is this still valid with the latest kernel updates? The info I'm interested in still is the alsa-info.sh output - namely the bit I mentioned in comment 7. If it's still got dB values >0, are you able to perform a dB measurement? This would require an audio loopback cable (a cable with a 3.5mm jack on each end) plugging it in to both headphones and mic then running some software? Let me know if this is a possibility as that way we can define a dB override table and test it in PulseAudio before submitting the data upstream.
(In reply to comment #12) > Just saw your comment on another bug. Yes, I was hoping to catch your attention. :) > Is this still valid with the latest kernel updates? Not with any 3.2.x kernels but now works with 3.3.0-desktop-0.rc6.1.mga2 release.
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED
Yup, lots of nice things in 3.3 related to sound stuff... might even get working headphone jacks at long, long last :)