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
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
