From the amixer output, 'Master Front' level is set to 0, try raising it using any sound mixer.

Or:
amixer -c0 set 'Master Front' 100%

Can you also attach the "pacmd ls" output?

I suspect I know what the problem is but I need to check a few things.

(In reply to comment #1)
> From the amixer output, 'Master Front' level is set to 0, try raising it using
> any sound mixer.
> 
> Or:
> amixer -c0 set 'Master Front' 100%

Thank you very much! This command has helped! I could not increase the sound by using pavucontrol and KMix.

(In reply to comment #2)
> Can you also attach the "pacmd ls" output?
> 
> I suspect I know what the problem is but I need to check a few things.

Sorry, I at that time did not understand how to attach a file. I have it in the description of the bug:

> # pacmd ls
No PulseAudio daemon running, or not running as session daemon.

Are you running "pacmd ls" as the same user as normal or as e.g. root? Just do things as your normal user. Also try "ps aux | grep pulse" to make sure PA is indeed running.

AFAICT, the "Master Front" mixer element is simply misnamed. We can botch around this in PA (and I can tell you about some files on your system to edit to make all the normal UIs work), but it should really be fixed at the alsa level.

I'll try and work that one out and push it upstream.



In the mean time, could you could try:

su -
<enter root password>
cd /usr/share/pulseaudio/alsa-mixer
cp -ar paths paths.bak
grep -rl Master paths | xargs sed -i 's/\[Element Master\]/\[Element Master Front\]/'

then reboot (or "pulseaudio -k" then log out and back in again).

Hopefully after doing that, your mixer will "just work"(tm) properly via pavucontrol/kmix etc.

Please let me know either way.


If it didn't seem to do anything, then please run the following to revert the above change.

su -
<enter root password>
cd /usr/share/pulseaudio/alsa-mixer
rm -rf paths
mv paths.bak paths

Created attachment 648 [details]
pacmd ls

I replaced the Element Master for Element Master
Front in the files / usr / share / pulseaudio / alsa-mixer. But nothing has changed. What was supposed to change?

Following instructions Ahmad Samir I can already adjust the sound with the KMix. But, lacking KMix channel selection "Front", "PCM", etc. as it was in earlier versions KMix.

Created attachment 649 [details]
The same problem on another sound card.

This problem does not depend on sound card. I now set Mageia for other people. Again required to use "amixer-c0 set 'Master Front' 100%" of the console. Thank you for what I know now this way. But what do other beginners?

Oh! I installed the proprietary drivers for video card, and appeared in KMix "Front", "PCM", etc. I'm so behind the times, I do not know that for the sound need  install video card drivers. %)

By the way, the video card nVidia GT 440 was not determined by the system. It was proposed to vesa. I just select "nvidia GeForce 400 series and later".

I apologize for what I made ââa forum here.

Dmitriy,

The problem is the fact that the mixer element is called "Master Front". This is non-standard and it should just be called "Master". This is the source of all the problems.

GUI mixers these days are simplified to offer users a more logical and intuitive interface. Rather than having Master, Front and PCM which all ultimately control the same volume, we have PulseAudio controlling the whole mixer pipeline for us and just presenting us a simple sound device to control without worrying about the underlying alsa kcontrols. e.g. for a sound card they simply see one device with six channels, all properly labelled (except in kmix which cannot label channels) rather than separated controls in different places.

Anyway, the drivers need fixed to not label things as "Master Front". That's the real fix.

What I'd hoped to do with the instructions I gave you is tell PA to use "Master Front" rather than "Master". What this should have done is made the GUI in e.g. pavucontrol work for your card (i.e. adjusting the volume there should have controlled the underlying Master Front kcontrol in alsa. In fact your pacmd ls output seems to confirm that this indeed worked, as your built in sink appears to have the "HW_VOLUME_CTRL" flag which is should only do if Master is present.... (compare this to your HDMI sink which does not have this flag... this is likely due to the change I suggested - it will have a "Master" kcontrol, but PulseAudio is no longer looking for it and thus it's volume control is now broken.

I have to confess, I'm confused as to why Master Front is not being adjusted for you when changing the volume in pavucontrol now.... the flags suggest it should :s

Re: KMix, it very specifically *should not* show you the separated out "Front", "PCM" etc. This is a legacy mode that we're trying to hide away from users.

It can still work in this way if you set an environment variable "KMIX_PULSEAUDIO_DISABLE=1" in e.g. your ~/.bashrc.

For some reason kmix is misbehaving or PulseAudio is no longer starting properly (or you have disabled it in draksound), but this is a different case entirely (it could also just be a race condition at startup)


Anyway, like I say pavucontrol and kmix should ultimately show you approximately the same thing, hiding away the underlying complexity of the mixers.

As I said the fundamental problem here is that "Master Front" should just be called "Master"

I will attempt to get this fixed at the alsa side and also in our kernels.

Thank you very much!

I regret to note that the sound system in Mageia worse than it was in Mandriva. In Mandriva I had not got so many problems with sound. :( In the configuration (attachment 649 [details]) at startup every time it fails KMix:

Application: KMix (kdeinit4), signal: Aborted
[KCrash Handler]
#7  0xffffe424 in __kernel_vsyscall ()
#8  0xb5f15181 in raise () from /lib/i686/libc.so.6
#9  0xb5f16cae in abort () from /lib/i686/libc.so.6
#10 0xb5f0da98 in __assert_fail () from /lib/i686/libc.so.6
#11 0xb06c9061 in snd_hctl_handle_events () from /usr/lib/libasound.so.2
#12 0xb06d64f1 in snd_mixer_handle_events () from /usr/lib/libasound.so.2
#13 0xb0819331 in ?? () from /usr/lib/libkdeinit4_kmix.so
#14 0xb082ebfe in ?? () from /usr/lib/libkdeinit4_kmix.so
#15 0xb082eb6e in ?? () from /usr/lib/libkdeinit4_kmix.so
#16 0xb6d7277d in QMetaObject::metacall(QObject*, QMetaObject::Call, int, void**) () from /usr/lib/libQtCore.so.4
#17 0xb6d81fac in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/lib/libQtCore.so.4
#18 0xb6dd1ee5 in QSocketNotifier::activated(int) () from /usr/lib/libQtCore.so.4
#19 0xb6d88bef in QSocketNotifier::event(QEvent*) () from /usr/lib/libQtCore.so.4
#20 0xb626afb4 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQtGui.so.4
#21 0xb626ff97 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/libQtGui.so.4
#22 0xb74a4351 in KApplication::notify(QObject*, QEvent*) () from /usr/lib/libkdeui.so.5
#23 0xb6d6bf2e in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/libQtCore.so.4
#24 0xb6d9a708 in ?? () from /usr/lib/libQtCore.so.4
#25 0xb5a334d9 in g_main_context_dispatch () from /lib/libglib-2.0.so.0
#26 0xb5a33ce0 in ?? () from /lib/libglib-2.0.so.0
#27 0xb5a33f9a in g_main_context_iteration () from /lib/libglib-2.0.so.0
#28 0xb6d9ad9b in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#29 0xb63227fa in ?? () from /usr/lib/libQtGui.so.4
#30 0xb6d6b13d in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#31 0xb6d6b3b9 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#32 0xb6d6fef0 in QCoreApplication::exec() () from /usr/lib/libQtCore.so.4
#33 0xb6268d34 in QApplication::exec() () from /usr/lib/libQtGui.so.4
#34 0xb07eb6bb in kdemain () from /usr/lib/libkdeinit4_kmix.so
#35 0x0804dca4 in _start ()

More on the same computer when downloading sound is reproduced with the "rattle" (do not know how to describe correctly) using Gstreamer or VLC-backend to Phonon. Smooth sound only when XINE-backend.

On another computer, could not adjust the microphone's webcam: http://www.a4tech.com/product.asp?cid=77&scid=160&id=550 had to disable PulseAudio. Previously, there was a Mandriva 2010.1 and microphone webcam worked fine.

I installed 64-bit version of Mageia. The next day, after starting the system, I got the same error:

Application: KMix (kdeinit4), signal: Aborted
[KCrash Handler]
#6  0x00007ff4c1734ff5 in raise () from /lib64/libc.so.6
#7  0x00007ff4c1736786 in abort () from /lib64/libc.so.6
#8  0x00007ff4c172d865 in __assert_fail () from /lib64/libc.so.6
#9  0x00007ff4b0eb9320 in snd_hctl_handle_events () from /usr/lib64/libasound.so.2
#10 0x00007ff4b0ec42f9 in snd_mixer_handle_events () from /usr/lib64/libasound.so.2
#11 0x00007ff4b11baa59 in ?? () from /usr/lib64/libkdeinit4_kmix.so
#12 0x00007ff4b11ced27 in ?? () from /usr/lib64/libkdeinit4_kmix.so
#13 0x00007ff4b11cec8d in ?? () from /usr/lib64/libkdeinit4_kmix.so
#14 0x00007ff4c2dabdbf in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/lib64/libQtCore.so.4
#15 0x00007ff4c2df4bae in QSocketNotifier::activated(int) () from /usr/lib64/libQtCore.so.4
#16 0x00007ff4c2db246b in QSocketNotifier::event(QEvent*) () from /usr/lib64/libQtCore.so.4
#17 0x00007ff4c1f328a4 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib64/libQtGui.so.4
#18 0x00007ff4c1f3747a in QApplication::notify(QObject*, QEvent*) () from /usr/lib64/libQtGui.so.4
#19 0x00007ff4c3b1f9c6 in KApplication::notify(QObject*, QEvent*) () from /usr/lib64/libkdeui.so.5
#20 0x00007ff4c2d973dc in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib64/libQtCore.so.4
#21 0x00007ff4c2dc2369 in ?? () from /usr/lib64/libQtCore.so.4
#22 0x00007ff4be80ddc3 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0
#23 0x00007ff4be80e5a0 in ?? () from /lib64/libglib-2.0.so.0
#24 0x00007ff4be80e83d in g_main_context_iteration () from /lib64/libglib-2.0.so.0
#25 0x00007ff4c2dc29af in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQtCore.so.4
#26 0x00007ff4c1fd921e in ?? () from /usr/lib64/libQtGui.so.4
#27 0x00007ff4c2d96792 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQtCore.so.4
#28 0x00007ff4c2d969dc in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQtCore.so.4
#29 0x00007ff4c2d9ae9b in QCoreApplication::exec() () from /usr/lib64/libQtCore.so.4
#30 0x00007ff4b11926fa in kdemain () from /usr/lib64/libkdeinit4_kmix.so
#31 0x0000000000406cc9 in _start ()

If I understand correctly, this is an old error. It has already resolved.
http://expert.mandriva.com/question/108797
https://bugs.kde.org/show_bug.cgi?id=235822
But I have not found how to fix it yourself.

It seems that there is no solution to the problem: https://bugs.mageia.org/show_bug.cgi?id=2124 :(

Indeed. I need to ask upstream about this.

*** Bug 2388 has been marked as a duplicate of this bug. ***

CC: (none) => g.sprik

(In reply to comment #14)
> It seems that there is no solution to the problem:
> https://bugs.mageia.org/show_bug.cgi?id=2124 :(

@ Colin: Sorry, I didn't read the whole thread, but if this bug depends on 2124, can you please set the depend?

(In reply to comment #15)
> Indeed. I need to ask upstream about this.

Any news?

CC: (none) => marja11

There are two bugs here.... One is related to the naming of "Master Front" element, the other relates to a bug in libasound which is reported in https://bugzilla.redhat.com/show_bug.cgi?id=692278 and (I think) incorrectly closed.

Dmitriy, can you perhaps do some tests for me just to check something?

You will need to install the "speaker-test" package.

Firstly, start a terminal and execute:

pasuspender bash

This will suspend PulseAudio (i.e. make it release the sound h/w) and let you do some fiddling.

In this terminal you will run the command:
while true; do speaker-test -D surround51:0 -c 6 -t pink -s 3; done

This command will play pink noise on the "Rear Left" speaker continuously (you might also need to provide a -r argument to set the sample rate), You obviously need some kind of speaker plugged into the Rear Left output on your board.


While this is going on, I'd like you to open a second terminal, and do a couple tests.

Run: alsamixer -c0

In this interface you should be able to adjust the left channel of the "Surround" element and have this affect the sound volume you hear on the speaker. However, the real question I want to know the answer to is if adjusting the "Master Front" element also affects the volume level you hear through the rear speaker.



When this is done, it would be great if you could then cancel (ctrl+c) the original speaker-test command and rerun it with but change the -s 3 argument to -s 5. This will now play the noise through the "Centre" speaker.

In alsamixer you should now be able to adjust the volume with the "Center" element. In this case I'd like to know whether Master Front also affects the volume coming out the Center speaker.



To give you some background, I believe "Master Front" is simply mislabelled and should be called "Master". If my assumption is correct, adjusting this *should* affect the volume in the rear speakers. If I am incorrect, then it should just be called Front, but as you already have a Front element, this seems somewhat strange! (in this case, it would perhaps also be worthwhile testing is -s 1 and making sure both "Front" and "Master Front" affect the volume)


The reason I'm checking the Center channel is that an element called "Master" should not affect the Center and LFE channels. Sadly this is not always the case (oh the joys of totally non-standard driver implementations at the alsa level!) and e.g. on some Creative h/w (X-Fi) it *does* affect Center/LFE...


When you are done testing, you can quit the speaker-test loop and type "exit" to exit your suspended shell and get "normal" audio back.

Many thanks for your help and sorry for the delay in getting back to you.

PS I've assumed card 0 in the above commands: You can substitue the surround51:0 and -c 0 arguments with the appropriate card index if needs be (cat /proc/asound/cards).

I'm sorry, but those problems have been on other people's computers where I installed Mageia 1. Now I can not run tests.

(In reply to comment #20)
> I'm sorry, but those problems have been on other people's computers where I
> installed Mageia 1. Now I can not run tests.

Can you still not test? Colin can't really do anything without more information.

Unfortunately, now I can not yet. I am sorry that my post was useless. :(

(In reply to comment #22)
> Unfortunately, now I can not yet. I am sorry that my post was useless. :(

It was a lot more useful than no post!! :-D

Please give the feedback Colin asked for in comment 19 when you have access to a computer with this problem again :)

Do you already know when that will be?

> Do you already know when that will be?

I cannot say when it will be. Sorry.

This message is a reminder that Mageia 1 is nearing its end of life. 
In approximately 25 days from now, Mageia will stop maintaining and issuing 
updates for Mageia 1. At that time this bug will be closed as WONTFIX (EOL) if it 
remains open with a Mageia 'version' of '1'.

Package Maintainer: If you wish for this bug to remain open because you plan to 
fix it in a currently maintained version, simply change the 'version' to a later 
Mageia version prior to Mageia 1's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not 
be able to fix it before Mageia 1 is end of life.  If you would still like to see 
this bug fixed and are able to reproduce it against a later version of Mageia, 
you are encouraged to click on "Version" and change it against that version 
of Mageia.

Although we aim to fix as many bugs as possible during every release's lifetime, 
sometimes those efforts are overtaken by events. Often a more recent Mageia 
release includes newer upstream software that fixes bugs or makes them obsolete.

--
Mageia Bugsquad

Mageia 1 changed to end-of-life (EOL) status on ''1st December''. Mageia 1 is no 
longer maintained, which means that it will not receive any further security or 
bug fix updates. As a result we are closing this bug. 

If you can reproduce this bug against a currently maintained version of Mageia 
please feel free to click on "Version" change it against that version of Mageia and reopen this bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

--
Mageia Bugsquad

Status: NEW => RESOLVED
Resolution: (none) => WONTFIX