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
