[pulseaudio-discuss] limits on maximum device volume?

[pl bossart]

Lennart,
I wasn't really addressing the difference between sink and stream
volume. Your answer on which volumes are saved when was extremely
interesting and educational, but my concern was: 'how do I prevent the
user from setting a volume (stream or sink) that is too high when
he/she plays with the sliders. I understand some people want to boost
their volume of their poorly mastered tracks, but for most products
you want to avoid being too loud. I think there's even a EU directive
that the sound cannot be louder than xx dB for mobile devices.
Likewise iPods provide a means to lock the max volume. How would we go
about that in a PulseAudio/ALSA context.

On Fri, Apr 24, 2009 at 5:53 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> 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
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at mail.0pointer.de
> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
>