On Fri, 2011-11-18 at 16:58 +0200, Janos Kovacs wrote: > > By maintaining the availability information, do you perhaps mean that > > the module that interfaces with the policy daemon would publish the > > availability information to the policy daemon? If that guess was > > correct, what would that information be used for? (I'm fearing that the > > availability information would affect the priority lists, which would > > make the routing changes racy - the streams would get first routed using > > the old priority lists, and then again with the updated priority lists. > > I hope that won't be necessary. I hope the priority lists from the > > policy daemon will be largely static.) > > > > No, my idea was that we would use quite static priority lists what would > change only if you get an external event, like incoming call. Needs to be > proved in practice however. That is one of the reason that I try to > protototype the whole idea. I liked the "my idea was that we would use quite static priority lists what would change only if you get an external event" part, but the "like incoming call" example ruined it :) Why should an incoming call affect any routing priority lists? When an incoming call happens, a stream is created for the ringtone. The system should have a static routing priority list for ringtones, so no need to update any lists. A better example (for handsets) of an "external event" would be that the user has a call ongoing, and uses a bluetooth headset. The user then chooses to put the call to the loudspeaker, so the call audio routing priority list needs to be updated so that the loudspeaker goes higher than the headset. Now I also see why you want to maintain the availability information for the policy daemon - if there's no headset available, the UI should know about that, and the UI probably talks to the policy daemon instead of Pulseaudio directly, so the policy daemon needs to know it too. > > I think this (points 3-5) should be part of the generic routing module > > that will be used also on desktops. > > As I said before I would be more than happy to see that. However, we > are prepared to build this thing top on the current proposal as it seems > feasible. I don't actually like the proposal much, but maybe I'm envisioning a too big change. Maybe the proposed system is a good intermediate step that doesn't require rewriting too much stuff. > > What's the concrete scenario here? I'd expect there to be usually > > separate ports for separate accessory types. That is, if you mean that > > an "analog output" jack could be used for both speakers and something > > else, let's say headphones, you probably know in advance that the jack > > can support multiple types of accessories, and you'll be somehow able to > > detect which type is connected at any given time. You should then have > > separate ports for each accessory type, and activate them according to > > what the jack detection mechanism says. If you don't have good enough > > jack detection mechanism, you wouldn't be able to set the accessory > > description property either, right? > > Actually I was thinking that there is only one port but it could have a property > that tells what sort of logical device is connected to it. If the > device cannot be > detected automatically the user could set it via UI. That's why I proposed the > protocol change that I could set it via the UI that an active speaker is > connected to my the jack. I think you could still have separate ports for each accessory type. It would make it simpler to set up accessory specific tuning parameters, for example, if the only thing that mattered was the port in use, instead of the port and some property. > > Can you give some concrete example? What kind of applications would get, > > and especially set, the property? > > One could write a UI applet that would listen to jack events and if the jack > detection cannot determine the connected device it would pop up a dialog > box where you actually could say what was plugged-in. Mobile devices do > this for ages. Thanks, now I see your point. -- Tanu
