[pulseaudio-discuss] User volume vs. Application volume

[Andrew Eikum]

On Thu, May 24, 2012 at 06:33:43PM +0300, Tanu Kaskinen wrote:
> I agree that Pulseaudio should provide facilities for fading. We could
> insist that applications do such processing themselves (like is
> currently required), but the problem is that it's a non-trivial thing
> with large buffers when the fading should begin immediately upon user
> input - it requires the application to understand the concept of
> "rewinding" (going back in time and rewriting already written data). I
> think fading is so common feature that it makes sense to save the
> duplicate work of implementing the complex audio rewriting logic in
> every application by doing it in Pulseaudio.
> 
> I don't think using an "application volume" as in Windows is the right
> solution for fades, though. If it works so that the application sends
> volume change commands at a high rate, it will cause rewinding at the
> server end at the same rate, which is unnecessarily wasteful and may
> possibly cause even user-visible performance problems. I think
> applications should just tell when a fade should start and how long it
> should last.
> 
> That said, an "application volume" may be useful for other purposes
> (replay gain is the only concrete use case that I have in mind), and I
> have already filed a feature request for it myself:
> https://bugs.freedesktop.org/show_bug.cgi?id=39556
> 

I feel like it'd be useful in any context where the application wants
to control its volume. For example, ducking audio during a video game
when voice chat occurs; or A/V production software with volume
controls for the individual elements. Giving the application the
ability to say, "Cut this stream's volume in half compared to the rest
of the streams" without also overriding the user's preferences seems
nice.

Your bug description basically sounds like exactly what I had in mind.

> Since you wanted to hear tips about API design for this stuff, are you
> perhaps planning to implement this in Pulseaudio yourself? That would be
> great - I don't think this will otherwise get done in any timely manner.
> 

A simple, application-side volume control would probably be pretty
easy. It would be just another value to multiply against the user
volume value before mixing.

On the other hand, I find PA's API to be incredibly user-hostile as it
is. I'm afraid to make it even worse by adding more functions without
having the familiarity with PulseAudio to make it mesh sanely.

In addition, dealing with the rewind issues you presented is probably
more work than I'd be willing to do on evenings.

Andrew