seems a duplicate of bug 5183

no, I don't think so ... 

first, the Altert Sound should not touch the hardware mixers at all when using pulseaudio (which does software mixing), for several reasons:
 1) it will interrupt (e.g. by muting the audio output) ongoing playback
 2) it violates the principles of an audio server (abstraction with per application volume settings)

second, there is no point in 'playing' a 'disabled' alert sound in the first place (which it seems to do, just with muted audio)

and finally, the 'beep' mentioned in the other report seems to be the speaker emulation which some hda chipsets provide producing the well known beep sounds from the last century just directly via the sound card.

CC: (none) => herbert

This is not a duplicate. It's also not a bug, but a feature (well half of it it, there is still a bug in here).

Herbert's statements of why PA should not be messing with the hardware controls are sadly incorrect. PulseAudio maintains complete control over the audio pipeline, and is far more than just a software mixer. It must know and interpret all the various (and inconsistently named) mixer controls and work out the best way to configure the hardware for any given configuration the user chose (e.g.  5.1 analog output, stereo output, front mic, rear mic etc. etc.). Different configurations require different setup at the alsa level. PulseAudio is a very advanced alsa client, in fact it is the only client that controls alsa quite so extensively and (AFAIK) the only client to enable timer based scheduling.

Anyway, the feature at play here is called "flat volumes" and it is in no way isolated to alert sounds. Flat volumes simple state that the hardware volume should always be set to the loudest playing stream. This maximises the use of the audio h/w for volume scaling and frees up CPU time for other tasks (or simply extends battery life). So even when the sink volume is reported to be, say, 90%, but only a single stream with a volume of 50% is playing, then there is no point in doing work in CPU to reduce the volume by 40% before playing it - that is simply wasteful - we just  set the underlying hardware volume to 50% and do no extra work in software.

If another stream comes along and wants to play at say, 80%, we will shuffle things around to accommodate. h/w volume will be set to 80% and the 30% attenuation needed on the first sound is only then applied in software.

So I'm not sure of where you get this mythical "principles of an audio server" from, but it's simply not true. PulseAudio is part of the plumbing layer of linux and it's not just a "bolt on". If you use it, you give it full control.


Another detail of flat volumes is that application volumes are absolute, or "flat". There is no such thing as an Rhythmbox volume of 50% meaning it will reduce the output to half of what the device volume is. It's an absolute. 50% always means 50%. You don't have to do a mental mapping to say, "well it's 50% of something, now what is that something?", you simply always know what it means in absolute terms. This means that if your sink volume is at 50%, and then Rhythmbox's volume cannot be more than 50%. If you increase Rhythmbox's volume beyond that, then you are also pushing up your sink volume to accommodate (other playing streams will be unaffected)


Now all that aside, if you do not like flat volumes, you can disable them in the daemon.conf.




Now as for the real issue here, the adjustment of the volume when the sound being played is muted. I agree, that this is simply a bug and should be fixed. I'll look into this issue for you.

Status: NEW => ASSIGNED
CC: (none) => mageia
Assignee: bugsquad => mageia

OK, I've confirmed with other developers. This problem has been present for a while, but you appear to be the first to notice (I guess not many people actually disable their alert sounds - I guess they probably like hearing their VoIP app ringing when a call is coming in!).

I've reported upstream. I will try to get a fix before mga2, but I cannot promise I will manage that. I will however, push an update later if I do not manage to fix this on time.

Thanks for the report.

Keywords: (none) => Triaged, UPSTREAM
URL: (none) => https://bugs.freedesktop.org/show_bug.cgi?id=48284

(In reply to comment #3)
well, what I actually meant (maybe my wording wasn't perfect, sorry, I'm no native english speaker) was that except for pulse audio nothing should mess with with mixer settings, and I discovered this problem because the music playing was interrupted by a 2 second 'pause of silence' whenever I triggered a bell in a terminal.

my (maybe completely wrong) conclusion was that the alert sound somehow overrides the mixer settings, ignoring the fact that pulseaudio should handle that instead, but maybe this is actually a pulseaudio bug after all ...

in any case, I do not expect the perceived audio playback volume to change when an alert sound is _not_ played, and I probably don't like it to change even if the alert sound is played (I'd expect it to be more like an independant sound source not affecting the other stuff going on)

(In reply to comment #5)
> in any case, I do not expect the perceived audio playback volume to change when
> an alert sound is _not_ played, and I probably don't like it to change even if
> the alert sound is played (I'd expect it to be more like an independant sound
> source not affecting the other stuff going on)

Yup, that's certainly how it should happen (the underlying state of the hardware controls is another matter).

Can I ask something tho': Does the music mute fully (i.e it is totally inaudible) or does it just get quieter? If the former, can you unmute the event sounds, make the volume slightly louder and then mute them again? And see what happens?

Either way, the audible volume of the music player should not be affected by event sounds (even with this bug it *should* change the audible volume of another currently playing stream, although there are other knock on effects). We do however have a module that can specifically cork (pause) and mute a music stream when a phone stream comes along (e.g. when you get a voip call, your music automatically pauses). I wonder if this is misbehaving in some way to cause the actual muting problem....

currently (I just updated to the latest Cauldron) the gnome Alert Sound doesn't work at all except from within the 'Sound Effects' tab of the 'Sound' configuration ... previously it required a logout to apply a change (see Bug 4738) but ATM, it doesn help whatever I do no Alert Sound from a gnome-terminal.

Hi,

This bug was filed against cauldron, but we do not have cauldron at the moment.

Please report whether this bug is still valid for Mageia 2.

Thanks :)

Cheers,
marja

Keywords: (none) => NEEDINFO

No comments for ever. Obviously there is no need to keep open. Housekeeping wins.

Status: ASSIGNED => RESOLVED
CC: (none) => nic
Resolution: (none) => OLD