Re: [pulseaudio-discuss] Per-app flat volume adjustment is highly unintuitive, if mathematically consistent.

2009-05-30 Thread Zygo Blaxell
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.

2009-05-28 Thread CJ van den Berg
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.

2009-05-27 Thread Colin Guthrie

'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.

2009-05-27 Thread Rémi Cardona

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.

2009-05-27 Thread Lennart Poettering
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.

2009-05-27 Thread Lennart Poettering
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.

2009-05-27 Thread Lennart Poettering
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.

2009-05-27 Thread Jud Craft
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.

2009-05-27 Thread Lennart Poettering
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.

2009-05-27 Thread Jud Craft
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.

2009-05-27 Thread Lennart Poettering
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.

2009-05-27 Thread CJ van den Berg
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.

2009-05-27 Thread Mark Greenwood
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.

2009-05-27 Thread Lennart Poettering
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.

2009-05-27 Thread CJ van den Berg
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.

2009-05-27 Thread Lennart Poettering
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.

2009-05-26 Thread Lennart Poettering
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.

2009-05-26 Thread Jud Craft
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.

2009-05-26 Thread Finn Thain

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.

2009-05-26 Thread Lennart Poettering
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.

2009-05-26 Thread Lennart Poettering
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.

2009-05-26 Thread Finn Thain


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.

2009-05-26 Thread Lennart Poettering
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.

2009-05-26 Thread Lennart Poettering
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.

2009-05-26 Thread Jud Craft
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.

2009-05-26 Thread Jud Craft
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


[pulseaudio-discuss] Per-app flat volume adjustment is highly unintuitive, if mathematically consistent.

2009-05-25 Thread Jud Craft
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).

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.

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.

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.

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.
2.  Pulse should never change the main system volume on its own.  That's mine.
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.

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.

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) --
which means that since they usually don't change volume, they serve as
an arbitrary reference for the main system volume and all other apps
to match to.  This means that in Windows, when you adjust an App, it
doesn't change the system volume, since the system volume still
matches the Sound Events volume.

So, Solution B:  Make Sound Events show up on the Volume Control
Applications tab, and match the main system volume to it.  And make
sure that Pulse never changes or goes above the main system volume on
its own.  That would also fix the problem.

Thanks for your time, sorry about the long post.  I see in Redhat
Bugzilla #494112, there is the option to disable flat volumes, but I
don't want to do that -- I really just want the volume logic to be as
good as possible.
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss