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 >
