Hello,
Quoting "Tanu Kaskinen" <[email protected]>:
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.
We will first try to integrate existing pulseaudio infrastructure
with UCM and see what are the limitation, challenges etc.
Already in this early phase we can see that the mapping is not very
straight forward and we might have to do some changes to the UCM code
(we have been experimenting with ucm only in a desktop environment).
--
Tanu
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
br,
Jaska
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
