[pulseaudio-discuss] RFC: Routing and Priority lists

[Janos Kovacs]

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
>