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
