[pulseaudio-discuss] Stream volumes as the universal volume adjustment method

[Lennart Poettering]

On Fri, 15.01.10 07:19, Tanu Kaskinen (tanuk at iki.fi) wrote:

> 
> to, 2010-01-14 kello 23:25 +0100, Lennart Poettering kirjoitti:
> > To be a bit more constructive this is what I kinda have in mind
> > regarding stream and device volumes:
> > 
> > 1 in the UI prominently expose the device volume, since I believe this
> >   is what the user wants to control more often.
> > 
> > 2 In the UI less prominently expose the stream volumes. Should be
> >   available for some cases, like compensating for normalization issues
> >   and suchlike.
> 
> Normalization issues == song or video that is too quiet (or in some
> cases too loud)? I'd like to use the hardware controls for fixing these
> temporary issues too. The hardware controls control the device volume,
> but I think in practice it works well that way also, so no need to touch
> the stream volume. Stream volumes should really only be adjusted by the
> user in cases where two streams are active simultaneously or when some
> application *consistently* plays at too low/high level. In other words,
> the user should never touch the stream volume for temporary changes...
> uh... except when playing two streams simultaneously.

I think people would really hate it if we automatically would even out
all volume changes in streams based on a short time window. that would
be DRC. And (in this form) it's evil.

ReplayGain only makes sense if you can look at tracks or even discs as
units and compensate for loudness out between those units as a whole,
instead of just a short time window into the past.

I guess the actual replaygain compensation needs to take place in the
music player, nowhere else. However, the replaygain information could
be forwarded to us so that we wouldn't have to determine it for the
streams and waste CPU cycles on it. If we then have this perceived
loudness information we would use that to make sure event sounds
aren't massively louder (or fainter) than the content stream you are
playing.

if the player does not do replaygain compensation then the user could
apply it manually, and that's where per-stream volumes exposed in the
UI should be useful.

> > 3 As mentioned determine the perceived loudness of content streams
> >   (i.e. music and movies), and allow configuration of auxiliarly
> >   stream loudness (i.e. event sounds) relative to it.
> 
> I don't remember exactly what you said earlier (and I'm too lazy to
> search and re-read the message), except that you mentioned implementing
> ReplayGain partially. That gave me the association to automatically
> normalizing all audio (not compressing - many people would like that,
> but it shouldn't really be enabled by default). Auto-normalization would
> be awesome, if it worked well, but it's probably impossible to make it
> work well. But now after thinking a bit, I realize that you mean
> something different: just tracking, not changing, the real music/movie
> volume level is actually useful in itself, exactly for the purpose of
> playing event sounds at a good level even when the user has changed the
> device volume due to bad normalizing of the song/video.

Yes, exactly.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4