Hi, First a disclaimer: I haven't read Colin's proposal properly yet, so I may be missing some stuff. On Wed, 2011-11-16 at 15:04 +0200, Janos Kovacs wrote: > I try to build a multimedia policy for embeded systems like smart > phones, TV's in vehicle entertainment systems etc. > The idea is to have a policy decsion making daemon that would control > audio/video routing among other things. This policy > daemon supposed to push down policies to the actual madia handling > daemons eg. pulseaudio, X server or Wayland > compositor. So my comments come from that angle. > > In general the priority list seem to be suitable approach for us. > However, in the routing decision we want to deal with logical > devices like 'speaker', 'headset' etc not cards, sinks ports etc. > That would allow to separate policies from the HW adaptation. > IMO the mapping of logical devices to actual cards/sinks/sources/ports > should be done in pulseaudio. One reason we are > interested in UCM is that UCM natively support those logical devices. 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. > The routing is somewhat similar what Tanu once proposed some time ago. > Generally the routing would happen like: > 1.) the policy decision point would figure out a priority list of > logical devices for each media roles and push those lists to > pulseaudio. > 2.) a routing module in pulseaudio would maintain mappings between > logical devices and actual cards/sinks/sources/ports > and the availablility of those logical devices. In case of > multiple logical devices it would select the preferred one (lets > discuss later how this would happen). 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...) 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.) > 3.) the routing module would also track the streams and maintain a > list of the active media roles. > 4.) when streams appear/disappear the the routing module would figure > out the card and port settings by walking through > of the active media roles. Media roles would have priorities and > the routing module would first set the cards/ports for the > highest priority routing target of the highest priority media > role. The subsequent media roles would be routed to the first > non-conflicting routing target (that can be in worst case the > nulll sink). Consequently the cards/ports would be set > accordingly. > 5.) the actual streams will be (re)routed to their sinks/sources if needed. I think this (points 3-5) should be part of the generic routing module that will be used also on desktops. > If the routing infrastructure will not support logical devices as > routing targets, in step 4 the routing module would create > for each media role a routing list with the single sink entry. > > I am actually prototyping something to see how this algorithm would > work in practice. What we call a logical device maps > to device port in pulseaudio. It seems that the above algorithm can be > done but some infrastructural support for logical devices > would be good. For instance adding properties to device ports would > help. A property that describes the connected device > would help a lot (ie. instead of 'analog output' one could see that > actually a 'speaker' is connected to the jack). 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? > 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? I think ports will need property lists for other reasons, though, so I'm certainly not against that. -- Tanu
