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

[Gregory Petrosyan]

On Mon, Dec 13, 2010 at 8:41 PM, Colin Guthrie <gmane at colin.guthr.ie> wrote:
> '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.

Thanks a lot for the answer; I'll try to look into the pavucontrol sources.

Do I understand correctly that I need to "guess" the
"module-stream-restore.id" before the stream exists?

> 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?)

The problem with the "create the stream beforehand" method is that I
can't create a stream without knowing the desired sample format, that
is, before the playback starts.

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

                Gregory