On Fri, 2013-06-28 at 12:37 +0200, David Henningsson wrote:
> On 06/28/2013 09:48 AM, Tanu Kaskinen wrote:
> > ---
> > src/pulsecore/sink-input.c | 45 +++++++++++++++++++++++++++++++++++++++++--
> > src/pulsecore/sink-input.h | 6 ++++++
> > src/pulsecore/source-output.c | 42 +++++++++++++++++++++++++++++++++++++++-
> > src/pulsecore/source-output.h | 6 ++++++
> > 4 files changed, 96 insertions(+), 3 deletions(-)
> >
> > diff --git a/src/pulsecore/sink-input.c b/src/pulsecore/sink-input.c
> > index 4863f15..a79aa4e 100644
> > --- a/src/pulsecore/sink-input.c
> > +++ b/src/pulsecore/sink-input.c
> > @@ -109,9 +109,11 @@ pa_sink_input_new_data* pa_sink_input_new_data_init(pa_sink_input_new_data *data
> > data->resample_method = PA_RESAMPLER_INVALID;
> > data->proplist = pa_proplist_new();
> > data->volume_writable = TRUE;
> > -
> > data->volume_factor_items = pa_hashmap_new(pa_idxset_string_hash_func, pa_idxset_string_compare_func);
> > data->volume_factor_sink_items = pa_hashmap_new(pa_idxset_string_hash_func, pa_idxset_string_compare_func);
> > + pa_node_new_data_init(&data->node_data);
> > + pa_node_new_data_set_type(&data->node_data, PA_NODE_TYPE_SINK_INPUT);
> > + pa_node_new_data_set_direction(&data->node_data, PA_DIRECTION_INPUT);
> >
> > return data;
> > }
> > @@ -229,9 +231,17 @@ pa_bool_t pa_sink_input_new_data_set_formats(pa_sink_input_new_data *data, pa_id
> > return TRUE;
> > }
> >
> > +void pa_sink_input_new_data_set_create_node(pa_sink_input_new_data *data, bool create) {
> > + pa_assert(data);
> > +
> > + data->create_node = create;
> > +}
>
> I tried to think of a use case where sink inputs would not have nodes,
> but failed (but I'm not sure how this would work with virtual sinks).
>
> If not, is there a reason to have this - can't we just always create the
> node?
At least with loopbacks there should not be nodes for the streams that
the loopback creates.
Ports, however, might be such that they should always have nodes. I'd
still like to keep the create_node option in pa_device_port_new_data for
consistency, but if you don't buy that argument, I'll remove it.
--
Tanu
