On Sun, 2013-11-24 at 07:57 +0200, Tanu Kaskinen wrote:
> module-alsa-card does currently a bit of routing: it moves streams
> during profile switches with the goal of keeping streams connected to
> the same card before and after the profile switch. This doesn't
> belong to module-alsa-card, it should be in a policy module, so this
> patch set removes that code from module-alsa-card.
I'll start writing the next patch set now. To ensure that reviewers are
happy with the scope of the next patch set (there have been problems
with the scope in the past), I'd like potential reviewers to ack or nack
the following plan (the sooner the better):
Currently module-experimental-router sets the initial sink of a sink
input directly, but the routers shouldn't need to care about whether the
nodes are sinks or ports or sink inputs or whatever, and this is what
I'd like to work on next. How should the initial sink for a sink input
be set in the brave new node-based world? I think this should happen as
part of creating a new connection object. So, I want to introduce the
connection objects.
Eventually connections may contain loopbacks and whatnot, but at this
point they will be simple links between sink inputs and sinks, or source
outputs and sources. When someone creates a connection, the connection
does these things:
- If the stream is still in the initialization phase, the connection
sets the initial sink/source of the stream.
- Otherwise the connection calls pa_sink_input_finish_move() (if
pa_sink_input_start_move() hasn't been called, creating the connection
fails).
When someone deletes a connection, the connection calls
pa_sink_input_start_move(). What if pa_sink_input_finish_move() is never
called? The sink input should be killed, but what triggers that? I
propose that whoever is managing the connections is responsible for
calling pa_node_finalize_null_routing() if it's going to leave a node in
a connectionless state. In the future, sink inputs could implement null
routing by connecting to a null sink, but for now the behaviour of
pa_node_finalize_null_routing() for sink inputs would be to kill the
sink input and its node.
Who manages and owns the connections? If there's no router, the core
will of course need to manage the connections. The natural owner for
sink input connections in this case is pa_sink_input. If there is a
router, then connections may be created by the router, and I think it
makes sense in that case to make the router also the owner of the
connections, so freeing the connections is then also the responsibility
of the router. Hopefully it won't become too complex to tell apart
connections owned by the core and connections owned by a router.
So, the proposed scope for the next patch set is that connection objects
are introduced, the core will be able to manage its own connections, and
module-experimental-router will be able to implement its routing policy
by creating connection objects instead of directly setting the sink for
sink inputs.
--
Tanu
