Description of problem: Please see bug 1896 where this is discussed in depth. This bug has been created to allow the update to be validated. Radiotray volume is interacting strangely with the system volume. Comment 18 describes it well. ========= 1. Increasing the radiotray volume, increases also the system volume. So, system volume follows the increment of radiotray volume. That happens only when radiotray is "playing" (a radio station), not when it's idle in "system tray". 2. The opposite doesn't happen. For example: Both volume levels are up (let's say 75%) and I turn down the volume level in radiotray, the system volume does not follow, it stays at 75%. 3. If the radiotay volume is in a level and I only change the system volume level, both ways (up or down), the radiotray volume does not change. ==========
Assignee: bugsquad => jani.valimaaSource RPM: radiotray-0.6.4-1.0.mga1.src.rpm & radiotray-0.6.4-1.0.mga1.tainted.src.rpm => radiotray
CC: (none) => stormi
This is intended. It's called Flat Volumes. If you don't like it, you can turn it off in ~/.pulse/daemon.conf by setting flat-volumes=no (I think... have a look in /etc/pulse/daemon.conf to double check the syntax). The idea is to ensure that application volumes are absolute. e.g. in the old world individual applications will have a multiplying effect (when thinking in dBs) with the system volume. For example I might set an application to 25%. This number in itself is meaningless. I cannot tell from just looking at that number how loud the app might be because it is multiplied with the actual hardware volume. e.g. if the h/w vol is at 100% then, yes, the app will be at 25%, but if the h/w vol is 50% then the application is actually at 12.5%. This is obviously not good from a usability perspective, so flat volumes were introduced. This is similar to a feature in Windows 7 (maybe vista?) which ensures that individual application volumes are as they state: when it says 25% it is 25%. If the system volume is at 50% then the application can happily remain at 25%, but if you raise the application about 50% then the system volume *has* to increase to accommodate this. If any other applications are playing at that time, their volume will be kept consistent. However, if any applications are not running at that time, their saved volume will remain the same and thus they may be restored louder or quieter in the future. I can understand why this latter bit may be the killer for some people, but it also has it's benefits. For example, if you change your h/w volume you likely *do* want your applications to scale with it! Thus, you have to store the volumes as a factor, not an absolute. I hope this explains the feature. Obviously some people like it and some don't. Personally I think it's a win usability wise, and the fact this is the first bug report I've had about it (and it's been enabled for a long time) kinda backs this up! But if you really hate it, feel free to turn it off. Col
Status: NEW => RESOLVEDCC: (none) => mageiaResolution: (none) => INVALID
I'm quite uncomfortable with that change but maybe it's just a question of habit. I always found the old way clear and simple to use : applications have a relative volume of the system volume. What makes me uncomfortable is that it's meant to be a usability improvement but all those who tested radiotray were unable to understand what was going on. Either the way it works is too complex for users to understand what happens, or we're just stuck into old habits.
(In reply to comment #2) > I'm quite uncomfortable with that change but maybe it's just a question of > habit. I always found the old way clear and simple to use : applications have a > relative volume of the system volume. What makes me uncomfortable is that it's > meant to be a usability improvement but all those who tested radiotray were > unable to understand what was going on. > > Either the way it works is too complex for users to understand what happens, or > we're just stuck into old habits. (but thanks for the explanation :))