[pulseaudio-discuss] Get the 'future' volume of a stream?

[Colin Guthrie]

'Twas brillig, and Gregory Petrosyan at 13/12/10 17:14 did gyre and gimble:
> Hi everybody,
> 
> I am the current maintainer of cmus console music player (and the
> author of its PulseAudio output plugin).
> 
> Like every audio player, cmus displays the "volume control widget".
> Nothing unexpected here :-) But, in fact, this control serves dual
> purposes: it displays the current playback volume *and* it is used to
> indicate/configure the volume before the playback starts.
> 
> But the problem is, as it seems to me, that with PA I have no way to
> display/configure the volume before the playback starts, if I want to
> take advantage of module-stream-restore (pass NULL volume to the
> pa_stream_connect_playback, which is "strongly recommended"). So, I
> either store the volume myself and pass it to
> pa_stream_connect_playback (which seems not to be the "true way"), or
> I display no volume control at all before the playback starts, which
> is kind of a nonsense.
> 
> Am I right on this or not, and what is the preferred way to control
> the volume with PA?

Yeah you are more or less right, but there is an API that could be used
to get the volume before you start playing. It's a little fiddly tho' so
it may not be something you really want to do.

Other players choose to simply "grey out"/disable the volume widget
until playback starts but I appreciate this is not necessarily the most
elegant of solutions, but it's certainly the easiest!

The API you can use is the stream restore extension. As a reference, I'd
point you to the pavucontrol source which uses this API to get/set the
volume on for the "Event Sounds" slider on the Playback tab.

The general problem is that it relies on a "stream-restore-id" property
on the streams (in their proplist) to act as the key for
saving/restoring volumes (and devices and mute status too). The
stream-restore-id can be specified specifically by the application or it
will be determined automatically when the stream is created, typically
from either the "role" of the application or the individual application
name itself. Have a look at "pacmd list-sink-inputs" while your app is
playing and you should see the one used in your case.

The API will return all the saved volumes when reading them and you just
have to ignore all but the one you actually care about.

As I said, it's a little fiddly.

I talk a little about stream restore id here as part of a wider musing
on stream routing where I actually propose removing that property
completely and having a more deterministic (but flexible) tiered set of
priority lists to do the routing of streams (which has consequences for
volume too): http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/


One totally different thing you could do is open the stream to PA
immediately on startup but keep it "corked" (PA_STREAM_START_CORKED flag
IIRC) until it's needed at which point you can uncork. This might not be
a very wise thing to do (not really sure of the consequences in terms of
UIs etc.) but this should allow the stream to be routed and have it's
volume restored etc. even when it's not actively being played. Perhaps
we just need the UIs to differentiate between corked and uncorked
streams better (e.g. hide corked streams by default or grey them out
somehow perhaps?)

Not 100% sure what the best approach is here, so opinions from others
are welcome.

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]