[pulseaudio-discuss] [PATCH 2/8] card: Add variables for splitting up a profile

[Tanu Kaskinen]

On Mon, 2015-10-19 at 17:11 +0200, David Henningsson wrote:
> 
> On 2015-10-19 16:32, Tanu Kaskinen wrote:
> > On Mon, 2015-10-19 at 16:11 +0200, David Henningsson wrote:
> > > 
> > > On 2015-10-19 15:56, Tanu Kaskinen wrote:
> > > > On Tue, 2015-05-05 at 17:01 +0200, David Henningsson wrote:
> > > > > It can be useful for routing modules to know if a profile consists
> > > > > of an output and input part, in order to e g change output profile
> > > > > while keeping the input profile unchanged.
> > > > 
> > > > n_sinks and n_sources already tell if a profile consists of an output
> > > > and input part.
> > > 
> > > It's not only *if* but also *what* the input and output parts are.
> > 
> > Ok, so routing modules may want to know what particular sinks and
> > sources the profile contains. Since a profile may contain multiple
> > sinks or sources, I think the fields should contain all sink/source
> > names, and not only one that is selected according to some unobvious
> > logic.
> 
> Yes. Although more than one sink is currently not implemented (it leaves 
> the field as NULL instead - see later patches).
> 
> > Currently the fields don't contain the actual sink/source name, but an
> > alias (derived from the alsa mapping name) - are there good reasons to
> > prefer an alias rather than the real sink/source name?
> 
> Consistency with the name field, I suppose. Or plain simplicity. I 
> didn't really think of the option of using the real sink/source names 
> instead.
> 
> The sink(s) are not created until the profile is activated, so I haven't 
> checked if it's easy or difficult to use the sink/source names instead.
> 
> The idea is just to make it possible for a routing module to keep "the 
> other side" unchanged - e g, when hdmi is unplugged and the routing 
> module needs to swap to analog speakers (and thus an analog profile), it 
> should try to select a profile which has the same input_name as the 
> current one.
> 
> In the future maybe input_name/output_name can be improved and used for 
> more things.

After reading your reply, I'm not sure if you're planning to implement
any of the proposed changes. I'd really like you to change the single-
name fields to lists (hashmaps or whatever) that contain the ids of all
sinks and sources. Populating the lists should be easy. If the policy
modules can't deal with multi-sink profiles, they can just ignore such
profiles.

Since the names refer to sources and sinks, I suggest that you rename
input_name/output_name to source_names/sink_names, or if it turns out
to be too complicated to use the actual source/sink name, maybe the
field names should be source_ids and sink_ids to not suggest too
strongly that the strings would be actual source/sink names.

-- 
Tanu