[pulseaudio-discuss] couple with vnc
gmane at colin.guthr.ie
Thu Dec 11 08:23:02 PST 2008
'Twas brillig, and Brian J. Murrell at 11/12/08 15:01 did gyre and gimble:
> On Thu, 2008-12-11 at 14:45 +0100, Lennart Poettering wrote:
>> You shouldn't be using padevchooser anymore. It is obsolete.
> As in completely obsolete? i.e. distro vendors should not be shipping
> it? Note that I am using pulseaudio 0.9.10. Not sure how that affects
> this deprecation of padevchooser.
> So if padevchooser is obsolete, how do I, as a desktop graphical user
> access the manager, volume control, volume meters, preferences, etc.
> that padevchooser gave me access to? But most importantly, how do I
> make default server, sink and source changes that padevchooser lets me
This statement explains why padevchooser has been obsoleted because this
way of working is not really how things should be done is a more modern
Most of the time you don't want to change the default server, but rather
redirect a given stream (there are of course reasons to redirect all
streams to another server but but it shouldn't be done this way!).
> I notice any currently playing audio (like a rhythmbox for example) does
> not change play locations until it's paused/stopped and resumed.
This highlights the problem :) Streams shouldn't have to be
stopped/started to change the server but by changing these config
variables that's what you are enforcing.
A nicer user experience is to *always* talk to your local server. If you
want to redirect your audio to another server, you create a "tunnel
sink" on your local server that connects to the remote one and then move
your stream across. The application is then totally unaware that this
has happened and we achieve our desired level of abstraction :)
> I guess there is no way to change in progress streams? Although, I can do
> that from the Volume Control applet, on a stream by stream basis. Is
> there a programmatic way of doing that?
> for each stream in enumerate_streams()
In theory yes, you can do that but again, I'd question if that is the
*right* thing to do!
What I'd rather see here is some kind of routing system in pulse that
can do a kind of "I'd like to send everything to this tunnel sink
regardless of saved preferences" routing (although not quite
functionally equivalent to sending all connections to a remote server
which would allow the remote server to make routing decisions about
where the streams should go etc.).
I think that keeping the user controlling their streams via one
connection to one server is the way to go. I do think that to get the
absolute best out of pulse that the routing system needs some work, but
I'm not totally sure how best to make this work for now!
I do think the concept of a "default sink" is needed (perhaps this can
be done via a module that just piggy back on to a real sink and can
change which sink it piggy backs on to at run time?), but perhaps
Lennart has more grand plans :)
Tribalogic Limited [http://www.tribalogic.net/]
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]
More information about the pulseaudio-discuss