[pulseaudio-discuss] RFC: New volume functionality for PulseAudio

Arun Raghavan arun at accosted.net
Tue Feb 18 08:12:35 PST 2014


On 17 February 2014 23:04, Alexander E. Patrakov <patrakov at gmail.com> wrote:
[...]
> A sensible model has been demonstrated (as a replacement of the current
> logic) that doesn't fit into those assumptions. E.g. (here I am deliberately
> trying to "misinterpret" and/or augment the earlier e-mails by Tanu, just to
> see if this modification breaks any of his own assumptions):
>
> A. For each sink, there are two volumes: "System" and "Entertainment". None
> of them can be said to be the system's main volume. An attempt to read or
> adjust the sink's volume via legacy tools follows the usual flat-volume
> logic and changes both.

I see these falling under volume classes, rather than multiple
controls for each device.

> B. These volumes exist and are adjustable via new tools even if nothing is
> playing through that sink.

I don't follow - what volumes are you talking about here?

> C. Any stream playing through a sink does not have an
> independently-adjustable volume. It effectively assumes one of the "System"
> or "Entertainment" volumes belonging to the sink, depending on its media
> role. An attempt to read or change the stream volume via legacy interfaces
> reads or adjusts one of the "System" or "Entertainment" volumes belonging to
> the sink, as appropriate.

Again, this is to do with volume classes and not volumes being
represented as objects on the server. I hope the difference I'm trying
to draw between the two is clear?

-- Arun


More information about the pulseaudio-discuss mailing list