I've tested to play any kind of sound in 2.6.38.2-desktop-1.mga-kernel, but when you lower it to 10% it seems to be muted, but speaker isn't muted in the panel. Even when you play at 15% it's still to low, you have to turn it up to at least 30%. lspcidrake -v | fgrep -i AUDIO shows: snd_hda_intel : nVidia Corporation|MCP72XE/MCP72P/MCP78U/MCP78S High Definition Audio (vendor:10de device:0774 subv:103c subd:360a) (rev: a1) PulseAudio is activated. Glitch-Free mode is also activated. I did the alsa-project.org debug-script & got this: http://www.alsa-project.org/db/?f=3859b171ffc69b6e2108564ad24372a877dc3ce0
Priority: Normal => High
Try alsamixer, then F6 to see the soundcard hardware levels. Pulseaudio manages several levels at the time, so it can give almost muted sound with some chipsets.
CC: (none) => lists.jjorge
Created attachment 181 [details] Here's the result of typing F6 in alsamixer.
The levels for Internal Mic, Docking Mic & Mic was lowered. Why is that so by default?
Assignee: bugsquad => mageia
If you run alsamixer -c0, chances are you will see that the 10% mark (in terms of the PA volume is when the "Master" slider of your NVidia card reaches 0 and the PCM slider takes over.... (although there may not be a PCM slider at all). If this is the case it's ultimately caused by a "min is mute" bug in alsa. Setting Master to 0 should not mute (according to the HDA spec) but many systems implement this anyway... totally sucks. What is likely required is a TLV quirk. I recently had a similar issue with my hardware and we found that the TLV quirks were broken in two ways - one in the kernel for my driver and once generally in the userspace alsalib. This is now fixed so the process for you should be simpler. If you can confirm that this is indeed what you see, then we can look into the next steps needed. Cheers Col
I have a similar problem with my audio. I found a solution which required a quick editing of some alsa config file. Here is the link to the thread. http://forum.mandriva.com/en/viewtopic.php?f=83&t=112515#p841811 Hope this helps. This problem as been around for a very long time and nobody seems to know how to fix it. This may be your only salvation.
CC: (none) => nine_dimensions
(In reply to comment #5) > I have a similar problem with my audio. I found a solution which required a > quick editing of some alsa config file. Here is the link to the thread. > > http://forum.mandriva.com/en/viewtopic.php?f=83&t=112515#p841811 > > Hope this helps. This problem as been around for a very long time and nobody > seems to know how to fix it. This may be your only salvation. Tried it exactly as instructions told me & now the volume is muted at 100%.
(In reply to comment #6) > Tried it exactly as instructions told me & now the volume is muted at 100%. Sorry to hear it didn't work for you. I think that editing the alsa file is on the right track despite your bad result. Your particular chipset probably requires different tweaks than mine did. Maybe you need to try different channels to mute/unmute. I'd backup the original config file and try switch which channels are ignored/used.
This is the incorrect fix. This basically tells PA to ignore the whole kcontrol. So rather than fixing the underlying problem, it just works around it. This is clearly not the right approach. The problem is the same as the one I had on my h/w a while back. The HDA codec clearly states that the minimum volume should NOT be mute, but many manufacturers have messed this up :s In order to fix it, a quirk has to be added to the kernel driver for this hardware to get it to tell the userspace system (libalsa) not to go all the way down to 0 on the master slider when we ask for a particular volume. I've already asked for confirmation in comment 4, but not heard back yet. Once this is done we can push a kernel-level fix to the alsa people. FWIW, please also supply alsa-info.sh output. Here is a handy link, I've, ahem, borrowed, which tells you how :) https://wiki.ubuntu.com/Audio/AlsaInfo
(In reply to comment #8) > FWIW, please also supply alsa-info.sh output. Here is a handy link, I've, ahem, > borrowed, which tells you how :) > https://wiki.ubuntu.com/Audio/AlsaInfo What's the difference to my alsa-project-link & your link?
Ooooops. Double-comment.
Oh yeah, the alsaproject one is fine! Sorry, been a while since I read the bug so didn't go back and look at the initial comment! But ultimately, what I asked in comment 4 was to confirm that the 15% "silence" mark in pulseaudio corresponded to the point at which the alsa "Master" control reached 0 in alsamixer -c0. This information is needed to ensure I'm correct in my guess as to what is wrong. If you can confirm that, I'll see if I can come up with a patch or if I need to engage some other kernel hackers who are cleverer than me :)
Keywords: (none) => NEEDINFOPriority: High => NormalSource RPM: (none) => alsa
Created attachment 681 [details] alsa-info.sh output
In my system, this is not the case : 3 mixers are changing sound level : Master, PCM and Front. PA changes the level of the three in a strange way, I try to represent that here : PA MA PCM FRONT 0 0 0 65 5 16 100 65 10 16 100 65 15 16 97 65 20 21 97 100 <- I start hearing sound If I put FRONT at 100, I hear sound with PA 5 (second line). So at least on my system the problem is that FRONT is not straight into 100 with PA at 5%.
When you say "[you] put FRONT at 100" was that a manual change or automatic when PA hit the 20 mark?
It is automatic when PA hit the 20 mark, but if I do it manually at line 2, : PA 5 FRONT 65 it gives also sound. I think PA should behave this way instead of my previous observed table : PA MA PCM FRONT 0 0 0 0 5 5 100 100 10 10 100 100 15 15 100 100 20 20 100 100 In fact, this is nearly what it does on another system I have, with HDA ATI SB Realtek ALC1200.
Keywords: NEEDINFO => (none)
@José The difference could be due to dB step sizes and/or ranges on different hardware. Can you supply your alsa-info.sh or is it exactly the same model as the ones already uploaded?
Created attachment 686 [details] Alsa Info
@ Colin I don't want to nag you, but do you mind giving a little update on this bug?
CC: (none) => marja11
@Marja, Don't worry about nagging me - I need that sometimes :D So PA behaves normally. The table in comment:14 is certainly how things should work. "Master" often does not have the granularity to set the volume the user requested (e.g. user may request -10.5dB, but the granularity of master might be 3dB at a time. Therefore to get -10.5dB we need to set Master to -9dB (3 steps @ -3dB) This leaves -1.5dB still to apply. In order to do this, we move on to the Front control. Let's say this has a granularity of 1dB, so we add in -1dB from Front which leaves us with -0.5dB still to apply, so we use PCM to do that if we can. If the granularity of PCM still doesn't give us a perfect overall attenuation, we do the remainder in software within PA itself). So the way PA is controlling the h/w is as expected. However if Front is not giving any audio unless at 100%, this this indicates a buggy alsa driver or buggy dB values and as such should be reported to alsa-devel. However, before doing that, does the latest Cauldron kernel help in any regard? If this works OK, we'll use a dB measurement tool to test how this works (you will need a loopback cable to plug your output into your mic for this test).
(In reply to comment #20) > > However, before doing that, does the latest Cauldron kernel help in any regard? > If this works OK, we'll use a dB measurement tool to test how this works (you > will need a loopback cable to plug your output into your mic for this test). @ Josè @ Kristofer Despite my name being at the top line of Colin's comment, this part is meant for you. Can you answer his question?
On my system the problem is solved in Cauldron, so for me the bug can be closed : - Front does not mute when at 97% - I've got a much more progressive sound level bar. alsamixer says : Chip: Intel IbexPeak HDMI
(In reply to comment #22) > On my system the problem is solved in Cauldron, so for me the bug can be closed > : > - Front does not mute when at 97% > - I've got a much more progressive sound level bar. > > alsamixer says : Chip: Intel IbexPeak HDMI @ José Thanks for replying @ Kristofer @ Colin Closing this bug because of José's reply. Please reopen if you don't agree
Status: NEW => RESOLVEDResolution: (none) => FIXED
I'm now updating to Cauldron without adding Backports & Testing-medias for it. I'll let you know what happens.
lspcidrake -v | fgrep -i AUDIO gives me: snd_intel8x0 : Intel Corporation|82801AA AC'97 Audio Controller [MULTIMEDIA_AUDIO] (vendor:8086 device:2415 subv:8086 subd:0000) (rev: 01) No sound at all updating to Cauldron. Not using Testing or Backports-medias.
alsamixer says following: Card: PulseAudio Chip: PulseAudio Item: Master /proc/asound/version shows: Advanced Linux Sound Architecture Driver Version 1.0.24.
Opening this again. If someone feels that this is wrong, please feel free to close it once again.
Status: RESOLVED => REOPENEDResolution: FIXED => (none)
(In reply to comment #27) > Opening this again. If someone feels that this is wrong, please feel free to > close it once again. @ Kristoffer: Thanks for updating to cauldron and checking. Could you please disable pulseaudio in MCC and tell if that makes any difference? @ Colin: I don't know much about sound (and this bug is still yours, anyway ;) ), and I'm the last one to know whether Kristoffer's current problem has anything to do with the original bug. So it's up to you to decide
It's impossible to say about Kristoffer's problem, but I can certainly say it's not the same bug, so this one should remain closed. A bug is not about tracking an individual user's specific set of problems, but rather a specific issue itself. I strongly suspect that like numerous others, Kristoffer simply has .rpmnew files in /etc/pam.d/ that is preventing proper permissions being applied to the sound nodes. i.e. https://bugs.mageia.org/show_bug.cgi?id=2982 We do of course have to address that issue (i.e. fix it up automatically) but it's certainly not related to the many comments here. If I'm correct in this guess, then disabling PA will make no difference. The symptom would be the display of a "Dummy Output" in various mixer apps (gnome-volume-control, kmix, pavucontrol etc). If it turns out to be something different and the original problem is indeed still present, then this bug can be reopened. Thanks for your understanding :)
Status: REOPENED => RESOLVEDResolution: (none) => FIXED
I dunno if this information is relevant, but as I run drakconf from Terminal & going to Sound-settings I see this message: [root@localhost ~]# "/usr/bin/drakmenustyle" is not executable [Menus] at /usr/sbin/drakconf.real line 822. "/usr/sbin/drakbackup" is not executable [Backups] at /usr/sbin/drakconf.real line 822. "/usr/sbin/drakvirt" is not executable [Virtualization] at /usr/sbin/drakconf.real line 822. "/usr/sbin/tomoyo-gui" is not executable [Tomoyo Policy] at /usr/sbin/drakconf.real line 822. perl: "include /lib/module-init-tools/modprobe.compat" is deprecated, please use /etc/modprobe.d : File or directory doesn't exist perl: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/. : Not a directory perl: "include /lib/module-init-tools/modprobe.compat" is deprecated, please use /etc/modprobe.d : File or directory doesn't exist perl: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/. : Not a directory perl: "include /lib/module-init-tools/modprobe.compat" is deprecated, please use /etc/modprobe.d : File or directory doesn't exist perl: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/. : Not a directory perl: "include /lib/module-init-tools/modprobe.compat" is deprecated, please use /etc/modprobe.d : File or directory doesn't exist perl: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/. : Not a directory perl: "include /lib/module-init-tools/modprobe.compat" is deprecated, please use /etc/modprobe.d : File or directory doesn't exist perl: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/. : Not a directory perl: "include /lib/module-init-tools/modprobe.compat" is deprecated, please use /etc/modprobe.d : File or directory doesn't exist perl: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/. : Not a directory perl: "include /lib/module-init-tools/modprobe.compat" is deprecated, please use /etc/modprobe.d : File or directory doesn't exist perl: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/. : Not a directory perl: "include /lib/module-init-tools/modprobe.compat" is deprecated, please use /etc/modprobe.d : File or directory doesn't exist perl: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/. : Not a directory Gtk-CRITICAL **: gtk_cell_view_set_cell_data: assertion `cell_view->priv->displayed_row != NULL' failed at /usr/lib/libDrakX/interactive/gtk.pm line 522. Using `/etc/sound/profiles/alsa' to provide `soundprofile'. Stopping sound (via systemctl): [ OK ] ERROR: Module does not exist in /proc/modules Starting alsa (via systemctl): [ OK ] Starting sound (via systemctl): [ OK ]
So it appears as the module isn't there.
That's just saying the module is not there when it tries to restart the sound system. This is not necessarily conclusive of anything at all. Again tho', this is now a completely different problem and the output from your specific problems is not relevant to this bug. Please seek help via IRC or other means to solve your particular issue and then, if needed report a new bug for the new problem or reopen this one if the original problem returns.
Wait a minute....... How's this a different problem? I had sound-problem in Mageia 1 with the 2.6-kernel. This is even more valid now in Cauldron.
A 'sound problem' is too vague. Or we could create only one bug called I've got a problem. This bug is about sound levels wrong in Cauldron, not in Mageia 1. And we can't put here a modules not loaded problem.