13.06.2016 01:36, Tanu Kaskinen пиÑ?еÑ?: > On Sun, 2016-06-12 at 18:33 +0500, Alexander E. Patrakov wrote: >> 10.06.2016 22:55, Tanu Kaskinen пиÑ?еÑ?: >>> I want module-alsa-card to set the availability of unavailable >>> profiles before the initial card profile gets selected, so that the >>> selection logic can use correct availability information. >>> module-alsa-card initializes the jack state after calling >>> pa_card_new(), however, and the profile selection happens in >>> pa_card_new(). This patch solves that by moving parts of pa_card_new() >>> to pa_card_choose_initial_profile() and pa_card_put(). >>> >>> pa_card_choose_initial_profile() applies the profile selection policy, >>> so module-alsa-card can first call pa_card_new(), then initialize the >>> jack state, and then call pa_card_choose_initial_profile(). After that >>> module-alsa-card can still override the profile selection policy, in >>> case module-alsa-card was loaded with the "profile" argument. Finally, >>> pa_card_put() finalizes the card creation. >>> >>> An alternative solution would have been to move the jack >>> initialization to happen before pa_card_new() and use pa_card_new_data >>> instead of pa_card in the jack initialization code, but I disliked >>> that idea (I want to get rid of the "new data" pattern eventually). >>> >>> The order in which the initial profile policy is applied is reversed >>> in this patch. Previously the first one to set it won, now the last >>> one to set it wins. I think this is better, because if you have N >>> parties that want to set the profile, we avoid checking N times >>> whether someone else has already set the profile. >> >> Looks OK to me, but I would like an extra confirmation whether in the >> UCM case the sequence of mixer accesses is the same before and after the >> patch. > > That's a pretty specific concern. What makes you concerned about the > UCM case and not about the non-UCM case? Scratch that. It was based on my misunderstanding. I incorrectly thought that the patch changes the call chain that leads to card_set_profile(), and there is "if (u->use_ucm)" there. The new u->linked field guarantees that card_set_profile() is not called prematurely, so my concern was completely unfounded. The patch is OK. -- Alexander E. Patrakov
