Re: [pulseaudio-discuss] Per-app flat volume adjustment is highly unintuitive, if mathematically consistent.
On Wed, May 27, 2009 at 04:16:11AM +0200, Lennart Poettering wrote: On Wed, 27.05.09 12:02, Finn Thain (fth...@telegraphics.com.au) wrote: On Wed, 27 May 2009, Lennart Poettering wrote: You are misunderstanding the flat volume logic. Probably. But since attenuator knobs don't tweak each other (rather I am in control), I think you can read what I wrote as arguing against flat volume logic, on the grounds of intuitive behaviour. Sorry, I don't buy this. PA is not KDE. We try to handle things automatically if we can and only expose a minimal set of controls. I am trying my best to merge as many sliders in our pipeline into one as possible. Sure it takes away control. But that's the purpose of the whole think. I realize I often deviate significantly from the norm, but I do like parts of that idea. Specifically the minimal parts. I don't want to be mucking around with per-app volume sliders at all. Just normalize all the streams so they play at exactly the same loudness(*) relative to a common reference, and give me a single attenuation/gain control knob at the end of the pipeline that sets that reference...preferably a physical knob, actually, but software emulation of a physical knob is sometimes acceptable. BTW, When I write attenuation/gain, I really do mean gain, in software, and I know it can lead to clipping distortion. Some distortion is acceptable if it helps make bad recordings of speech intelligible, and necessary if the audio hardware's output is weak relative to ambient noise levels. Google talks seem to need this sort of processing more than other recordings in my experience. (*) yes I know loudness is subjective, and normalization is awful. I'm listening to a computer playing crappy mp3's and videos and telling me about my incoming email over a Bluetooth headset while riding a bus or a bike. I don't need accurate audio rendering, I just need it all to have the same volume before it gets sent to the headset. Once I'm on the road, the only convenient control I have at any point in the system is the headset's volume control. I'm not trying to get my system THX-certified, and I actually consider the inability to accurately render double-digit-dB loudness changes at all to be a feature. signature.asc Description: Digital signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Per-app flat volume adjustment is highly unintuitive, if mathematically consistent.
On Thu, May 28, 2009 at 02:05:23AM +0200, Lennart Poettering wrote: On Thu, 28.05.09 01:47, CJ van den Berg (c...@vdbonline.com) wrote: On Thu, May 28, 2009 at 01:33:48AM +0200, Lennart Poettering wrote: On Thu, 28.05.09 00:53, CJ van den Berg (c...@vdbonline.com) wrote: Well, I think the stream volume should ‘push’ the reference volume. ie. if stream volume reference volume then reference volume == stream volume. The would be pretty intuitive if you ask me. Doesn't work either since this reintroduces all the problems that made us come up with the concept of the ref volume in the first place: If a stored volume for a stream says 2 dB more than ref volume, then when we apply this we will change the ref volume itself (since we need to 'push' it as you suggest). i.e. before the stream appeared we where at ref volume x, when it appeared we set the ref volume to x+2dB. This doesn’t make sense. If the stream volume slider ‘pushes’ the ref volume slider, then the stream volume can never be 0 dB (relative to the ref volume). For legacy stored stream volumes 0 dB, just round them down to 0 dB. And there is no need to store it after rounding either. The entries in the db are note only controlled by m-s-r but also by the UI tools. But I must admit that right now this suggestion actually makes more sense to me than all other suggestins we have discussed. I need to think about this a bit more. And probably implement it to see in which ways this logic would fail in the end... ;-) There is one issue that I think might come up with the concept of ‘pushing’ the ref vol. What happens to other streams? My gut feeling is that they should compensate so that they stay at the same absolute volume, but that could be tricky to implement, especially considering stored stream volume values. In fact, it is probably not really worth the effort. Probably just compensating active streams would be enough to make it feel intuitive. Of course, the other option is to drag the other streams along for the ride. Which would make pushing the ref vol via a stream vol exactly the same as just moving the ref vol (at least with regards to movements in the upwards direction). That would not be quite as cool, but at least its intuitive and consistent for active stream vols and stored stream vols. pgpTpamECKF0s.pgp Description: PGP signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Per-app flat volume adjustment is highly unintuitive, if mathematically consistent.
'Twas brillig, and Jud Craft at 27/05/09 04:06 did gyre and gimble: Actually, wait. There is one last thing that might clue me in. Let's say I have, relative to each other, Firefox/youTube set to 100% and Banshee set to 80%. Now, imagine I'm listening to Banshee and my volume is 100%. Does flat volume mean that if I start to play a Firefox video...that Firefox will be at 100% and that Pulse will intelligently drop Banshee to 80%? In essence...applying my per-app ratios automatically on the fly, whenever something comes up? I'll be honest, I didn't really think of it like -that-. That sounds awesome enough that I might need to give it another chance. Yes! The way I understand it, and apologies if I'm wrong here, is that Banshess want's 80% and it's the only app playing. In order to achieve that result, pulse does not scale the stream at all but sets the underlying hardware volume to 80% (but in dB's yada yada!). So the net result is I get sound at the right volume. Then another stream joins that wants 100% So, pulse with start scaling the Banshee stream to ensure it is scaled in software to 80%, and turn up the underlying hardware volume to 100%. Net result is that Banshee continues playing at the same level and sounds the same but the new stream can be louder. Essentially, whenever possible pulse is off-loading the scaling to the h/w, meaning less work in software = less load, and better quality audio due to the use of the full range of the DAC. Hope that's right! Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Per-app flat volume adjustment is highly unintuitive, if mathematically consistent.
Colin Guthrie a écrit : Essentially, whenever possible pulse is off-loading the scaling to the h/w, meaning less work in software = less load, and better quality audio due to the use of the full range of the DAC. Slightly off-topic: is there a way to keep the flat-volume behavior but with 100% software volume handling ? Rationale : my intel_hda makes awful crackling sounds with some volume combinations (especially when PCM is at 0%). Thoughts ? Cheers -- Rémi Cardona LRI, INRIA remi.card...@lri.fr r...@gentoo.org ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Per-app flat volume adjustment is highly unintuitive, if mathematically consistent.
On Wed, 27.05.09 11:07, Colin Guthrie (gm...@colin.guthr.ie) wrote: In essence...applying my per-app ratios automatically on the fly, whenever something comes up? I'll be honest, I didn't really think of it like -that-. That sounds awesome enough that I might need to give it another chance. Yes! The way I understand it, and apologies if I'm wrong here, is that Banshess want's 80% and it's the only app playing. In order to achieve that result, pulse does not scale the stream at all but sets the underlying hardware volume to 80% (but in dB's yada yada!). So the net result is I get sound at the right volume. Then another stream joins that wants 100% So, pulse with start scaling the Banshee stream to ensure it is scaled in software to 80%, and turn up the underlying hardware volume to 100%. Net result is that Banshee continues playing at the same level and sounds the same but the new stream can be louder. Essentially, whenever possible pulse is off-loading the scaling to the h/w, meaning less work in software = less load, and better quality audio due to the use of the full range of the DAC. Hope that's right! Yes it is! Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Per-app flat volume adjustment is highly unintuitive, if mathematically consistent.
On Wed, 27.05.09 14:28, Rémi Cardona (r...@gentoo.org) wrote: Colin Guthrie a écrit : Essentially, whenever possible pulse is off-loading the scaling to the h/w, meaning less work in software = less load, and better quality audio due to the use of the full range of the DAC. Slightly off-topic: is there a way to keep the flat-volume behavior but with 100% software volume handling ? Nope. Not right now. Patches welcome ;-) Rationale : my intel_hda makes awful crackling sounds with some volume combinations (especially when PCM is at 0%). Sounds like a driver bug which should fixed at the driver level and not worked around in PA. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Per-app flat volume adjustment is highly unintuitive, if mathematically consistent.
On Wed, 27.05.09 09:13, Jud Craft (craft...@gmail.com) wrote: On Wed, May 27, 2009 at 5:07 AM, Colin Guthrie gm...@colin.guthr.ie wrote: The way I understand it, and apologies if I'm wrong here, is that Banshess want's 80% and it's the only app playing. In order to achieve that result, pulse does not scale the stream at all but sets the underlying hardware volume to 80% (but in dB's yada yada!). So the net result is I get sound at the right volume. Right, but you did not address an important detail of my example. Keep reading... Then another stream joins that wants 100% So, pulse will start scaling the Banshee stream to ensure it is scaled in software to 80%, and turn up the underlying hardware volume to 100%. Net result is that Banshee continues playing at the same level and sounds the same but the new stream can be louder. So far so good. When running Banshee (80%), and, say, Firefox (100%). Main system volume is 100%. I am in agreement with your explanation thus far. Now...for the catch. Mate, pleas just read those mails I wrote yesterday. Close Firefox. Only Banshee runs. System volume has now dropped back to 80% (hardware volume has been changed to 80% too), since that's Banshee's volume. If you close ff (actually flash) PA will remember that it was at 100% of the device volume. Now, increase the system volume to 100%. Banshee is now 100%. Then, turn back on Firefox and play a video. What should happen? Since the Banshee : Firefox ratio was previously 0.8 : 1.0, my theory was that Banshee should be pushed down to 80% and Firefox starts playing at 100% (the system volume) again. However, when I tried it last night, they both stayed at 100%, and I lost the relative volume difference between them. (This was with flat-volumes enabled). Yes, PA restores flash's volume according to what it saved previously: to 100% of the device volume. So when I changed Banshee to 100% when it was running alone, it appears that Pulse forgot that Banshee-Firefox have an 0.8 : 1.0 ratio. (Note, maybe this was a bug, and Pulse should have remembered. I'm not sure, since I can't tell what's intentional and what might be a bug, since I haven't figured out what flat volumes mean in terms of user volume interaction. It didn't make sense to me that Pulse forgot remember the ratio, but maybe that's how it's supposed to be.) PA is not storing stream volumes relative to each other but relative to the sink's refernce volume. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Per-app flat volume adjustment is highly unintuitive, if mathematically consistent.
On Wed, May 27, 2009 at 10:23 AM, Lennart Poettering lenn...@poettering.net wrote: Mate, please just read those mails I wrote yesterday. I'm working on it, I think I'm getting better. Note the end of this email... PA is not storing stream volumes relative to each other but relative to the sink's reference volume. I guess that's just a unfortunate side-effect of the logic. Since only active volumes are rescaled against the reference, it means that closing an App X and then changing the reference volume with the rest of the active Apps will make that App X lose its relative position to the other Apps when it is relaunched. That's the only thing I don't like. I do like the flat logic's intention (use hardware scaling over software scaling when possible) though. It sounds like a smart way to overcome that problem. I believe you mentioned in your earlier email to me that setting the _stream_, not the sink [which I assume means output] leaves the reference volume alone. I think this makes sense, so I will give flat volumes another shot when I get home today. So with this explanation, I can understand why Banshee always changes the volume predictably in flat-volume mode. I believe, with the sink set to 100%, I must have set Banshee to something like 92% (while some other app was playing 100% relative to the sink volume). Thus the sink was 100%, and Banshee was 92%. And then I changed the sink volume (thus the reference volume) to near 90%. I closed the other app. This made the sink match Banshee's volume (which by that time was 0.92*0.9 = 83%). So, with my reference volume set to 90% and Banshee set to 92% of that, this means that when playing, Banshee will have a stream factor of 83%, and the sink meter matches this while I play. Whenever I cease playing, the sink will resume displaying the reference volume of 90%. Do I have it correct? And I will add, that this behavior (the sink's visible volume constantly jumping around, even if the reference stays at 90% internally) is what I find a little confusing. However, if, as you say, the Sound Events were treated as any other application in Gnome-Volume-Control (and thus the sink volume matched them when that stream was set to 100%), this would provide nearly identical behavior to Vista, as far as I can tell, since I often adjust all of my apps relative to the Events volume in Vista (which I believe is how I must have achieved what I do in Windows). ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Per-app flat volume adjustment is highly unintuitive, if mathematically consistent.
On Wed, 27.05.09 13:28, Jud Craft (craft...@gmail.com) wrote: On Wed, May 27, 2009 at 10:23 AM, Lennart Poettering lenn...@poettering.net wrote: Mate, please just read those mails I wrote yesterday. I'm working on it, I think I'm getting better. Note the end of this email... PA is not storing stream volumes relative to each other but relative to the sink's reference volume. I guess that's just a unfortunate side-effect of the logic. Since only active volumes are rescaled against the reference, it means that closing an App X and then changing the reference volume with the rest of the active Apps will make that App X lose its relative position to the other Apps when it is relaunched. That's the only thing I don't like. Side-effect of the logic? The fact that all volumes are saved/restored relatively to the reference volume is the very core of the logic. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Per-app flat volume adjustment is highly unintuitive, if mathematically consistent.
On Wed, May 27, 2009 at 2:27 PM, Lennart Poettering lenn...@poettering.net wrote: Side-effect of the logic? The fact that all volumes are saved/restored relatively to the reference volume is the very core of the logic. No, no, I didn't mean to say the side effect wasn't that the volumes were saved/restored, because they obviously need to be...that wasn't what I meant. It was a poorly worded statement. What I meant, was that...To the user, when running one program, the sink and the stream seem to be the same volume meter. However, internally, they change two different values (the reference volume, and the stream volume/factor, respectively). Since they appear to be the same meter, a user who changes a stream volume (and watches his output sink change as well) will be a little puzzled as to why, when the program is closed, his sink (or output device) magically decides to jump back to its old volume value (ie, from the stream value back to the reference value). As far as s/he can see, they didn't tell the volume to jump back to the old value (and if they've lost track of the reference value because they've been running one program for so long, they definitely won't make that connection). It appears to them that whenever they stop playing a program or open other programs, their main volume meter jumps to a random value. But, does it seem that I have an understanding of how Pulse manages the reference volume and the streams relative to it? ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Per-app flat volume adjustment is highly unintuitive, if mathematically consistent.
On Thu, 28.05.09 00:11, CJ van den Berg (c...@vdbonline.com) wrote: On Wed, May 27, 2009 at 12:47:28AM +0200, Lennart Poettering wrote: Volume control UIs show the sink's virtual volume in the sink slider. You can change the reference volume by changing the sink slider position. In which case the volume of all sink inputs is adjusted in a way that the virtual volume will match the reference volume. You can change the virtual volume also by changing the stream slider positions, which then doesn't have any effect on the reference volume. And this is the core of the entire problem IMHO. The sink volume slider *displays* one value (the virtual volume level) and *adjusts* another (the reference volume level). This really, really counter-intuitive and a major cause for confusion. A UI element should never ever carry two different meanings. This is not entirely true. It displays one value, but adjusts *two* values, including the one that it displays. i.e. after you fiddled with the slider reference and virtual volume will *both* be set to what you set with the slider But yes, you are right, I am tempted to agree that this asymmetry is problematic. Now, I must admit that this all is a bit hard to grasp. And thus not exactly the definition of easy to use. We had a couple of discussions on this very ML about this. So far noone came up with a way to fix this in a way that would be completely convincing. I still think that my suggestion to drop the virtual volume altogether in the UI and have the sink volume slider display the reference volume is the right solution. I am not convinced. Think about this scenario: you have one stream playing. Reference sink volume, virtual sink volume and stream volume are at -inf dB. Now you move stream volume to 0 dB. This would not change the reference volume level, but would set the virtual volume to 0 dB. According to your suggestion the UI would stick to the ref volume, and hence you get *full* output with the UI showing volume at -inf dB. I am pretty sure that people would be confused about that even more than they are with the current logic. So yepp. We now found that a) presenting only virtual volume in the UI sucks b) presenting only ref volme in the UI sucks, too. So, what about integrating both values in some way? Maybe present max(virtual, ref), as has been suggested by Marc-Andre? Given that most of the time virtual volume ref volume, this would be very similar to a). Similar for min(virtual, ref), which would be like b). Show avg(virtual, ref)? Welcome to land of complete confusion! Present both volumes? Forget it! Other options might be to handle the cases I) no streams playing II) one stream playing and III) = 2 streams playing differently. In fact that is a bit what happens already, since we actually expose in the UI the ref vol in case I) and the virtual vol in case II). Beyond that we could for example make the reference volume be controllable by the stream volume, but only in case II) or so. Dunno This is one messy affair... At very least I think it will reduce the confusion level dramatically and you won’t have to explain the flat volume logic over and over again. Au contraire! Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Per-app flat volume adjustment is highly unintuitive, if mathematically consistent.
On Thu, May 28, 2009 at 12:31:29AM +0200, Lennart Poettering wrote: I still think that my suggestion to drop the virtual volume altogether in the UI and have the sink volume slider display the reference volume is the right solution. I am not convinced. Think about this scenario: you have one stream playing. Reference sink volume, virtual sink volume and stream volume are at -inf dB. Now you move stream volume to 0 dB. This would not change the reference volume level, but would set the virtual volume to 0 dB. According to your suggestion the UI would stick to the ref volume, and hence you get *full* output with the UI showing volume at -inf dB. I am pretty sure that people would be confused about that even more than they are with the current logic. Well, I think the stream volume should ‘push’ the reference volume. ie. if stream volume reference volume then reference volume == stream volume. The would be pretty intuitive if you ask me. That of course also eliminates the possibility of getting into an overdrive situation, but IMHO that’s a feature, not a bug. :-) So yepp. We now found that a) presenting only virtual volume in the UI sucks b) presenting only ref volme in the UI sucks, too. So, what about integrating both values in some way? [...] Hmm, deja vu. Didn’t we have this exact same discussion once before? pgp8xzNbtPhg9.pgp Description: PGP signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Per-app flat volume adjustment is highly unintuitive , if mathematically consistent.
On Wednesday 27 May 2009 23:31:29 Lennart Poettering wrote: On Thu, 28.05.09 00:11, CJ van den Berg (c...@vdbonline.com) wrote: On Wed, May 27, 2009 at 12:47:28AM +0200, Lennart Poettering wrote: Volume control UIs show the sink's virtual volume in the sink slider. You can change the reference volume by changing the sink slider position. In which case the volume of all sink inputs is adjusted in a way that the virtual volume will match the reference volume. You can change the virtual volume also by changing the stream slider positions, which then doesn't have any effect on the reference volume. And this is the core of the entire problem IMHO. The sink volume slider *displays* one value (the virtual volume level) and *adjusts* another (the reference volume level). This really, really counter-intuitive and a major cause for confusion. A UI element should never ever carry two different meanings. This is not entirely true. It displays one value, but adjusts *two* values, including the one that it displays. i.e. after you fiddled with the slider reference and virtual volume will *both* be set to what you set with the slider But yes, you are right, I am tempted to agree that this asymmetry is problematic. Now, I must admit that this all is a bit hard to grasp. And thus not exactly the definition of easy to use. We had a couple of discussions on this very ML about this. So far noone came up with a way to fix this in a way that would be completely convincing. I still think that my suggestion to drop the virtual volume altogether in the UI and have the sink volume slider display the reference volume is the right solution. I am not convinced. Think about this scenario: you have one stream playing. Reference sink volume, virtual sink volume and stream volume are at -inf dB. Now you move stream volume to 0 dB. This would not change the reference volume level, but would set the virtual volume to 0 dB. According to your suggestion the UI would stick to the ref volume, and hence you get *full* output with the UI showing volume at -inf dB. I am pretty sure that people would be confused about that even more than they are with the current logic. So yepp. We now found that a) presenting only virtual volume in the UI sucks b) presenting only ref volme in the UI sucks, too. So, what about integrating both values in some way? Maybe present max(virtual, ref), as has been suggested by Marc-Andre? Given that most of the time virtual volume ref volume, this would be very similar to a). Similar for min(virtual, ref), which would be like b). Show avg(virtual, ref)? Welcome to land of complete confusion! Present both volumes? Forget it! Other options might be to handle the cases I) no streams playing II) one stream playing and III) = 2 streams playing differently. In fact that is a bit what happens already, since we actually expose in the UI the ref vol in case I) and the virtual vol in case II). Beyond that we could for example make the reference volume be controllable by the stream volume, but only in case II) or so. Dunno This is one messy affair... At very least I think it will reduce the confusion level dramatically and you won’t have to explain the flat volume logic over and over again. Au contraire! Lennart )) I'm not sure I have completely followed and/or understood the complete argument here but, UIs are kind of my area of expertise. Ignore me if I'm rambling or ranting but, it's my experience (15 years worth) that developers tend to view things from a neatness of code point of view, whereas users tend to view things from an intelligibility of the UI point of view. What is satisfying to the developer is often not what the user wants or understands... realising what the user needs often results in horrid and messy code but happy and productive users. What conclusions have I drawn from this? (a) Existing coding models are crap. (b) you can't please end-users with beautiful algorithms, (c) UI design should be independent of the underlying code and really ought not to directly reference any of the features of the driver model. My manager would shoot me at this point.. the people who use my software are not complaining however. (c) Is really the point I think is relevant to this discussion. If the UI of pavucontrol is making end users confused then either (a) redesign the interface so the bits that confuse them are masked by brilliant and inventive mappings or (b) redesign the backend such that the existing UI makes sense. In my experience, (a) pleases most of the people most of the time. In other words. it's not the logic that is the issue, it's the way that logic is displayed to the user. As I'm fond of saying - find out what your users want to do, then map what your application actually does onto those desires, then design a UI that controls the mapping - leaving the
Re: [pulseaudio-discuss] Per-app flat volume adjustment is highly unintuitive, if mathematically consistent.
On Thu, 28.05.09 00:53, CJ van den Berg (c...@vdbonline.com) wrote: I am not convinced. Think about this scenario: you have one stream playing. Reference sink volume, virtual sink volume and stream volume are at -inf dB. Now you move stream volume to 0 dB. This would not change the reference volume level, but would set the virtual volume to 0 dB. According to your suggestion the UI would stick to the ref volume, and hence you get *full* output with the UI showing volume at -inf dB. I am pretty sure that people would be confused about that even more than they are with the current logic. Well, I think the stream volume should ‘push’ the reference volume. ie. if stream volume reference volume then reference volume == stream volume. The would be pretty intuitive if you ask me. Doesn't work either since this reintroduces all the problems that made us come up with the concept of the ref volume in the first place: If a stored volume for a stream says 2 dB more than ref volume, then when we apply this we will change the ref volume itself (since we need to 'push' it as you suggest). i.e. before the stream appeared we where at ref volume x, when it appeared we set the ref volume to x+2dB. Then when the stream goes away and comes back we'll need to adjust it to x+4dB and so on which would eventually end up in +inf dB amplification. Of course, now you probably say that the stored volume needs to be updated after we restored it, i.e. it would then be 0dB on disk. However, after we did that, teh stream would from then on be played at the same level as everything that was stored on disk to be played at 0dB, i.e. the 2dB difference goes away. Now, your next idea is probably to update all other stored entries accordingly to even that out, i.e. when we update the stored entry for our stream we need to subtract the same dB from *all* db entries --- but if you do that you end up with something that is 100% equivalent to the current reference volume logic, with the exception that updating a single ref volume level is cheap, while updating all entries in the db is expensive. We are running in circles. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Per-app flat volume adjustment is highly unintuitive, if mathematically consistent.
On Thu, May 28, 2009 at 01:33:48AM +0200, Lennart Poettering wrote: On Thu, 28.05.09 00:53, CJ van den Berg (c...@vdbonline.com) wrote: I am not convinced. Think about this scenario: you have one stream playing. Reference sink volume, virtual sink volume and stream volume are at -inf dB. Now you move stream volume to 0 dB. This would not change the reference volume level, but would set the virtual volume to 0 dB. According to your suggestion the UI would stick to the ref volume, and hence you get *full* output with the UI showing volume at -inf dB. I am pretty sure that people would be confused about that even more than they are with the current logic. Well, I think the stream volume should ‘push’ the reference volume. ie. if stream volume reference volume then reference volume == stream volume. The would be pretty intuitive if you ask me. Doesn't work either since this reintroduces all the problems that made us come up with the concept of the ref volume in the first place: If a stored volume for a stream says 2 dB more than ref volume, then when we apply this we will change the ref volume itself (since we need to 'push' it as you suggest). i.e. before the stream appeared we where at ref volume x, when it appeared we set the ref volume to x+2dB. This doesn’t make sense. If the stream volume slider ‘pushes’ the ref volume slider, then the stream volume can never be 0 dB (relative to the ref volume). For legacy stored stream volumes 0 dB, just round them down to 0 dB. And there is no need to store it after rounding either. CJ pgpwclIPdo4tO.pgp Description: PGP signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Per-app flat volume adjustment is highly unintuitive, if mathematically consistent.
On Thu, 28.05.09 01:47, CJ van den Berg (c...@vdbonline.com) wrote: On Thu, May 28, 2009 at 01:33:48AM +0200, Lennart Poettering wrote: On Thu, 28.05.09 00:53, CJ van den Berg (c...@vdbonline.com) wrote: I am not convinced. Think about this scenario: you have one stream playing. Reference sink volume, virtual sink volume and stream volume are at -inf dB. Now you move stream volume to 0 dB. This would not change the reference volume level, but would set the virtual volume to 0 dB. According to your suggestion the UI would stick to the ref volume, and hence you get *full* output with the UI showing volume at -inf dB. I am pretty sure that people would be confused about that even more than they are with the current logic. Well, I think the stream volume should ‘push’ the reference volume. ie. if stream volume reference volume then reference volume == stream volume. The would be pretty intuitive if you ask me. Doesn't work either since this reintroduces all the problems that made us come up with the concept of the ref volume in the first place: If a stored volume for a stream says 2 dB more than ref volume, then when we apply this we will change the ref volume itself (since we need to 'push' it as you suggest). i.e. before the stream appeared we where at ref volume x, when it appeared we set the ref volume to x+2dB. This doesn’t make sense. If the stream volume slider ‘pushes’ the ref volume slider, then the stream volume can never be 0 dB (relative to the ref volume). For legacy stored stream volumes 0 dB, just round them down to 0 dB. And there is no need to store it after rounding either. The entries in the db are note only controlled by m-s-r but also by the UI tools. But I must admit that right now this suggestion actually makes more sense to me than all other suggestins we have discussed. I need to think about this a bit more. And probably implement it to see in which ways this logic would fail in the end... ;-) Marc-Andre, are you reading this? Got an opinion? Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Per-app flat volume adjustment is highly unintuitive, if mathematically consistent.
On Mon, 25.05.09 12:51, Jud Craft (craft...@gmail.com) wrote: I understand how audacious it would be to post and tell you that Pulseaudio is doing the volume scaling wrong, but let me demonstrate a problem. I won't post twice -- I know you guys are busy on this list -- but I've really wanted to mention this. I've seen Redhat Bugzilla #494112, but it seems to glance over the problem. I know that Pulse can remember the volume of an app. And when Pulse also scales the main-system volume (with only one program, App A, present), it remember that app's volume, say 75%, and sets the main system volume to it. All is good. Set App A to 75%, and Pulse sets the system volume to 75%. But what happens when you run another program (App B), that has a per-app volume of 80%? It appears that Pulse remembers the volume of App B too. In this case, it appears that Pulse rescales both apps, so that the main system volume matches App B (80%), and App A is set so that it has a relative volume to App B. (ie, if App A has only 75% of the main system volume, and 80% is the main volume, so App A now has .80 x .75 = 60% volume). Uh? No, that's wrong. First of all, using percentages for this is misleading. The percentage scale is artificial and has only an indirect connection to what happens internally. It is explicitly *not* a factor that is used for actual volume adjustments. If you have one stream A at linear volume factor X and one B at linear volume factor Y with X Y, then the device will be configured to Y and internally the data from B will be passed through untouched and the one from A will be attenuated with the factor (X/Y). That is completely different from what you wrote above. This maintains the correct per-app ratio (App B is louder than App A), but it changes the main system volume. In addition, if a program that has no per-app volume yet (with a default of 100%) is launched, then Pulse resets system volume to 100% and scales _both_ apps to match this one. That is not correct. PA will set streams it doesn't know to 100% of the 'reference volume'. The reference volume is the one you configure on the sink with the UI. i.e. if you change the sink volume to 75% then a new previously unknown stream will be configured to 75%. However if you set the sink volume only indirectly to 75% (i.e. by controlling setting a stream volume to 75% with it being the highest volume) then the referece volume won't be changed and hence new streams will be set to hatever was the reference volume before. My apps are scaling fine, but here's the problem: main system volume is meaningless. I have no control over it, since Pulse will set it to whatever it wants. There's no point in even changing it -- I should just merely set the per-app volumes and let Pulse figure out what to do. That's not true. Just set the sink volume to whatever you want. All stream volumes are relative to that. I don't have my laptop plugged into a stereo system with a big volume knob that I can turn. When I set the main volume to 80%, I want it to stay that way. I don't want something like playing a YouTube video or playing a new CD to change the volume back to 100% or whatever it wants. It seems you first set the sink volume to 80%, then set the stream volume of youtube to 100%. This will then be remembered as set youtube to 125% of the sink volume. In essence, the user should be able to set the volume of any program he likes, and expect that the system will respect that. One solution. 1. When a new never-seen-before app is launched, Pulse defaults not to 100% but to the current system volume. Which is what happens. We call that reference volume however. 2. Pulse should never change the main system volume on its own. That's mine. PA won't touch the reference volume. What it will do is touch the virtual volume. 3. If I change the loudest App, then Pulse may change the main system volume to match. But only because I did it; whenever an App starts on its own, Pulse matches it relative to the main system volume. That's exactly what happens, with the exception that we apply it relative to the 'refernce volume', not the 'virtual volume'. This, in fact, is the way Windows Vista behaves. Pulse currently doesn't behave like Windows Vista: nothing ever changes your main volume on Windows except you, or unless *you* change the highest volume app. WHich is exactly what happens in PA. With the exception that we save/restore the relative volume of each stream- It's also worth noting that System Sound Events are shown as an App in the Windows Vista list (unlike Pulse, where they are separate) -- Uh? pavucontrol shows system events as a slider on the Playback tab where all the other pp streams are shown too. If you are speaking of g-v-c, please file a bug against gnome-media. I think the big confusion stems from the fact that PA distuingishes reference and virtual sink volumes, but this
Re: [pulseaudio-discuss] Per-app flat volume adjustment is highly unintuitive, if mathematically consistent.
Long post coming, I apologize ahead of time. I really do appreciate you taking the time to explain it, even if I am a little frustrated (and you may be as well if I drag this thread on for much longer). First, I'm not sure what you mean by reference volume and virtual volume. My Internal Audio card has one volume, the Output Volume in g-v-c. Let me be clear about the puzzle I am facing, and you can tell me if I misunderstand. This example has two applications, one of which does not have a pre-set volume in Pulse. (For the both-apps-have-a-volume case, see below). Let's say I have _one_ application running, App A. The volume of the app is 80%, and thus my Output Volume on the main sink is 80%. If I launch a new App B that has never been seen before, Pulse will set B to the current volume (80%). What happens to App A is where we differ. I assumed that since I want A to be only 80% as loud as anything else, that since B is set to 80%, A must become quieter, to be only as 80% loud as B. Thus A will be scaled down to 56%, or whatever. You say, however, that App A is not 80% as loud as everything else, but that when I change only one running app, PulseAudio assumes I am only changing the Output Volume, but not the relative volume of App A. Thus, Output Volume is 80%, but A is 100% of that, and B will be too, so they will both be at 80%. Is that correct? Now, I find that hard to grasp. When I want my music to be quieter and I see a music stream slider, and I turn that down, that's what I want to turn down. Nothing else. Turning down the music does not mean I want _everything_ else on my machine that I will launch for the *first time* hereafter to be quieter too. (I'm not saying you've hit a usability problem yet, I'm just saying my expectation). On Tue, May 26, 2009 at 5:47 PM, Lennart Poettering lenn...@poettering.net wrote: If you have one stream A at linear volume factor X and one B at linear volume factor Y with X Y, then the device will be configured to Y and internally the data from B will be passed through untouched and the one from A will be attenuated with the factor (X/Y). That is completely different from what you wrote above. That sounds weird. If X is 0.75 (and thus my main system volume is 75%), and I launch Y (which has a previous volume of 0.8), then the main system volume will be set to 0.8 (to the loudest app), Y will be 0.8 (untouched), and X will be, to your formula, (0.75/0.8 = 0.9375?). What? That can't be right (0.93 and 0.8), so you must have meant 0.93 and 1.0. But, everything jumped from 0.75 : 0.8 to 0.93 : 1.0. I want the sound to be 75% as loud as everything else, but it's only 75% as loud relative to App B. Why is it now 93% as loud as everything else? That _only_ makes sense if you assume that secretly, the real volume of my machine is 100%, but you've hidden everything from me. That may in fact be what you mean by virtual volume, but I must admit that it's quite bewildering. Calculating App A relative to (whatever app I have running at the time) rather than some constant (the current fixed volume, if such a thing still exists) is a little bizarre to me. Now, I must admit that this all is a bit hard to grasp. And thus not exactly the definition of easy to use. We had a couple of discussions on this very ML about this. So far noone came up with a way to fix this in a way that would be completely convincing. I think the core problem is that it is impossible to figure out what the user actually wants. When he increases a volume of a stream he might A) want it a bit louder then whatever else is currently playing and would be pissed off if the other stream would get louder at the same time or B) want it a bit louder because everything that's playing is just too silent and he would be pissed off if only one stream would get louder and not all. I think you might be thinking too hard. When I increase the volume of my system, I expect everything to get louder. When I increase the slider of a program, I merely expect that one program to get louder. I don't expect everything else to get louder too, and I don't expect everything else to get quieter. Nothing else should chang except that one program. Why would I expect anything else? That makes no sense. If I wanted those Apps to be quieter, I would bring their sliders down. Windows Vista doesn't do this, really. When I increase the volume of one App, it doesn't touch any of my other Apps (unlike Pulse) -- it doesn't even bring them up, even if increasing one App changes the system volume. The only time Vista touches all Apps is when I adjust the main output device volume - the only time it should, since changing the main volume should change everything (like Pulse). And in Vista, changing one app doesn't change the main system volume -- and more importantly, I can SEE that it doesn't. The main volume isn't suddenly some nebulous value that means the current volume value of the
Re: [pulseaudio-discuss] Per-app flat volume adjustment is highly unintuitive, if mathematically consistent.
Lennart wrote: Now, I must admit that this all is a bit hard to grasp. And thus not exactly the definition of easy to use. We had a couple of discussions on this very ML about this. So far noone came up with a way to fix this in a way that would be completely convincing. I can't claim to grasp it, but... I think the core problem is that it is impossible to figure out what the user actually wants. When he increases a volume of a stream he might A) want it a bit louder then whatever else is currently playing and would be pissed off if the other stream would get louder at the same time or B) want it a bit louder because everything that's playing is just too silent and he would be pissed off if only one stream would get louder and not all. It seems to me that these problems would go away if you accept that boost/compression should not be a function of volume. (Use a seperate module!) If PA can't satisfy audiophiles, then PA will not earn a great reputation with the layman who trusts experts either. Every sensible volume control I can think of is conceptually an attenuator, i.e. zero decibels at maximum (even if it is implemented as amplifier gain control internally). That's why a slider is appropriate as a GUI element here. (VLC player notwithstanding. I carefully leave it at 100% and never touch it. The 400% upper bound is both non-intuitive, arbitrary and likely to distort.) So, if as you claim, the user might A) want it a bit louder then whatever else is currently playing and would be pissed off if the other stream would get louder at the same time, I think that user has probably never used a volume control or mixer (i.e. an attenuator). It doesn't make sense (in my mind) to optimise for this unusual situation. Finn ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Per-app flat volume adjustment is highly unintuitive, if mathematically consistent.
On Tue, 26.05.09 19:47, Jud Craft (craft...@gmail.com) wrote: Long post coming, I apologize ahead of time. I really do appreciate you taking the time to explain it, even if I am a little frustrated (and you may be as well if I drag this thread on for much longer). First, I'm not sure what you mean by reference volume and virtual volume. My Internal Audio card has one volume, the Output Volume in g-v-c. Let me be clear about the puzzle I am facing, and you can tell me if I misunderstand. Please read my mail again. I explained the difference between reference and virtual volume there. I also explained that only the latter is really visible in the UI. Or at least I tried to explain that. This example has two applications, one of which does not have a pre-set volume in Pulse. (For the both-apps-have-a-volume case, see below). Let's say I have _one_ application running, App A. The volume of the app is 80%, and thus my Output Volume on the main sink is 80%. If I launch a new App B that has never been seen before, Pulse will set B to the current volume (80%). Not necessarily. Please read again what I wrote about ref vs. virt volumes. And again, please stop talking about those percentages, they are misleading. On Tue, May 26, 2009 at 5:47 PM, Lennart Poettering lenn...@poettering.net wrote: If you have one stream A at linear volume factor X and one B at linear volume factor Y with X Y, then the device will be configured to Y and internally the data from B will be passed through untouched and the one from A will be attenuated with the factor (X/Y). That is completely different from what you wrote above. That sounds weird. If X is 0.75 (and thus my main system volume is 75%), and I launch Y (which has a previous volume of 0.8), then the main system volume will be set to 0.8 (to the loudest app), Y will be 0.8 (untouched), and X will be, to your formula, (0.75/0.8 = 0.9375?). What? That can't be right (0.93 and 0.8), so you must have meant 0.93 and 1.0. Again, please don't mention the percentages. If at all speak about the linear factors. So, reading these as linear factors. If X is 0.75 and Y is 0.8, then, yes, the virtual sink volume and hence the hw volume control is configured to 0.8, which is then shown in the UI on the volume slider of the sink. As I said the internally applied volume for stream B will then be 1.0, let's call that Y'. The internally applied volume X' for stream A will be X/Y: The final output volume of B will be Y' * Y = 1.0 * Y = Y = .8 The final output volume of A will be X' * X = (X/Y) * Y = X = .75 Which is exactly what was requested. if this is not clear to you, please read my last mail again. I think the core problem is that it is impossible to figure out what the user actually wants. When he increases a volume of a stream he might A) want it a bit louder then whatever else is currently playing and would be pissed off if the other stream would get louder at the same time or B) want it a bit louder because everything that's playing is just too silent and he would be pissed off if only one stream would get louder and not all. I think you might be thinking too hard. When I increase the volume of my system, I expect everything to get louder. When I increase the slider of a program, I merely expect that one program to get louder. I don't expect everything else to get louder too, and I don't expect everything else to get quieter. Nothing else should chang except that one program. Sure, but RB only shows one volume slider. Which one should it show? The stream volume? If so users of use case B would be pissed off. The sink volume? Then the users of use case A would be pissed off. And don't suggest that we should show both sliders in rb! Windows Vista doesn't do this, really. When I increase the volume of one App, it doesn't touch any of my other Apps (unlike Pulse) -- it Uh? That's bogus. Are you claiming that if you change a stream volume of A this might have the effect of changing the volume of a stream B? That's simply not true. doesn't even bring them up, even if increasing one App changes the system volume. The only time Vista touches all Apps is when I adjust the main output device volume - the only time it should, since changing the main volume should change everything (like Pulse). Vista is broken in this way too. Some apps expose the device volume, others expose the stream volume. And in Vista, changing one app doesn't change the main system volume -- and more importantly, I can SEE that it doesn't. The main volume isn't suddenly some nebulous value that means the current volume value of the loudest app. Which is exactly what PA does. Really, please try to understand what I wrote in my last mail. PA's flat volume work very much like Vista, with the exception that we save/restore volumes. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at]
Re: [pulseaudio-discuss] Per-app flat volume adjustment is highly unintuitive, if mathematically consistent.
On Wed, 27.05.09 11:10, Finn Thain (fth...@telegraphics.com.au) wrote: Lennart wrote: Now, I must admit that this all is a bit hard to grasp. And thus not exactly the definition of easy to use. We had a couple of discussions on this very ML about this. So far noone came up with a way to fix this in a way that would be completely convincing. I can't claim to grasp it, but... I think the core problem is that it is impossible to figure out what the user actually wants. When he increases a volume of a stream he might A) want it a bit louder then whatever else is currently playing and would be pissed off if the other stream would get louder at the same time or B) want it a bit louder because everything that's playing is just too silent and he would be pissed off if only one stream would get louder and not all. It seems to me that these problems would go away if you accept that boost/compression should not be a function of volume. (Use a seperate module!) If PA can't satisfy audiophiles, then PA will not earn a great reputation with the layman who trusts experts either. Every sensible volume control I can think of is conceptually an attenuator, i.e. zero decibels at maximum (even if it is implemented as amplifier gain control internally). That's why a slider is appropriate as a GUI element here. (VLC player notwithstanding. I carefully leave it at 100% and never touch it. The 400% upper bound is both non-intuitive, arbitrary and likely to distort.) So, if as you claim, the user might A) want it a bit louder then whatever else is currently playing and would be pissed off if the other stream would get louder at the same time, I think that user has probably never used a volume control or mixer (i.e. an attenuator). It doesn't make sense (in my mind) to optimise for this unusual situation. You are misunderstanding the flat volume logic. In flat vol the hardware volume is always configured to the *maxmimum* of all stream volumes. And if the streams have different volumes then some of them will be attenuated digitally, *nothing* will be amplified digitally. So, if someone wants playback of exactly one stream a bit louder, then this will have the effect that the output device volume will be increased and digital attenuation happens for all other streams. Which seems to be exactly hat you are asking for, which in turn makes me wonder what your mail is actually about? Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Per-app flat volume adjustment is highly unintuitive, if mathematically consistent.
On Wed, 27 May 2009, Lennart Poettering wrote: You are misunderstanding the flat volume logic. Probably. But since attenuator knobs don't tweak each other (rather I am in control), I think you can read what I wrote as arguing against flat volume logic, on the grounds of intuitive behaviour. Finn In flat vol the hardware volume is always configured to the *maxmimum* of all stream volumes. And if the streams have different volumes then some of them will be attenuated digitally, *nothing* will be amplified digitally. So, if someone wants playback of exactly one stream a bit louder, then this will have the effect that the output device volume will be increased and digital attenuation happens for all other streams. Which seems to be exactly hat you are asking for, which in turn makes me wonder what your mail is actually about? Lennart ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Per-app flat volume adjustment is highly unintuitive, if mathematically consistent.
On Wed, 27.05.09 12:02, Finn Thain (fth...@telegraphics.com.au) wrote: On Wed, 27 May 2009, Lennart Poettering wrote: You are misunderstanding the flat volume logic. Probably. But since attenuator knobs don't tweak each other (rather I am in control), I think you can read what I wrote as arguing against flat volume logic, on the grounds of intuitive behaviour. Sorry, I don't buy this. PA is not KDE. We try to handle things automatically if we can and only expose a minimal set of controls. I am trying my best to merge as many sliders in our pipeline into one as possible. Sure it takes away control. But that's the purpose of the whole think. Yes, the logic is not tweaked that well right now. But hey, my job is to improve things, and that's what I will be doing. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Per-app flat volume adjustment is highly unintuitive, if mathematically consistent.
On Tue, 26.05.09 21:25, Jud Craft (craft...@gmail.com) wrote: So, reading these as linear factors. If X is 0.75 and Y is 0.8, then, yes, the virtual sink volume and hence the hw volume control is configured to 0.8, which is then shown in the UI on the volume slider of the sink. As I said the internally applied volume for stream B will then be 1.0, let's call that Y'. The internally applied volume X' for stream A will be X/Y: The final output volume of B will be Y' * Y = 1.0 * Y = Y = .8 The final output volume of A will be X' * X = (X/Y) * Y = X = .75 Which is exactly what was requested. if this is not clear to you, please read my last mail again. That does make sense. But you missed a part of my example -- I don't want my system playing at full volume. I want it playing at 80% (whatever that means -- let Pulse and Vista figure that out), and I want A playing at 75% of that, and B playing at 80% of that. He, then you don't want the flat vol logic. But really, *why* do you want this? Why do you want your highest stream volume considerably lower than the device volume? That 20% headroom is simply something you lose then. Your sound card has a 16 bit DAC. But that way you use it as 15 bit dac only. Serious. There was only one way to scale volume values to me. I assumed that even in non-flat volume mode, Pulse behaved the same way as Vista. I just figured that Vista had the stupidity to scale all of my volume meters relative to the master volume meter, just to make me think extra hard. You know, this sounds more like a problem of didn't use to be like this, must be bad than serious cricism. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Per-app flat volume adjustment is highly unintuitive, if mathematically consistent.
No, genuinely. I really assumed that flat-volume was a different way of presenting the relative volumes, rather than a truly different method of managing stream volume. Truthfully, I insist upon my point about Vista. They may do the same things on the inside, but in Vista, the only thing that *appears* to touch the master volume is my volume knob. I like the metaphor of master volume, and scaling everything relative to that, so I guess flat volume isn't for me. On Tue, May 26, 2009 at 9:32 PM, Lennart Poettering lenn...@poettering.net wrote: Heh, then you don't want the flat vol logic. But really, *why* do you want this? Why do you want your highest stream volume considerably lower than the device volume? That 20% headroom is simply something you lose then. Your sound card has a 16 bit DAC. But that way you use it as 15 bit dac only. But it's not my highest stream. I don't want music to be the loudest thing that I play. I have other things that need to be louder. It is a shame not having the headroom accessible to my music, but the truth is, I like to set everything as I know it will be (my music should be this high, Skype and AIM and system events should be a little higher than that so I hear everything, Firefox should be lower than all of them because YouTube wears out my ears), and trust that they'll stay that way, even as I continue to adjust the master volume to make them all a little louder or quieter as I need at a particular time. Vista does this, and Pulse does it fine in non-flat volume mode. I really do find it curious that you say Vista and Pulse operate the same, because truthfully, even if Vista uses flat-volume style meter control, the actual behavior of the volumes is not quite the same as flat-volume-Pulse. It's truly a little different. Someday I may very much enjoy Pulse's flat volume mode, but I think it will require a paradigm shift. It may just be that I've managed to use Vista's flat volumes in a certain way that fits my this should be that loud, that should be that loud mentality, and Pulse is either more- or less-correct in its application of flat volume logic in a way I didn't expect. I -did- assume flat- and non-flat were basically the same. Both let me scale my app volumes relative to each other. But with flat volume, the meters jump all over the place just when I want to make things a little quieter or louder, and adjusting one program bothers everything else. It just doesn't make sense to me yet. So I guess this is where I end. Thanks for listening, and I appreciate your time. I'll give the virtual volumes thing a read after a little more supper and see if it makes more sense. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Per-app flat volume adjustment is highly unintuitive, if mathematically consistent.
Actually, wait. There is one last thing that might clue me in. Let's say I have, relative to each other, Firefox/youTube set to 100% and Banshee set to 80%. Now, imagine I'm listening to Banshee and my volume is 100%. Does flat volume mean that if I start to play a Firefox video...that Firefox will be at 100% and that Pulse will intelligently drop Banshee to 80%? In essence...applying my per-app ratios automatically on the fly, whenever something comes up? I'll be honest, I didn't really think of it like -that-. That sounds awesome enough that I might need to give it another chance. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
