On 07/17/2013 11:22 AM, Tanu Kaskinen wrote:
On Wed, 2013-07-17 at 09:27 +0200, David Henningsson wrote:
On 07/16/2013 03:20 PM, Tanu Kaskinen wrote:
Yes, automatic use of the combine module is planned (the combining
functionality would move to the core, because what's the point of having
code in a module if the core directly depends on that code).
Okay, so combine stuff would then not have its own node or set of nodes,
but essentially be as integrated as mixing is today?
Yes. Or well, I wouldn't say that it's as integrated as mixing, since it
would still create a separate combine sink, which is a bit ugly, but as
you said, the sink and the intermediate sink inputs wouldn't show up as
nodes. I think it would make sense to make combining really as
integrated as mixing, but that's not a high priority.
Ok.
- Can there be more than one edge between the same nodes? E g, one
default connection and one explicit connection? Or how does this work?
Yes, there can be both an explicit and a default connection between two
nodes, or it can be also thought as being one connection that is both
explicit and default. I don't know what is a better way to think about
it, but perhaps it doesn't matter anyway.
I would prefer the latter way. I would then see "default" and "explicit"
as a property of the edge.
I agree about that, at a conceptual level. Would you perhaps like to
have it this way also at the code level, i.e. have connection objects
with "default" and "explicit" fields instead of storing the information
in the nodes?
Good question. Actually one option could be to store the connections as
global list-like matrix instead of lists on the individual node objects.
After all, you'll need the connection on both sides, and unless you want
to duplicate information, you'll have to do a global search on one of
the sides anyway. Since the number of nodes < 100, I don't think this
would matter from a performance standpoint.
You would end up with a global list with entries looking something like:
struct pa_node_connection_t {
pa_node *from_node;
pa_node *to_node;
bool default;
bool explicit;
bool explicitly_disabled;
};
Where there is only one entry for every from_node/to_node combination,
explicit and explicitly_disabled cannot both be true, and there is a
connection if and only if (!explictitly_disabled) && (explicit || default).
And no list entry for a node combination, is the same as all three bools
being false.
- Can edges have properties, e g, a volume?
I don't know. Currently I'm not aware of a requirement to have
properties on the connections. My current thinking regarding volume
specifically is that we shouldn't attach volume to nodes: let's keep the
nodes for routing only.
Ok, that makes sense.
* As for possible node operations, a move operation would be the same
as a "batched remove + add" operation. Maybe therefore the batch
solution would be better, i e, the client API inputs an array of node
operations?
I don't like the idea that if a client wants to move a stream, it has to
break the operation down to "remove + add", and then the server tries to
guess what the client really meant. Having a "move" operations keeps the
client intention obvious.
Fair point, although the move can be on both sides, whereas one type of
move would be "I want node A to take data from C instead of B" and the
other type would be "I want node A to output data to node C instead of B".
These both are served by the move operation.
In the RFC you only have pa_context_move_node_connection, which serves
the latter case only. The former case is from "C -> A" to "B -> A", the
typical example would be a client wanting to move a recording stream
from one source to another.
Or perhaps you want to swap, so that if you're currently on "A -> B and
C -> D" and you want "A -> D and B -> C" and you want to do all of this
atomically. The number of operations you want to do might grow out of
hand unless you have a "batch mode".
The core doesn't currently have a concept of atomic swapping, so I don't
see the need for a separate swap command, but the core has a concept of
atomic moving.
Well, IIRC, we have move_start and move_finish commands? A swap command
would just be two move_starts and then two move_finish.
If you think applications need to be able to swap connections in one go
(even though the server will execute the commands sequentially), I'm not
opposed at all to having a batch mode.
* The operations on changing the default connections does not make
sense to me. If the definition for default connections are those made
automatically by the routing system, if you change them then you broke
the definition...?
What operations do you mean? Moving or removing a default connection is
not supported as such, but if the client tries that anyway, we can
implicitly convert the connection to an explicit one and disable default
connections, or we can require the client to do these operations
explicitly, but I think the latter would be too inconvenient for the
client.
Ok, I think I didn't read the proposal well enough. Having done that, I
understand that you're suggesting a global switch "default connections
on/off" only. Or is it a per-node switch?
It is a per-node switch.
I have another idea that might be worth considering: how about that the
"explicit" layer can both enable and disable connections? So that there
could be a default connection between A and B, but there is also some
sort of explicit override that disables it. This would be more flexible
than a more global on/off switch.
I'm not sure what you mean. Do you perhaps mean that the default
connection on/off switch should be per-node (which it already is in my
proposal), or that it should be per-connection (so that if there are
multiple default from node A, it's possible to disable only a subset of
those)?
I didn't make make it possible to disable individual default
connections, because I had a feeling that it would have very messy
semantics. If default connection from A to B is disabled, what is the
routing code supposed to do when conditions change and the default
routing is re-evaluated? Can it ever reactivate the connection between A
and B again? Is the per-connection disabling handled as a blacklist of
connections that must never be automatically activated?
If the A -> B route is explicitly_disabled, that overrides any default
connections the routing system tries to make.
--
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
