[pulseaudio-discuss] limits on maximum device volume?

[Lennart Poettering]

On Fri, 24.04.09 17:14, pl bossart (bossart.nospam at gmail.com) wrote:

> Hi,
> I have been playing with flat volumes in 0.9.15. Nice functionality.
> But it seems nothing prevents an application from setting the volume
> to the max any longer. Is there a way to specify that the master
> volume should only change within predefined limits? That would be
> useful to avoid losing your hearing with a headset or waking up your
> neighbors at night.

Saved stream volumes are applied relative to the 'reference' volume of
the sink you play your stuff on. That reference volume is the one you
can control in the 'Sinks' tab of pavucontrol.  If you change the
volume of a stream (i.e. in the 'Playback' tab of pavucontrol) this
might have feedback on the visible volume of the sink, but won't move
the reference volume.

What this boils down to is: 

  If you change the volume of a stream, you just change the volume of
  that one stream for now and for the future. It won't have any effect
  on the volume of *other* existing or future streams.

  If you change the volume of a sink, you change the volume of all
  streams on it at the same time for now and for the future. It will
  have a direct effect on existing or future streams.

Or with other words:

If you changed the volume of your music and then have been surprised
that the volume of your event sounds didn't change too then you
apparently changed the stream volume but should have changed the sink
volume.

This dichotomy between is sink and stream volume is admittedly hard to
understand. Even technical folks are surprised by this, although most
folks admit that this behaviour does make a lot of sense.

I am not sure what way could lead out of this. 

On one hand people are annoyed if they turn up the volume of their
movie and then are shocked that the 'You've got mail' sound blasts out
of the speakers, too. On the other hand the same folks are annoyed if
they turn up their music because it's too faint and then wonder why
that 'You've got mail' sound is still so darn faint. In the first case
what they wanted was changing the stream volume but changed the sink
volume and in the second case they wanted to thange the sink volume
but changed the stream volume. That's why just sticking to "we only
expose the sink volume in the UI" or sticking ot "we only expose the
stream volume in the UI" doesn't cut it and will annoy at least half
of the people.

It's hard to be smarter than the user in figuring out what he really
wants.

The only viable solution I am seeing here is to not strictly base the
decision of the volumes for new streams on the saved and configured
volume factors but instead also base them on the actual signals in
question. i.e. we'd follow the current algorithms, but transparently
add some limits to it: we'd make sure that the perceived loudness of
an event sound never exceeds the perceived loudness of the currently
played music by some specific factor.

And actually I already thought quite a bit about how to best get
loudness logic into PA. For music files that include Replay Gain we
could just beef up gst to pass that to us in a stream property. For
event sounds we could obviously precalculate the Replay Gain when the
sample is cached. For everything else we could implement some Replay
Gain-like algorithm that would continously calculate some Replay
Gain-like value with a moving window or so. Of course for such streams
the statistical processing part of Replay Gain would have to be
replaced. And I wonder how expensive and necessary the loudness filter
that Replay Gain uses would be CPU-wise if we really should apply it
to all streams we have passing through PA.

If we'd have the Replay Gain value for all streams this would be
immensly useful, not just for the event sound vs. music volume policy,
but also as help implementing DRC to avoid clipping when mixing. The
fact that PA is designed for long hw playback buffers is pretty good
for implementing DRC, too.

Unfortunately my todo list is already more than full. Not going to
happen tomorrow. Unless of course someone wants to pick this up! Alwas
happy to take patches!

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4