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
