Hi, Thanks for the comments. > Yes, this should generally be OK. The entries in each priority list are > what I've coined as "device+ports". This is basically a specific port of > a given device. Yep, and I think a route in the priority list should be considered unavailable if the device (ie. sink/source) is available but the active port does not match. In such case the subsequent, lower priority routes should be considered as long as a valid route target is not found. If we run out of the routes, the stream should be moved to the null sink (if loaded :). Alternatively the null sink can be part of the priority list I guess. (Or do I miss something here?) > > e.g. on some HW I have, I have a single sink, but that sink consists of > two ports: Speaker and Headphones. > > In a given priority list I may favour the built in Headphones first, > then some external USB headset, then the Speakers. > > So as you can see the single sink actually fits into the priority list > in two different places (or as many different places as there are ports). > Some separate logic (ultimately coming from David's work on jack > detection) would ensure a given port is activated when it becomes > "available". This means that I have some stream playing and it's on the > speakers, I plugin my USB headset and the stream moves over > automatically (due to a "reroute" event triggered when the new sink > becomes available). Then I plug in my headphones into the 3.5mm jack > socket, and it's detected as now being "available". The "separate logic" > mentioned, switches port from "speakers" to "headphones" and a "reroute" > event is triggered (just like a new sink appearing/disappearing, > "reroute" events are triggered on port changes too) and the stream is > automatically moved to the Headphones. Just to make sure we are on the same page: Basically I propose a routing scheme where the routing decisions would be made in a nested loop. In the outer loop we would walk through the streams in decreasing priority order (marked by the media role of the stream). In the inner loop we would walk through of the media role based routes of the stream (also in decreasing priority order). The first available route will be selected and configured, ie. the needed profiles and ports would be set. Next the stream could be moved to the actual device. Lower priority streams should never undo the settings caused by higher priority streams. So, IMO the 'separate logic' should not make unconditional port changes, rather it should consider the actual routing priority lists and make the port change accordingly. However, because in your preferences 'headphones' has the highest priority, the above routing scheme will select the route to 'headphones' and actually switch the port and move the stream from the USB sink to the sink of the headphones. The port switching will block lower priority streams from using the 'speaker'. So my point is that - the 'separate logic' should not unconditionally change the profiles/ports - we need some mechanism to mark cards/sinks to be configured to prevent lower priority streams to undo the possible port changes caused by higher priority streams - since the 'separate logic' completely driven by the priority lists, it can actually be part of the basic routing infrastructure. > NB I've used the term "separate logic" here quite loosely. David has > some code to do this already, but this may eventually be superceded by > logic inside the routing daemon that will automatically switch to higher > priority ports on sinks if they are available. I guess the above described algorithm (if you like it) could be part of the of the basic infrastructure inside PA. Might not harm to provide some mechanism to disable it and allow an external 'separate logic' to do the profile/port settings if someone wishes to do so. >> 3.) the routing module would also track the streams and maintain a >> list of the active media roles. > > OK, I won't specifically do that in the proposed implementation, but > (and feel free to correct me if I'm wrong) this is just a simple matter > of iterating over the sink inputs and check the media.role property on > each of them. Right. The routing module meant to see how the 'separate logic' would look like as PA module. The whole routing was split into two phases and the media role tracking was just an optimization. Let's forget about it for the time being :) -janos-
