| Summary: | Radiotray Volume Control Affecting System Volume | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | claire robinson <eeeemail> |
| Component: | RPM Packages | Assignee: | Jani Välimaa <jani.valimaa> |
| Status: | RESOLVED INVALID | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | mageia, stormi-mageia |
| Version: | 1 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://bugs.mageia.org/show_bug.cgi?id=1896 | ||
| Whiteboard: | |||
| Source RPM: | radiotray | CVE: | |
| Status comment: | |||
|
Description
claire robinson
2011-08-31 12:13:56 CEST
Manuel Hiebel
2011-08-31 12:16:24 CEST
Assignee:
bugsquad =>
jani.valimaa
Samuel Verschelde
2011-08-31 12:27:48 CEST
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 =>
RESOLVED 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 :)) |