[pulseaudio-discuss] RFC: Routing and Priority lists

[Colin Guthrie]

'Twas brillig, and Tanu Kaskinen at 16/11/11 22:16 did gyre and gimble:
>> 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.)

I think the availability information is basically the same as David's
jack sense stuff.

In the previous reply, the "racy" concern is somewhat covered I think
(assuming different priority lists have weights (even for the keys
within a single priority list), thus how to "auto switch" and use the
devices/ports becomes more "order of stream routing" agnostic and less
racy. The implementation will obviously become more complex with
auto-switching is enabled (primarily needing to know about other routing
decisions that may be made in parallel - nothing impossible but tricky
all the same :))


>> 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.

Yup I agree.

>> 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?

Yup, this makes sense to me too.

> I think ports will need property lists for other reasons, though, so I'm
> certainly not against that.

And Yup³

Cool, I think this is begging to take shape now :)

Col



-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/