'Twas brillig, and Sean McNamara at 25/02/09 04:50 did gyre and gimble: > For networking, we only know about the case (a). We really have no way > of registering for notification of when a network-backed sink goes > from being unavailable to available. Well we do, we have module-zeroconf-discover. No need to poll there. > It seems that, to resolve that > problem, you would either have to poll, or add an entirely new class > of functionality: having a PA daemon become aware of clients that are > coming in from module-tunnel-sink, and send a "Hi, I'm alive" packet > to clients when the daemon starts. This exists, it's called avahi (bonjour, zeroconf, pick your favourite name!) and it already works!! > In other words, solving the generic problem of "determining the > instantaneous availability state of an arbitrary sink" is logically > prior to building your priority list. And unfortunately, the > availability logic has to be hand-coded for each different class of > sink. It gets even worse if you think about the availability of > virtual sinks, such as combined sinks. The availability and configuration of combined sinks needs work IMO. People want to be able to create combined sinks easily via a GUI and that (to me) is a good goal to reach. A combined sink should be "available" when one of it's slave sinks is available. That's pretty simple to work out IMO. > I haven't studied the innards of PA enough: do we have functionality, > at the generic sink level, of registering for notifications on when a > sink has become available or unavailable? Yeah, there is already a hook that will inform the listener when a new sinks becomes available. > If not, it would seem that > the first step to realizing this functionality at the Pulse<->Phonon > level is to submit a feature request to PA to implement the hairy > details of what we're discussing (or to generalize existing > availability logic for e.g. HAL-backed cards to the generic case of a > sink). There is not much in the this regard that PA does not already support TBH. All this stuff has been there for a long time. The only things I want to make pulse do is *remember* which sinks its seen in the past so it's own internal priority list can be tweaked. That way the KDE phonon system settings thing essentially becomes a window onto pulse. Tweaking the orders there is really just tweaking the settings in PA not in KDE. Passing on the phonon categories as pa roles will mean the routing logic etc. is done totally in pulse. That (IMO) is how it should be done. > Also, please don't just think of KDE when implementing this. The more > of the "priority list" logic and "availability notification" logic you > can implement PA-side, the easier it would be to hook up a GUI to this > same functionality on another desktop environment, perhaps one not > using Phonon. Indeed. I'm looking at other systems (e.g. OSX) too. 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/]
