Bug 324975

Looks like it's due to:

commit 23795b6e3feb6aeea50335566174193378beb589
Author: Harald Sitter <sitter@kde.org>
Date:   Thu Jul 4 02:52:47 2013 +0200

    cache volume inside PAStreams when trying to set it on an invalid one

Revert resolves the issue here

Created attachment 82370 [details]
Output when notification is triggere

(In reply to comment #0)
> Actual Results:  
> Observe volume go to 100%

The volume of what where when? In what application do you change it? In what application does it subsequently go back to 100%?

In data mercoledì 18 settembre 2013 10:06:48, hai scritto:

> The volume of what where when? In what application do you change it? In what
> application does it subsequently go back to 100%?

To answer this, since I'm affected too: I've seen this when trying to adjust 
the volume of system notifications: it is fixed at 100%, and changing it 
produces no effect whatsoever (it's restored to 100%).

– 
Luca Beltrame - KDE Forums team
KDE Science supporter
GPG key ID: 6E1A4E79

(In reply to comment #3)
> The volume of what where when? In what application do you change it? In what
> application does it subsequently go back to 100%?

Main volume, identified in KMix as Built-in Analog Stereo. For the rest:
Kmix, KMix.

Ah. That makes sense.

So what happens... As we can see in the attached output log Phonon always gets its volume set to 1 (i.e. 100%), this is done by knotify. Point being that Pulseaudio manually maps the notification streams into one virtual stream for which KMix can display a convenient slider. However knotify does not "support" volume changes from the outside such that it will not react in any way to Phonon emitting volumeChanged. So knotify keeps setting whatever volume it thinks we need thus forcing Pulseaudio to use 100% rather than 25% or whatever.

The reson why 23795b6e3feb6aeea50335566174193378beb589 now causes it to behave like that is because previously Phonon would essentially (and unintentionally) ignore attempts to set the volume of a non-playing AudioOutput. Something knotify does, so in essence we ignored knotify's volume setting.
Now the thing is that knotify has its own volume control (see notification KCM in systemsettings) which controls the volume. This feature was defunct up until aforementioned commit. So Kmix/Pulseaudio had free control over the volume, seeing as knotify was never able to actually enforce its own volume setting. Now that it can enforce its own setting it overrides the global Kmix/Pulseaudio one leading to the bug at hand.

Possible resolutions (first=worst, last=best):
1. Make knotify listen to volumeChanged of AudioOutput and remember volume changes at least for the duration of a session, not increasing the volume semingly arbitrary
2. Remove volume control entirely assuming Pulseaudio as part of the recommended experience giving users volume control over notifications via kmix (!PA users will of course be left stranded ... the semi-requirement on Pulseaudio for sane experience is already done by Phonon, which is why the next two options actually make sense from a stack coherence POV)
3. Check if Pulseaudio is active and if so do not apply knotify's volume setting
4. As previous but also hide the setting in the KCM
5. Iff Pulseaudio is active, wire the KCM's volume control to use PA rather than the own internal setting (i.e. basically replicate what Kmix already does for knotify's own volume slider)

5.1. [variation of 5 and 1 without linking against PA] listen to volumeChanged and adjust knotify's own volume according to what volumeChanged says. the only time volumeChanged is different from what you set using setVolume is when the volume was changed by a platform override (e.g. when PA's stream volume is altered by kmix), so you can simply compare what the volume should be and what it is and then adjust your own expectation/setting to fit that. this somwhat simulates that knotify's own volume control is the same as PA's/Kmix' without them actually being the same. of course this option is less enjoyable than option 5 as there are multiple layers of abstraction and asynchronization involved possibly leading to weird differences between what knotify the volume needs to be and what PA thinsk the volume should be.

Personally, I'd go for option 2.

I've actually been doing this for 3+ years in Mandriva/Mageia KDE packages anyway where I've completely replaced the knotify sound code with libcanberra (http://colin.guthr.ie/git/KDE/kde-runtime/log/?h=canberra)

Technically, 5 is probably the "right" think to do...

(In reply to comment #7)
> I've actually been doing this for 3+ years in Mandriva/Mageia KDE packages
> anyway where I've completely replaced the knotify sound code with
> libcanberra (http://colin.guthr.ie/git/KDE/kde-runtime/log/?h=canberra)

Your patch still doesn't quite resolve the problem. While the main volume *does not* get restored to 100%, and notification sounds are at the same level as the main one, those cannot be changed (basically, comment 4 is still valid with mageia patch). Personally, i have no problem with that, but then KMix should lose the slider...

(In reply to comment #8)
> (In reply to comment #7)
> > I've actually been doing this for 3+ years in Mandriva/Mageia KDE packages
> > anyway where I've completely replaced the knotify sound code with
> > libcanberra (http://colin.guthr.ie/git/KDE/kde-runtime/log/?h=canberra)
> 
> Your patch still doesn't quite resolve the problem. While the main volume
> *does not* get restored to 100%, and notification sounds are at the same
> level as the main one, those cannot be changed (basically, comment 4 is
> still valid with mageia patch). Personally, i have no problem with that, but
> then KMix should lose the slider...

The patch does not solve the volume-adjustment case for when PulseAudio is not used. But kmix has had an "Event Sounds" slider available for a few years now when PulseAudio *is* used (as is generally recommneded) and this allows indepenedant control of the event sound volume level quite happily.

So while I agree it doesn't help in this use case, we very much target PulseAudio usage and there are several UX things that basically break when not using PA and this is just one of them. Personally, I can live with this!

the solution you adopt is a big regression.

because i want 100 % for global sound and 20 % for notification. i don't like to be disturb by loud notification.

since many years i set separately the global sound volume and the notification volume.
the first years i was using kde settings > notification settings > notification manager > sound reader manager
the later years i used kmix manager.

the main feature coming with PA was now linux has for each app a separated setting for sound.
so saying notification settings are not separated from global volume is the contrary of the basic principle of PA.

(In reply to comment #10)
> the solution you adopt is a big regression.
...
> the main feature coming with PA was now linux has for each app a separated
> setting for sound.
> so saying notification settings are not separated from global volume is the
> contrary of the basic principle of PA.

I think you are misunderstanding. There is already an "Event Sounds" slider in *kmix* under PA. Just use this slider rather than the other one. The "regression" is simply that the slider is with most of your other volume settings rather than hidden away under it's own panel.

Created attachment 82837 [details]
kmix in the systray and kmix manager

@colin

about what slider do you speak ?

see the capture i made about kmix in the systray and kmix manager for opensuse 13.1 rc1

in this capture i see no slider to set sound level of notifications

Comment on attachment 82837 [details]
kmix in the systray and kmix manager

Hmm, your kmix seems to be busted.... There should be an Event Sounds slider listed on the "Flux de lecture" pane. Likely some kind of kmix string matching profile problem.

I'd recommend trashing any local kmix settings ~/.kde4/share/config/kmix* ~/.kde4/share/apps/kmix/profiles/* to see if that restores it.

(In reply to comment #13)
> Comment on attachment 82837 [details]
> kmix in the systray and kmix manager
> 
> Hmm, your kmix semble être démantelé.... There should be an Event Sounds
> slider listed on the "Flux de lecture" pane. Likely some kind of kmix string
> matching profile problem.
> 
> I'd recommend trashing any local kmix settings ~/.kde4/share/config/kmix*
> ~/.kde4/share/apps/kmix/profiles/* to see if that restores it.

i didn't find any "~/.kde4/share/apps/kmix/profiles/*"

i deleted ~/.kde4/share/config/kmix*
then
i closed kde session
then
i opened kde session
then
pb is still there : no slider in "flux de lecture" for setting notification sound level

Hmm, I don't know then.... perhaps your kmix has been patched to not include this? Or perhaps it's just a different version to the one I developed.

Philippe: which exact KDE SC version do you use?

i test opensuse 13.1 rc1 x86_64 with kde 4.11.2 , pa 4

exactly pa 4.0.git.265.g35fe-1.1

phonon-backend-gstreamer-0_10 4.6.80~git20130915-2.1.4

about kmix recent bug fixes log :

sam. 28 sept. 2013 12:00:00 UTC
tittiatcoke@gmail.com
- Update to 4.11.2
  * KDE 4.11.2 bugfix release
  * See http://www.kde.org/announcements/announce-4.11.2.php

mar. 24 sept. 2013 12:00:00 UTC
hrvoje.senjan@gmail.com
- Added Who-needs-event-slider.patch -- since KNotify will no longer
  be able pretending it can control volume, also remove the Event
  slider within KMix

dim. 01 sept. 2013 12:00:00 UTC
tittiatcoke@gmail.com
- Update to 4.11.1
  * KDE 4.11.1 bugfix release
  * See http://www.kde.org/announcements/announce-4.11.1.php

jeu. 08 août 2013 12:00:00 UTC
tittiatcoke@gmail.com
- Update to 4.11.0
  * KDE 4.11 Final release
  * See http://www.kde.org/announcements/4.11/

(In reply to comment #19)
> about kmix recent bug fixes log :
> mar. 24 sept. 2013 12:00:00 UTC
> hrvoje.senjan@gmail.com
> - Added Who-needs-event-slider.patch -- since KNotify will no longer
>   be able pretending it can control volume, also remove the Event
>   slider within KMix

Hmm, this seems totally wrong.... I'd report it to SuSE that their thoughts here seem bogus to me - for starters the event sounds slider here covers many applications, not just knotify-generated sounds. Several other applications produce sounds marked as "Event".

I would recommend replacing the knotify sound code with my canberra version (linked above) which makes all the event sounds slider stuff work perfectly well in kmix (it avoids this whole problem as it doesn't use phonon and pre-specified volume levels)

/me grumbles something about downstreams changing stuff in broken ways which wastes upstreams time.... (then realises his canberra patch is just the same and hides under an irony blanket ;))

@colin

thanks

(In reply to comment #20)
> Hmm, this seems totally wrong.... I'd report it to SuSE that their thoughts
> here seem bogus to me - for starters the event sounds slider here covers
> many applications, not just knotify-generated sounds. Several other
> applications produce sounds marked as "Event".
Sorry about that. We opted for what looked the best option at the time.
 
> I would recommend replacing the knotify sound code with my canberra version
> (linked above) which makes all the event sounds slider stuff work perfectly
> well in kmix (it avoids this whole problem as it doesn't use phonon and
> pre-specified volume levels)
With vanilla KNotify, or with your patch, effect for the event slider is the same, volume is always left at the same level -> thus ineffective. Additionally, your patch removes option for playing event sounds with an external player.

> /me grumbles something about downstreams changing stuff in broken ways which
> wastes upstreams time.... (then realises his canberra patch is just the same
> and hides under an irony blanket ;))
:-) Reasoning was to remove it, as it takes no effect. Which, as said, looked better than to add a patch which changes nothing, and removes one more option on top of that.

(In reply to comment #6)
> 3. Check if Pulseaudio is active and if so do not apply knotify's volume setting
> 4. As previous but also hide the setting in the KCM

Used #4 for ROSA & OpenMandriva. In case anyone needs quick patch to do the same, here it is:
https://abf.rosalinux.ru/openmandriva/kdebase4-runtime/blob/master/kde-runtime-4.11.3-knotify-volume.patch

(In reply to comment #23)
> (In reply to comment #6)
> > 3. Check if Pulseaudio is active and if so do not apply knotify's volume setting
> > 4. As previous but also hide the setting in the KCM
> 
> Used #4 for ROSA & OpenMandriva. In case anyone needs quick patch to do the
> same, here it is:
> https://abf.rosalinux.ru/openmandriva/kdebase4-runtime/blob/master/kde-
> runtime-4.11.3-knotify-volume.patch

If you're patching downstream, I would still advise using the canberra patch I've previously posted rather than this one TBH. It's been in use for several years now without any problems (to be honest I thought it was even like this in the Mandriva days so kinda assumed Rosa would have it, but perhaps I've got my timescales mixed up)

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

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

> If you're patching downstream, I would still advise using the canberra patch I've
> previously posted rather than this one TBH.

No offense, but I wouldn't, sorry. Your patch sounds like an interesting idea for the new Frameworks world and you should discuss it with upstream for there, but for the 4.x series (and especially for a distro patch!), it is IMHO way too invasive and drops a lot of existing functionality. In addition, your 2 commits mention several things that still need to be done.

So I would advise using the patch from comment #23 which specifically addresses the actual issue at hand (and it is what we are planning to do in Fedora).

(In reply to comment #27)
> So I would advise using the patch from comment #23 which specifically
> addresses the actual issue at hand (and it is what we are planning to do in
> Fedora).

Meanwhile I found that my quick patch is not that good as well. It fixes the issue only on some installations.

We are using this in openSUSE
https://build.opensuse.org/package/view_file/KDE:Distro:Factory/kdebase4-runtime/Remove-volume-control-from-KNotify.patch?expand=1

(In reply to comment #27)
> > If you're patching downstream, I would still advise using the canberra patch I've
> > previously posted rather than this one TBH.
> 
> No offense, but I wouldn't, sorry. Your patch sounds like an interesting
> idea for the new Frameworks world and you should discuss it with upstream
> for there, but for the 4.x series (and especially for a distro patch!), it
> is IMHO way too invasive and drops a lot of existing functionality. 

What functionality does it drop? It removes *options* to get the same end result, quite simply because it's pointless having three diffrent ways to play a sound when providing one that actually works is sufficient. That's what I've done with the patch. Concentrate on one system that is used by both Qt and GTK apps alike - one solution, one set of low level testing. Job done. No test matrix explosion from supporting a manually typed in player command and other setup options.

It's *exactly* the kind of thing a distro patch *should* be doing IMO. e.g. remove the options where they are not needed because you ship a product with a working subsystem.

As a distro maintainer I'd rather not have a different codepath to follow if PA is or is not active when dealing with Qt/KDE/GTK apps. With this approach all event sounds played by either KDE or GNOME both go via canberra (where the only PA vs. non-PA decision is made for event sounds) and thus both get the same degree of support and testing.

>In addition, your 2 commits mention several things that still need to be done.

I mention things that need done if it were to be upstreamable. Regarding the usage of it in a linux distro (i.e. ignoring OSX or Windows) where canberra is already shipped and working it's perfectly fine.

I've added all the needed support to KMix for it to show the Event Sounds sliders and I've made sure that if someone *does* use Phonon to play something in the "Notifications" category, it will properly mark it as an 'event' sound when the backend plays via PA. All of this I did several years ago now and the patch is a perfectly fine option when it's build-time constrains are met.

Knowing the Phonon PA code (I wrote 90% of it) and the hoops we have to jump through to bypass to the abstracted-backend and still get control of the PA streams to control the volumes, I'd want to avoid this for event sounds whenever possible. I want my event sounds to play quickly and I certainly don't want some client-side fu to control volume (which will be - almost by design - laggy) and would definitely prefer this to be done properly at the server side for all sounds with the event role which is what my patch acheives.

> So I would advise using the patch from comment #23 which specifically
> addresses the actual issue at hand (and it is what we are planning to do in
> Fedora).

That's up to you. I still disagree that this is the right approach as IMO it adds too many code branches when debugging. Keep it simple, push everything through canberra and don't worry about the other pointless combination of options.

So, looking again at your libcanberra patch, it does seem to make sense. (In particular, I see that existing configurations should still just work, because "use phonon" or "use external player" configs are just interpreted as "use libcanberra", and playing a specific file (not a sound theme) also just works.)

That said, I suppose removing the "use external player" option would not really be needed to fix this issue, only replacing the builtin Phonon-based code by libcanberra should be sufficient.

And of course, as you know, there are several things in your libcanberra patch which are not upstreamable, starting from the direct use of pkg_check_modules.

I'm discussing this on IRC with Rex Dieter and it looks like we will try out your patch in Fedora after all (also considering comment #28, i.e. the ROSA patch not being good enough).

But doesn't your patch also require PulseAudio to be able to control the volume of the notifications? (I see: "// TODO Set volume: CA_PROP_CANBERRA_VOLUME is in dB, so not directly related to 0-100%".) If so, what's the advantage over the openSUSE approach from comment #29 (which just rips out the volume setting from KNotify4)?

(In reply to comment #32)
> But doesn't your patch also require PulseAudio to be able to control the
> volume of the notifications? (I see: "// TODO Set volume:
> CA_PROP_CANBERRA_VOLUME is in dB, so not directly related to 0-100%".) 

I'd just ignore the volume these days. There would be an argument to say you probably do want it when using ALSA but as this is the exception rather than the rule, I'd personally not worry about it too much. Under ALSA there would be no easy way to set the notification volume (which would require adding in the controls again, and even then it's just in this little walled garden and it wouldn't apply to e.g. Skype rings or other notifications so the whole user experience is not great anyway.

> If so, what's the advantage over the openSUSE approach from comment #29 (which
> just rips out the volume setting from KNotify4)?

The SUSE patch basically makes it impossible to set the volume which is fine in itself. It does keep using phonon which is also fine, but I found generally better performance from canberra with sounds actually happening closer to when they are meant to be happening (especially if you use sound-theme:// URLs which can be cached as sample at the PA end, but that's really just a toy for now).

Again, as the general distro "sound guy" I wanted KDE and GNOME to use the same sound output system. It's just easier to keep the same code path whenever possible.

Summary:
 ROSA: Use Phonon for event sounds. Try to detect at runtime if PA is used and only show options for volume controls if it's NOT active.
 SUSE: Use Phonon for event sounds. Sod the whole volume control when not using PA, just rip it all out. If you want volume on event sounds, use PA.
 Magiea: Use libcanberra event sound library for event sounds - same code path as GNOME. Sod the whole volume control when not using PA, just rip it all out. If you want volume on event sounds, use PA.

When I first wrote that patch knotify had a habbit of falling back to ALSA when Phonon could not be used for any transient reason. There was a period of about a year or two when one of the biggest problems getting PA to work was "knotify was hogging the sound card". I got sick of these problems and ripped out the whole of the knotify sound support and just replaced it with canberra and then all the problems went away nicely.

I would still like to see a Qt canberra module (that perhaps uses the Accessibility layer) to generate canberra events for appropriate actions (menu clicked, button pressed etc) and thus support sound themes generally but this is out of scope here.

By the way, using libcanberra, raw ALSA (non-PulseAudio) users will also lose the possibility to select their preferred output device for notifications in the Phonon KCM (because Phonon is no longer used for output). (For PulseAudio users, Phonon enforces priorities for all PulseAudio clients through module-device-manager and so this is not an issue there.)

(In reply to comment #34)
> By the way, using libcanberra, raw ALSA (non-PulseAudio) users will also
> lose the possibility to select their preferred output device for
> notifications in the Phonon KCM (because Phonon is no longer used for
> output). (For PulseAudio users, Phonon enforces priorities for all
> PulseAudio clients through module-device-manager and so this is not an issue
> there.)

Yup, I guess that could be considered a regression. Personally I feel that presenting users with a GUI to select devices that pretended to be global where the user then runs some non-phonon app where none of those settings applied seemed like the wrong approach anyway. One of the many reasons why this whole interface really doesn't work without PA.

The real problem here is that the volume is a property/setting of the "output", instead of the "player". An application shouldn't be able to change the global volume for all other applications in the first place.

Actually, looking at notifybysound.cpp, knotify creates an "output" for "Phonon::NotificationCategory". If changing the volume for this output changes the volume for other output categories, then it is a Phonon bug.

(In reply to comment #37)
> Actually, looking at notifybysound.cpp, knotify creates an "output" for
> "Phonon::NotificationCategory". If changing the volume for this output
> changes the volume for other output categories, then it is a Phonon bug.

At least (slightly ;-) less ugly patch for phonon would then be:

@@ -1332,7 +1332,7 @@ bool PulseSupport::setOutputVolume(QString streamUuid, qreal volume) {
             return false;
         }
         pa_operation_unref(o);
-    } else if (s_outputStreams.contains(streamUuid) && s_outputStreams[streamUuid]->index() == PA_INVALID_INDEX) {
+    } else if (s_outputStreams.contains(streamUuid) && s_outputStreams[streamUuid]->index() == PA_INVALID_INDEX && !Phonon::NotificationCategory) {
         logMessage(QString::fromLatin1("Setting volume on an invalid stream ..... this better be intended"));
         PulseStream *stream = s_outputStreams[streamUuid];
         stream->setCachedVolume(volume);

I am also curious when I should reactivate PulseAudio support for my system.
https://forums.opensuse.org/english/get-technical-help-here/applications/492575-66-sound-volume.html#post2601951

I am having the same problem. However, I noticed that if you go to System Settings ->Manage Notifications then Player Settings, the volume bar will be at 100%. Changing that volume DOES change the notifications volume system wide.

This is now broken on a pulseaudio-less system too. Amarok experiences the same (initial volume on amarok start is set to 100% regardless of what the Amarok volume slider is set at, adjusting the slider returns the volume to the slider setting). Also knotify4 crashes if it tries to play two or more notifications at once.
KDE 4.11.4
works fine with phonon-4.6.0/phonon-vlc-0.6.2/vlc-2.0.9
broken with phonon-4.7.1/phonon-vlc-0.7.1/vlc>=2.1.0

I like the "less ugly patch" from Hrvoje :-) (comment #38).

Anyway, can we have consensus on a patch and an actual fix of the problem, pretty please?

This bug is annoying, TIA.

Why is this a knotify bug? Shouldn't that be moved to Phonon?

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

(In reply to comment #43)
> Why is this a knotify bug?

Due to:
> Harald Sitter <sitter@kde.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
> Status|NEEDSINFO                   |CONFIRMED
>             Version|4.6-git                     |unspecified
>           Component|Pulsesupport                |knotify
>            Assignee|sitter@kde.org              |ogoffart@kde.org
>          Resolution|WAITINGFORINFO              |---
>      Ever confirmed|0                           |1
>    Target Milestone|4.7                         |---
>             Product|Phonon                      |kdelibs
> 
> --- Comment #6 from Harald Sitter <sitter@kde.org> ---
....

On the user side of things, possible workaround, without patching, would be to disable PA's flat volume feature...

I do have flat volumes disabled, and yet I experience https://bugs.kde.org/show_bug.cgi?id=329166 which was recently marked as duplicate of this bug. However, in my case it's the *Amarok* volume slider which jumps to 100%, not the one of the sound device.

I had the same problem : "Volume gets restored to 100% after each knotify event"

Resolved by reading the post of pjeturgh, May 2011
http://forum.xbmc.org/showthread.php?tid=93839

>>So the solution - in my case at least - was to edit the /etc/pulse/daemon.conf and set "flat-volumes = no"

If it can be of use to somebody!

confirmed with latest 4.12.2:  'events sounds' jumps back to 100% after an event sound happened.

Bug is that events sound volume is read from system settings:

   Application and System Notification -> Manage Notification -> Player Settings ->  Volume
  (default is 100%)

Whatever volume is chosen and applied in this kcm is used to play event sounds.
Try to set it to e.g. ~ 30 % apply and enjoy a moderate event sound ;-)   For all future
sound events the mixer volume of 'event sounds' jumps to this setting from the kcm.

Bugs:
1) kcm volume settings do not read/update the mixer settings
2) event system uses whatever the kcm stored not what's set with the mixer
3) minor: kcm has no way to test the volume setting.  One has to apply and generate a event that has a sound setting to check if the chossen volume feels right.

(In reply to comment #34)
> By the way, using libcanberra, raw ALSA (non-PulseAudio) users will also
> lose the possibility to select their preferred output device for
> notifications in the Phonon KCM (because Phonon is no longer used for
> output). (For PulseAudio users, Phonon enforces priorities for all
> PulseAudio clients through module-device-manager and so this is not an issue
> there.)

I use Opensuse 13.1, KDE 4.12. With PA activated I had the same problems as described here. 

That is one of very many reasons why I deactivate PA on most of my 10 Opensuse systems. However, I have understood that I then loose all possibilities the to adjust the volume of system notifications independently of other sound sources in the system.   
So the situation is, that KDE forces users to use PA to get control over the relative volume of system notifications via pavucontrol. But if we use PA then we get bugs as the one described here - among many other problems. If it is not too far off topic. Could someone comment on the fact, that we are "forced" to use PA at all - as Kevin Kofler also indicated in his comment ?

Just to make it clearer, cause I missed it at first, too: There's a separate volume slider in the notification settings (kcmshell4 kcmnotify) that is setting the initial volume for these sounds. Sliding it down to 25% was the acceptable workaround for me.

(In reply to comment #50)
> Just to make it clearer, cause I missed it at first, too: There's a separate
> volume slider in the notification settings (kcmshell4 kcmnotify) that is
> setting the initial volume for these sounds. Sliding it down to 25% was the
> acceptable workaround for me.

Can you elaborate where this slider would be ? I do not find it on my Opensuse 13.1. It used to be under the "Player Settings" tab - but SuSE removed it from there. Because they claim it does not work anyway. 
Could that mean that Opensuse has deactivated and removed something that they only think to be not working ? But it does actually work on a raw Alsa system without PA ?

Oh, didn't realize Suse did that. Never mind then. Not sure what it would do without PA.

(In reply to comment #52)
> Oh, didn't realize Suse did that. Never mind then. Not sure what it would do
> without PA.

I got some RPMs from Wolfgang Bauer without the SuSE Patch. So the slider under the "Player Settings" then became available. However, on my system without PA it had no effect on the volume of the system notifications. Unfortunately the related bug 
https://bugs.kde.org/show_bug.cgi?id=324975    
was closed - with reference to SuSE - although SuSE can't do anything about it. So, as I said : KDE forces people to use (a buggy) PA if they want to get control over the volume of the system notification - or they have to turn off system notifications completely.

>  So, as I said : KDE forces people to use (a buggy) PA if they want to
> get control over the volume of the system notification - or they have to
> turn off system notifications completely.

Although it is a side discussion I need to correct myself: After a new test of W. Bauer and tests on my own systems I regret and take back some of my previous statements.  

Actually, on all of my raw alsa systems 
* without PA, 
* with gstreamer as phonon backend
the original KDE slider in the system notifications kcm (under the "player settings" tab) HAS the expected effect.  
The only thing that the slider position under "player settings"  does not influence on systems without PA is the volume of the notification TEST sound  of kcmshell4 kcmnotify. That was the source of my misunderstandings because I expected to hear a reduced sound there after using the kcm slider. 
However the slider DOES have the desired effect on real notification sounds generated due to system and application events. It was W.Bauer who found that out. 
 
I have afterwards confirmed this on some of my own Opensuse 13.1 systems 
- with KDE 4.12 packages without the SuSE patch (RPMs provided by W. Bauer), 
- without PA and several soundcards as realtek chips, audigy 2, terratec aureon 5.1. 

So it is NOT AT ALL true that KDE forces me to use PA to get control over the  notifications sound volume. Sorry for my misunderstandings and my limited testing in the beginning.  PA is only required on Opensuse systems with the patch that eliminates the kcm slider.

I have tested the 3 patches proposed above (#7, #23, #29), on a debian system.
The first two did not solve the bug (volume was still restored to 100% after each notification); instead #29 (the patch from opensuse) worked for me (even though the "event sounds" volume slider became ineffective)

I think this bug should have been marked as no less than critical because it has a potential to physicaly damage user's hearing when using headphones which usually require much lower global volume than passive speakers.

I think this bug is invalid because real bug is here:
https://bugs.kde.org/show_bug.cgi?id=337034

It's been nearly a year and the speakers and hearing of KDE users and everyone else in earshot are *still* being assaulted by this. **Let's get this moving.**

If an ideal fix can't be worked out in a reasonable time frame (which we've already blown waaaay past), then at the very least a temporary makeshift solution needs to be made, even if it means going so far as reverting the bigfix that exposed this bug in the first palce. THIS IS A CRITICAL ISSUE, and as Václav Pokorný pointed out, it can even even be a health hazard. This is a critcal embarrasement to KDE and makes the whole project look bad.

Thank you for the workaround. But why on earth does KDE notification think it has any business adjusting the volume in the first place - I often keep the volume down when working in the night, and up when working on at day in a noisy environment.

If it really has to adjust the volume for the notification sound, it should at apply to the notification sound only, and not leave the system in a different state. 

If you need to mess with the volume at all, could you at least make the messing optional, so that I could turn it off after carefully adjusting my volume to a level that suits my current situation.

I agree that this issue should be critical, or at least very important. The social cost of suddenly playing everything at 100% volume can be high!

I think this issue is just being ignored.

Nevertheless, this is a major issue

Health first, it is dangerous to let that issue, when using earphones it could hurt the user ears when suddenly going to 100% volume...

Second point, lot's of none KDE software are best using pulseaudio so KDE must be aware with it smoothly for better user experience !

Third, when you work in an openspace office, the social cost of the system notification is awesome !

For all this reason we need a robust workaround or definitely resolve this issue...

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

I've had a light case of tinnitus for a couple of years.  This bug caused a very loud blast to my earphones and now my tinnitus has gotten worse (louder).
It is not a question of if this bug will cause physical damage it is how many will be affected and how badly.
Please fix this.

I was very pleased to be made aware of this bug when I was listening to music on my headphones today, and someone highlighted me on IRC, triggering a knotify event.

Does that mean we can classify it as remotely exploitable now?

I agree with newbeewan@nativobject.net

This is major issue. I use headphones all the time. I can tell you it's not a really nice suprise when you listen to a music track and then volume suddenly, for no visible reason, jumps to 100%. I'm not feeling very pleased after that sudden blast of sound reaching my ears.

Additionally, the social cost is another reason to fix this. And after all, this is a bug, not a feature, so it must be fixed. And as an end user, I care about the end-user friendly fix for this issue.

As a workaround until it is fixed, you can configure notifications to not use the KDE sound system, but use an external player. This may also fix some other issues, such as gstreamer/vlc issues, growing memory usage etc.

Konsole > "kcmshell4 notify" > Player Settings

(using "mplayer" since ever; there are probably lighter alternatives, but it works for me.)

Btw, I still do not understand why the volume setting that knotify uses for "Phonon::NotificationCategory" output is suddenly applied to the master volume, but I do not feel like reassigning this back to Phonon, because I just do not understand where the issue is. Comment #6 needs a diploma that I do not have :)

I have selected this bug as the "Bug of the Month". See https://community.kde.org/Gardening

If you are able to fix it, you will receive a honorable mention in the next issue of my blog post "The Bug of the Month" on Planet KDE.

We do not have a knotify maintainer. If the issue is in knotify, please suggest a patch with anything that fixes it and create a review request at https://git.kde.reviewboard.org/ and paste the link here. If the issue is in Phonon, its backends, in gstreamer, VLC, pulseaudio, or ALSA, please suggest a patch there.

Not all developers that would be able to fix it are subscribed to this bug. If you know someone, feel free to point him here.

If we receive multiple patches, we will have to decide which of them is best suited, and nominate one of them for the fix.

Git commit b40c51fb0247833a7e92e75ea54931e510c3ffb0 by Albert Astals Cid.
Committed on 04/12/2014 at 21:03.
Pushed by aacid into branch 'master'.

Make changing the volume on notifications optional and disabled by default

I don't see why we should change the volume at all, let the user decide their volume, but since we have the feature i didn't want to remove it completely and instead left if disabled by default.

Acked by davidedmundson and sitter
REVIEW: 121278
FIXED-IN: 15.04

M  +5    -2    kcontrol/knotify/knotify.cpp
M  +121  -113  kcontrol/knotify/playersettings.ui
M  +22   -9    knotify/notifybysound.cpp

http://commits.kde.org/kde-runtime/b40c51fb0247833a7e92e75ea54931e510c3ffb0

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

(In reply to Christoph Feck from comment #69)
> *** Bug 344985 has been marked as a duplicate of this bug. ***

Yes I agree that this is a duplicate, but shouldn't we reopen the issue?

No, because your bug report did not state that you are running kde-runtime 15.04.

I suppose volkan assumed it to be a Kmix bug. I too can confirm it happens again in plasma 5 (desktop version 5.2.1).

This bug is again present in KDE Frameworks 5.7.0. Volume resets to 100% when a notification event pops-up. Already tried the following to no effect:

1. Setting flat-volumes to 'no' in /etc/pulse/daemon.conf
2. Muting the Event Sounds altogether.
3. Switching phonons

There is also no Player Settings tab anymore in Plasma 5 Knotify.

Re: comment #73

Can you confirm you're also testing using kde-runtime 15.04 ? (see comment #71)

(In reply to Rex Dieter from comment #74)
> Re: comment #73
> 
> Can you confirm you're also testing using kde-runtime 15.04 ? (see comment
> #71)

No. I'm on 14.12.2. Distro: Manjaro Linux 0.9.0-pre3

I have exactly the same bug as Saad and this situation is not only annoying but also dangerous for hearing! Especially while you are listening music on 15% volume with headphones and suddenly volume increases to maximum. Please, fix it ASAP.

Software:
* Arch Linux with latest updates and KDE5
* kdebase-runtime 14.12.3-1
* plasma-framework 5.7.0-1 (kf5)
* kmix 14.12.3-1

> * kdebase-runtime 14.12.3-1

This bug is fixed in kdebase-runtime 15.04, but not in 14.12.

See https://www.kde.org/announcements/announce-applications-15.04-beta1.php

(In reply to Christoph Feck from comment #77)
> > * kdebase-runtime 14.12.3-1
> 
> This bug is fixed in kdebase-runtime 15.04, but not in 14.12.
> 
> See https://www.kde.org/announcements/announce-applications-15.04-beta1.php

OK...

I just experienced this today, while I was studying, with headphones on. Very, veeeery, bad bug to experience that way.

I hope this gets patched in all code bases relevant so that ti won't pop back up if someone uses an older version.

I still can reproduce the issue with phonon-backend-vlc (it doesn't happen with gstreamer).
I filed a new bug report about that: bug#345651

As a workaround, you can _enable_ the volume control in Systemsettings->Application and System Notifications->Playback Settings (if you are already using 15.04, if not it should be enabled anyway), and set a lower volume than 100% there.

I have a new install of Kubuntu 15.04, done today. I am experiencing this horrible bug with headphones. A rare instance of a glitch being able to physically hurt you. It seems it was not resolved, after all...

To clarify: "Event Sounds" sounds completely ignore any and all settings I set for them either through Pulse Audio or KMixer. Any time a new sound occurs, even if I have MUTED Event Sounds, it will restore itself to maximum volume and then play. Very painful way to discover this glitch.

What's worse, whereas in 14.xx and earlier versions, you could go to System Settings ---> Application and System Notifications and fix this sound issue there, this section of settings has apparently been removed from 15.04. 

How can I fix this? Right now, it essentially means I can't use headphones with Kubuntu...

(In reply to shiran from comment #82)
> To clarify: "Event Sounds" sounds completely ignore any and all settings I
> set for them either through Pulse Audio or KMixer. Any time a new sound
> occurs, even if I have MUTED Event Sounds, it will restore itself to maximum
> volume and then play. Very painful way to discover this glitch.
> 
> What's worse, whereas in 14.xx and earlier versions, you could go to System
> Settings ---> Application and System Notifications and fix this sound issue
> there, this section of settings has apparently been removed from 15.04. 
> 
> How can I fix this? Right now, it essentially means I can't use headphones
> with Kubuntu...

nano  ~/.config/knotifyrc
[Sounds]
Volume=25

logout

See if this helps.

No, it did not help.

I use Plasma 5.3.1, Framworks 5.10.0 and Apps 15.04.2
and I can confirm that this bug is not fixed.

I observe the following:
- Open Systemsettings
- Change some settings and click "Back". This will trigger a notification which asks you wether you want to save the changes or discard them.
Now: The first time this notifications appears after starting 'Systemsettings' it sets the master volume to 100%.
I can trigger the mentioned notification again (without restarting systemsettings) and oh wonder: it doesnt reset the volume to 100% any more and the sound is overall quieter (even at 100%).
All following notifications behave like this until I completely close and restart 'Systemsettings'. Then the first notification in this 'session' raises the volume again.

The above is reproducible on my system.

(In reply to Lukas Schneiderbauer from comment #85)
> I use Plasma 5.3.1, Framworks 5.10.0 and Apps 15.04.2
> and I can confirm that this bug is not fixed.

This is fixed in Plasma5 by removing that volume control from systemsettings, just like it is fixed in KDE4 by disabling that volume control by default.

What Phonon backend are you using?
If it's VLC, see comment#80.

Unfortunately, as the volume control in systemsettings has been removed completely in Plasma5, you cannot use it to prevent the issue either.

I am using the GStreamer backend for Phonon. Don't even have the VLC backend.

Please open a new bug, the cause for *this* one was fixed

Not sure whether this is off topic - but I suffer from the consequences of the bug solution: 

I use Opensuse 13.2 with  Frameworks 5.10 and Apps 15.04. I do not use pulseaudio (PA), just plain Alsa and the gstreamer backend for phonon. I do not experience the bug.

However, the volume slider in KDE systemsettings for notifications has been removed as part of the solution of this bug. 

Therefore,  I cannot change the volume of system notifications any more. It seems to have a fixed default value.  In Kmix there is no special slider for controlling notification audio streams either.    

Can someone of the KDE specialists give me a hint how I get control over the volume of system notifications if I do not use PA? (Which I have no intention to do because it still is buggy in very many respects ...).

I too have this issue, Debian 8 with KDE plasma-desktop 4.11.13, VLC backend 0.8.2.  It's beyond annoying and it's an hourly issue.

Using mouse wheel over the Amarok icon, I can turn down Amarok to, say, 60% and that also turns down 'Built In Analog Stereo' to be that same 60% (I hate this, by the way; I want separate volumes).

Then Dolphin has a KNotify audio stream that is 100% and pulls the 'Built in Analog Stereo' to 100% as well (because these aren't separate volumes).  That keeps Amarok at 60% until the end of this music track, but KNotify events are SUPER loud, 100%.  The next Amarok track is then 100% volume again, as is everything else.

Please don't let one volume affect another, this is horrible design.  If I chain real audio equipment on a shelf, they don't affect each others level-out volumes.  This shouldn't either.

(In reply to Jeffrey G Thomas from comment #90)
> I too have this issue, Debian 8 with KDE plasma-desktop 4.11.13, VLC backend
> 0.8.2.  It's beyond annoying and it's an hourly issue.
 Please see comment#80 and bug#345651 .

In short, switch to the gstreamer backend.

> Please don't let one volume affect another, this is horrible design.
This is how current PulseAudio is designed, complain there. You can workaround that by setting "flat-volumes=no" in /etc/pulse/daemon.conf .

(In reply to Ralph Moenchmeyer from comment #89)
> Not sure whether this is off topic - but I suffer from the consequences of
> the bug solution:

No, you do not.
This bug's solution was to disable the volume control by default in KDE4, but let the user choose to enable it again.

Yes, it has been removed completely (and the whole "Advanced" tab) in Plasma 5, but that's unrelated to this bug report AFAIK.

I would appreciate it myself if that option would be re-introduced in Plasma 5.
In particular as it is the only workaround to use the vlc backend.

But it doesn't help at all to discuss this here IMHO, in a closed KDE4 bug report (which is fixed indeed according to my experience) with over 90 comments.

Could you please open a new one (wishlist) for this please?
Thank you,

I am using openSUSE 13.2 x64

After each reboot the volume gets reset to about 60-70% and when I play something it is so loud that it is causing distortion.

Why is this happening when I have explicitly set the global volume at 20% in KMixer and also for each application?

I also notice that trying to play a video (YouTube, Vimeo) in Firefox causes the same effect. If the volume in Vimeo's player for example is set to 50% - this affects the global volume in KMixer and it is too loud. I don't think it is normal the web player to affect the system volume. This doesn't happen in Chromium for example.

Is there a bug or is something more to be configured?

(In reply to george from comment #93)
> I am using openSUSE 13.2 x64
> 
> After each reboot the volume gets reset to about 60-70% and when I play
> something it is so loud that it is causing distortion.
> ...
> Is there a bug or is something more to be configured?

There is a problem with VLC itself, see comment#80 (or #91).

If you are using Phonon's VLC backend, switch to gstreamer in systemsettings ("Configure Desktop" in openSUSE)->Multimedia->Audio and Video Settings.

Or, better, just uninstall phonon-backend-vlc completely (or phonon4qt5-backend-vlc in case you are using Plasma5).
The version in 13.2 doesn't work anyway with the latest vlc versions, and misses features compared to the gstreamer backend.

Thanks Wofgang.

I am not using vlc at all but I notice that pulseaudio-equalizer resets the master volume to 100% on every (re)boot, so I had to write a short autostart script that sets it back to 25% as a workaround. Not sure if this is related to the issue here.

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

I think this bug is related to what I'm experiencing.  I just installed Sabayon from their 15.11 monthly ISO.  Whenever there's a knotify event, the "Built-in Analog Audio Stereo" volume level goes to 100%.  Also, whenever I play a video in VLC or listen to music in Amarok, their volume controls directly change the Built-in Analog Audio Stereo levels.  Sabayon does have Phonon VLC by default, but I also tried Phonon Gstreamer, and it all behaved the same way.

I don't know if there has been a regression or what, but I'm kind of starting to get desperate for a solution.  I'm afraid to listen to anything on the off chance a knotify event fires off and suddenly my volume spikes.  And I can't watch anything in VLC without throwing everything out of whack.

Have FC23 here and looking for a solution to adjust the notify volume from kmail for "new mail". So far found nothing. Now the default is 100% :-(

use kmix

I have tried kmix of course- Firstly the slider pops up only during the short bling and is hard to catch. Even when I catch it and have the 0.5s time to adjust it, the volume will still be 100% at next beep.

(In reply to dag from comment #100)
> I have tried kmix of course- Firstly the slider pops up only during the
> short bling and is hard to catch. Even when I catch it and have the 0.5s
> time to adjust it, the volume will still be 100% at next beep.

Then something is not working as designed. Event sounds should have a static slider that is always present.

If this slider is not there, then something has likely changed in the code.

If it is there but your event sound still appears and disappears super quickly then the application generating it is likely not tagging it properly as being an event sound and should be fixed.

You should try and run "pacmd list-sink-inputs" while the sound is playing (might be hard to catch!) and you can inspect the proplist there to see what it's media.role property is. If it's not "event" then the app generating it (or it's event sound library) needs to be fixed.

(In reply to Colin Guthrie from comment #101)

> If this slider is not there, then something has likely changed in the code.

The event slider is there Ok, but doesn't affect the kmail "mail-notify" sound at all.

> You should try and run "pacmd list-sink-inputs" while the sound is playing
> (might be hard to catch!) and you can inspect the proplist there to see what
> it's media.role property is. If it's not "event" then the app generating it
> (or it's event sound library) needs to be fixed.

It is not going under the "event" label. Kmail will have it's own label during the sound event. Might have something to do with the mess with Qt5 in FC23 at the moment? So are you telling me that this has nothing to do with knotify and should be reported to the kmail guys instead?

I don't think this is related to Qt5, since this bug first appeared on KDE 4.12, which used Qt4.

Fabio

Have to add that the solution in Comment 47 (Setting the pulse-audio most stupid default changing the master volume together with any slave volume from "yes" to "no") made this bug a lot more tolerable. Now the notification only blasts at 100% x Master volume setting, not 100%x100% setting which killed my ears. So copy/paste from the comment: 

>>So the solution - in my case at least - was to edit the /etc/pulse/daemon.conf and set "flat-volumes = no"

"I see that same happens in pavucontrol , in KDE, even without kmix running
Increasing the volume of one stream increases the volume of master channel , doesn't make sense I increasing volume sound in one stream audio and master audio is also increased ? . When I choose volume in one stream , master volume control shouldn't change to the same level of sound of the stream. 
Worst is I have a app saved which the stream was saved at maximum, I left application , I reduce master volume to very low level but not mute, I open the app and volume goes to maximum (same level of the stream of the app). 
Disabling flat-volumes [1], things back to normal i. e. master volume doesn't change when I change the level of a stream sound . "
Conclusion is a pulseaudio problem. 

[1] https://wiki.archlinux.org/index.php/PulseAudio/Troubleshooting#Clients_alter_master_output_volume_.28a.k.a._volume_jumps_to_100.25_after_running_application.29

(In reply to Sérgio Basto from comment #105)

> Conclusion is a pulseaudio problem. 

Not entirely: The notification should never be blasted out at 100% anyway, but there should be a way of setting the initial volume. Perhaps for any KDE program. Or the default initial volume should be way lower. 

The pulseaudio bad default only made this bug more visible (audible ;-) )

(In reply to FabioLima from comment #103)
> I don't think this is related to Qt5, since this bug first appeared on KDE
> 4.12, which used Qt4.
(In reply to dag from comment #106)
> (In reply to Sérgio Basto from comment #105)
> 
> > Conclusion is a pulseaudio problem. 
> 
> Not entirely: The notification should never be blasted out at 100% anyway,
> but there should be a way of setting the initial volume. Perhaps for any KDE
> program. Or the default initial volume should be way lower. 

KDE4 does allow you to set the notification volume in systemsettings (the fix for this bug report disabled it by default because it forced the volume to 100%, its default setting).
You can enable it again though and set a lower volume.

In KF5, this option has been removed.

So it is related to KF5 (not Qt5) and should be reported separately I think, as this bug report was about KDE4.

(In reply to Colin Guthrie from comment #101)
> (In reply to dag from comment #100)
> > I have tried kmix of course- Firstly the slider pops up only during the
> > short bling and is hard to catch. Even when I catch it and have the 0.5s
> > time to adjust it, the volume will still be 100% at next beep.
> 
> Then something is not working as designed. Event sounds should have a static
> slider that is always present.
> 
> If this slider is not there, then something has likely changed in the code.
> 
> If it is there but your event sound still appears and disappears super
> quickly then the application generating it is likely not tagging it properly
> as being an event sound and should be fixed.

As mentioned already, that's what happens with the vlc backend and is apparently a bug/missing feature in VLC (2.2.x) itself, see Bug#345651 .

It works as expected with the gstreamer backend here (on openSUSE), KMix's event slider does correctly regulate KDE's notification sounds in KDE4 and Plasma5.

Unfortunately that event volume control is not available in Plasma5's new volume control applet AFAIK, and the separate application volume controls are only available in the applet's settings, not the popup, but that's again unrelated to this bug report...

I realize this is an old thread, but I'm new to Fedora (and Linux for that matter) I just loaded and updated Fedora 23 on a Lenovo T450.  I have the same problem as most of the others on this thread.  I can adjust my volume below 100% but as soon as a sound plays it will reset to 100%.

Is there a quick fix or do I have to keep my sound muted until Fedora patches it?

Thanks in advance

fedora includes the fixes referenced here, if you're still seeing similar symptoms, the cause is (most likely) different.

(In reply to Rex Dieter from comment #109)
> fedora includes the fixes referenced here, if you're still seeing similar
> symptoms, the cause is (most likely) different.

So, if I already ran "dnf update" it will have already included the bug fix discussed in this thread?

Ok, Thanks for the quick reply.  I'll keep searching the "interwebs" ;)

Kelly

Also annoyingly reproducible on debian stretch. About one of ten times I close video on SMPlayer, go to dolphin and start new one.