[pulseaudio-discuss] RFC: Routing and Priority lists

[Tanu Kaskinen]

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