'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 > make? 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 pulse :) 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!). Read on.... > 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() > move_stream() > done 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 :) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/]
