[pulseaudio-discuss] [PATCH v2 3/6] card: move profile selection after pa_card_new()
Alexander E. Patrakov
patrakov at gmail.com
Mon Jun 13 08:35:29 UTC 2016
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
> 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
More information about the pulseaudio-discuss