Hi, Thanks for the comments ... > I don't really see what UCM has to do with the policy daemon. Maybe > you'll be able to use the same names as identifiers in the UCM > configuration and as logical device names in the policy configuration, > but I don't think they should be tightly coupled. The policy daemon will > anyway have to interact with non-alsa (ie. non-UCM) devices, so you'll > need a way to map logical device names to arbitrary ports. Right. UCM is a side track in this discussion so let's drop it. And it is also true that we will need to work with an increasing number of non-alsa cards sinks etc. However, bluetooth for instance, already exposes profiles names that make easy to guess from the profile name what logical device is behind. > In my mind the "routing module" that you're talking about here would be > just a module that takes care of translating the logical device priority > lists into the "native" priority list format and pushes the lists into > the routing system. I'd expect there to be some separate generic module > (or the functionality might also be in the core) that acts on the > "native" priority list changes. (I think here it would help if I'd have > read Colin's proposal...) What I tried to propose is a two phase routing scheme. In the first phase PA cards and sinks/sources would get configured (ie. the profiles and ports would be set) and in the second phase the streams would be moved if needed. If I understood right from Colin's proposed code fragments, the new routing infrastructure deals with sinks/sources. It was mentioned that optionally cards/ports could also be set but I do not know how. So my proposal was that the fisrt phase would be done by the routing module and second phase would use the proposed routing mechanisms. Of course it would be better if the whole thing would be supported natively by the infrastructure :) > 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 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. > > 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. > >> And of cource >> some protocol change that this property could be get/set by applications. > > 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. > > I think ports will need property lists for other reasons, though, so I'm > certainly not against that. > > -- > Tanu > > _______________________________________________ > pulseaudio-discuss mailing list > pulseaudio-discuss at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss >
