On Fri, 2011-10-14 at 15:27 +0300, Janos Kovacs wrote: > The policy decision point would send profile changes for the detected > cards (needed to route between BT A2DP and SCO for instance) as well > as it would send for each media role a priorized UCM device target > list. This list in turn would be used by the device manager to route > the streams (i.e. sink-inputs and source-outputs) to the right > sink/source. Is it really necessary to send profile change commands from the decision point, if it's also sending routing priority updates? Wouldn't device-manager be able to do the needed profile changes by itself based on the new routing priorities? > Media roles would have priorities and the highest priority role would > determine the UCM verb. Currently only two seem to make sense: "HiFi" > and "Voice". UCM devices would be enabled/disabled based on the > targets for media roles. The rule would be that highest priority > device would be set first followed by lower priority devices if that > were possible at all. > > So the idea is to use a modified device manager, David's jack > detection (with the port support for cards) and a stripped version of > Margarita's UCM patches. > > First glance todo list for the components: > - Device Manager: > * should accept routing targets for media roles in terms of UCM devices > (e.g. 'speaker' instead of sinkname) Isn't UCM specific to alsa, and thus the UCM devices would not cover eg. Bluez devices? The device-manager should handle all device types, not only alsa. I like the general idea behind this todo item, though. I propose that there would be a general concept of "Route". UCM would provide Routes for device-manager, as would module-bluetooth-device and other pa_card implementations. The Routes would have names, for example concatenated sink_name+port_name, or something more readable, like "speaker", but then the different device types should somehow make sure that they don't create conflicting names. > * maintain a map for UCM device -> card, sink, port. That would be ok. Another possibility would be that these Routes would themselves contain the information about how they are activated (switching profiles and ports), and device-manager could then just call pa_route_activate(). > * not only route the streams to the sinks but also set the ports. > * hook-in to the jack-detection callbacks > - UCM Patches: > * beside profiles ports should also be supported. > * for jack detection we would use David's work > > Challenges: > - A resonable mapping of profiles and ports to UCM verbs+devices+modifiers. > - Multiple accessories of same kind (e.g. simultaneous use of multiple > BT devices, like car-kit and headset) > since we have just one 'bluetooth' UCM device Why is there only one "bluetooth" UCM device? Isn't the hardware adaptation able to configure UCM with arbitrary devices and names, so if there really are two bluetooth devices available in alsa, they could be named "bluetooth1" and "bluetooth2"? (Or even "bt-carkit" and "bt-headset" if the alsa devices are somehow hardwired to those device types.) > - route to multiple devices (e.g. ringtone to headset and speaker at > the same time) since only one port can > be active at the time. We could have ports for the combinations of > devices but it is kind'a ugly. Yeah, it's kind of ugly, but I don't see it as a significant problem in practice. I don't know if there is any better solution. I see this problem as a part of the larger problem of mapping the UCM concepts to the Pulseaudio concepts, though, so I think this item was redundant :) I don't personally think that the profile and port concepts are so great that they *must* be retained as they are now. I don't have any better system in my mind, though. Redesigning the core concepts would probably be an excessive amount of work anyway, so I hope that profiles and ports will suffice. -- Tanu
