On 06/19/2013 08:11 PM, Tanu Kaskinen wrote:
On Wed, 2013-06-19 at 19:50 +0200, David Henningsson wrote:
On 06/19/2013 05:40 PM, Tanu Kaskinen wrote:
pa_port_node takes care of things that are common to all port nodes.
The port device class is used in the node name for some extra
user-friendliness. The goal is to avoid the long and cryptic names
that are currently generated for sinks, sources and cards.
I'm not following. Why do we need extra pa_port_node and pa_sink_node
objects? Why don't we just have a pa_node pointer (or even embedded
struct, if that makes sense) in pa_device_port / pa_sink instead?
pa_node will probably have some callbacks, at least for activating the
node. I expect that e.g. pa_port_node would have a common implementation
for activating ports. There may or may not be need for further
specializing the activation code by adding an activation callback also
to pa_port_node. This is largely speculation, however, because this
hasn't been fully designed yet.
Hmm, I'm still not seeing why all types of specialization and callbacks
can't just be handled by code taking just a node pointer, like:
/* In device-port.c */
void activate_node_cb(pa_node *n)
{
pa_device_port *p = n->userdata;
/* Do some specialized node related stuff here */
activate_port(p);
}
If necessary, this method can also call p's callbacks if you need to
something differently for alsa and bt (although it would be more elegant
if such code was inside activate_port() rather than activate_node_cb).
If you think pa_port_node is bad, we
could try going without it until we actually need it.
At this point the struct looks very superfluous to me.
If every sink, source and port have exactly one node, that seems to be
the logical object model. Or can sinks, sources and ports have more than
one node attached to them?
I don't think it's likely that we would some day need one port or sink
to have multiple nodes - we certainly don't need it today. It's entirely
possible that a port or a sink could have zero nodes, however (or at
least it's possible for sinks - e.g. bluetooth sinks don't have nodes,
and neither do alsa sinks if ports are present).
Ok, then the logical object model to me seems to have a pa_node pointer
in pa_device_port and pa_sink. That also simplifies code because you
don't have to do anything in the alsa/jack/bluetooth backends - just
initialize the node in e g pa_sink_new and/or pa_sink_put.
--
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
