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
