'Twas brillig, and Gregory Petrosyan at 30/01/11 15:47 did gyre and gimble: > Hi, > > Can somebody please explain what flat-volume, actually, is? Strictly > and concisely, but from user's perspective ? not mathematically. Like > I can explain what non-flat-volume is to anybody :-) I have googled > quite a bit, but still don't get how it works. The way I think about it is the simple underlying principle: "Always try to use the hardware volume controls". If only one stream is playing and the "System" volume is, 100%, and only one "Stream" is playing and it's volume is 50%, then set the underlying hardware controls to "50%" while all the time keeping the (illusion of the) "System" volume at 100%. The key here is separating the concepts of the "System" volume and "Hardware" volume - the two are no longer one and the same. A more technical solution would be the "Hardware" volume is always MAX(All Stream Volumes) (except when COUNT(All Streams) == 0, in which case Hardware Volume == System Volume). System volume is always >= MAX(All Stream Volumes) With this in mind, it can be confusing looking at the Hardware volume (alsamixer -c0) while streams with different Stream Volumes come and go in PA as it can jump about in a seemingly erratic manner, while PA's notion of a System volume remains static. But the key is to break the conceptual connection of System volume to underlying Hardware volume. (FWIW, I've used System volume above rather than Sink Volume as I think it's clearer as an explanation). > Also, what does m-s-r actually save? Is it "volume the app will have > if the system volume will be 100%" in case of flat volumes? IIRC it contains the relative offset from System volume as a factor - e.g. if System volume increases, so does application. This can be seen quite easily by simply setting System volume to 75%, and a Stream volume to 50% (factor of two thirds). Then increase the System volume to 100% and see how the Stream volume moves to 67%. I think it is this factor that is actually stored (but I could be wrong). Looking briefly at the code, it stores a standard pa_cvolume structure (volume for each channel), but when m-s-r, saves and subsequently applies the volumes, it does so in non-absolute mode, which means that it saves the relative ratio and when it's restored, it's multiplied by the sink's reference volume. So in the case of the example above, it would be stored is always two thirds regardless of whether the sink volume itself was changed. > I am asking these, because I've managed to make an app restore the > volume properly using ext-stream-restore.h, but when I turn the flat > volume on, behaviour is counter-intuitive to say at least. Can you elaborate on this a little? When you say "you've manage to make an app restore the volume properly using ext-stream-restore.h" what do you mean? Do you mean you are making an editor for the stream restore database or are you just meaning that you have an audio producing app and you are manually using ext-stream-restore.h to get it's saved volume and are doing something with it manually to set it's own volume? If the latter, don't do that, the server handles all that for you automatically. If the former then cool. I'd have to look further at how the reference_ratio and the reference volumes themselves work in non-FV mode to give anymore insights but others may be more familiar with that already without having to poke around as much as me. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/]
