On Sun, 2011-11-13 at 16:42 +0200, Colin Guthrie wrote: > Hi, > > I've written up my latest proposal to gather feedback before starting > (hopefully soon now) on the implementation. > http://www.freedesktop.org/wiki/Software/PulseAudio/RFC/PriorityRouting Thanks for your work! That RFC alone looks like it has already taken a lot of effort. I feel a bit sorry for suggesting such big changes below, but let's see how the discussion continues... The system seems to be structured quite differently from what Janos was proposing: that there would be a central routing function that would have an outer loop that iterates through all streams in priority order, and an inner loop that iterates through one stream's route list in priority order, always selecting the first available route, and doing the required profile and port changes immediately, as well as moving the streams to the right devices. In your proposal it's unclear how such changes can be done at all - is that supposed to be done in the route hook callbacks? If that's the case, then you're relying on module-rescue-streams to move streams somewhere when the device disappears that they used previously, otherwise those streams get killed. Moving the streams to the correct devices happens only after all profile and port changes are done. I think that's a serious problem. Streams that are playing to a sink that changes port to one that is not suitable for the stream will leak their audio to the new port for a short time. Also the device that module-rescue-streams chooses can be wrong one, again making sound to go to a wrong place for a short time. We have had to fight this kind of issues in the Maemo phones. I think the right approach is to detach a stream whenever the device that it's initially connected to either disappears or changes port. The stream should be attached to the correct device when the stream's routing decision is done. I feel that the "multiple lists in one priority list" concept and priority list weights add unnecessary complexity. I think each stream should have exactly one priority list attached to them and that's it. It's up to the routing modules to set the correct list to each stream. I'm also not sure that we should add the priority list introspection and editing to the core API at this point. It may not be desirable to always give clients direct access to the priority lists. If some routing module wants to do that for its lists, then it could do that through an extension API. The priority list name and description (uiname) wouldn't be needed in the core. I think that's enough for now. -- Tanu
