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
