'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/
