[pulseaudio-discuss] [PATCH 14/21] port-node: Introduce pa_port_node

[David Henningsson]

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