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? This patch shouldn't affect the mixer access pattern in any case, UCM or not. This patch only postpones the initialization of pa_card.active_profile a bit: module- alsa-card.c used to call init_jacks() after active_profile had been initialized, now init_jacks() is called before active_profile is initialized. init_jacks() doesn't depend on active_profile, so I don't think this patch can cause any changes in the mixer access patterns. -- Tanu
