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.
There is currently no use for allowing modules to cancel card creation,
and I don't see need for that in the future either. Let's simplify
things by removing the failure handling code.
This is needed so we don't keep stale jack availability information
while the card is suspended.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=93259
Signed-off-by: Arun Raghavan <arun@arunraghavan.net>
I will modify module-switch-on-port-available so that it will keep
track of which input and output port the user prefers on the card,
based on the user's profile and port switches. The preference needs
to be saved on disk, for which I will use module-card-restore.
To facilitate communication between the two modules, this patch adds
preferred_input_port and preferred_output_port fields to pa_card, and
a hook for monitoring the variable changes. It would be nice if the
two modules would communicate directly with each other, but
implementing that would be somewhat complicated, so I chose this time
for adding the functionality to the core. In theory some other routing
module might want to manage the new variables instead of
module-switch-on-port-available, but admittedly that's not very likely
to happen...
In case pa_card_set_profile is called with save=false, then probably
it makes more sense not to update the port's preferred profile as well.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
It can be useful for routing modules to know a profile's input
and output parts, in order to e g change output profile
while keeping the input profile unchanged.
For now filling in these fields is optional and a routing module
must be able to handle NULL in these fields.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
FSF addresses used in PA sources are no longer valid and rpmlint
generates numerous warnings during packaging because of this.
This patch changes all FSF addresses to FSF web page according to
the GPL how-to: https://www.gnu.org/licenses/gpl-howto.en.html
Done automatically by sed-ing through sources.
When given an explicit device.description in card_properties, prefer
this information over other default prefixes (e.g. 'Built-in Audio')
when constructing sink/source descriptions.
For example, if I manually configure the card description to be
"FooBar", I then expect that the sinks and created by the card also
have "FooBar" in their description instead of generic "Built-in
Audio".
When setting attribute foo, or in this case the card profile, in my
opinion the thing passed to the set_foo() function should be of the
type of foo, not a string identifier that can be used to search for
the actual foo in set_foo().
This is mostly a question of taste, but there's at least some small
benefit from passing the actual object: often the profile object is
already available when calling pa_card_set_profile(), so passing the
card name would cause unnecessary searching when pa_card_set_profile()
needs to look up the profile from the hashmap.
f434087e42 introduced the potential to not select a card profile if
all the profiles were marked as unavailable.
While this is very unlikely, it's a theoretical posibility, so if the
initial choice of a profile fails, try harder.
When a card is being created and no profile has been assigned
pa_card_new will attempt to select one from the list but it does that
without checking the available flag which can lead to select profiles
not available.
Since the hashmap stores a pointer to the key provided at pa_hashmap_put()
time, it make sense to allow the hashmap to be given ownership of the key and
have it free it at pa_hashmap_remove/free time.
To do this cleanly, we now provide the key and value free functions at hashmap
creation time with a pa_hashmap_new_full. With this, we do away with the free
function that was provided at remove/free time for freeing the value.
This reverts commit a9c3f2fb0f.
It has been recently agreed that ports should somehow have some physical
meaning, leading to the port merge in module-bluetooth-device.
With this assumption in mind, it is very unlikely that a card would
add or remove ports dynamically. Therefore, the core can be simplified
by removing the support for this.
The revert affects the code added to module-card-restore in commit
a1a0ad1af2, which can now be partially
removed.
Conflicts:
src/pulsecore/card.c
src/pulsecore/core.h
Some cards are capable to announce if a specific profile is available or
not, effectively predicting whether a profile switch would fail or would
likely succeed. This can for example be useful for a UI that would gray
out any unavailable profile.
In addition, this information can be useful for internal modules
implementing automatic profile-switching policies, such as
module-switch-on-port-available or module-bluetooth-policy.
In particular, this information is essential when a port is associated
to multiple card profiles and therefore the port availability flag does
not provide enough information. The port "bluetooth-output" falls into
this category, for example, since it doesn't distinguish HSP/HFP from
A2DP.
The previous patch removed module-gconf's dependency on the userdata
pointer of the free callback, and that was the only place where the
userdata pointer of pa_free2_cb_t was used, so now there's no need for
pa_free2_cb_t in pa_hashmap_free(). Using pa_free_cb_t instead allows
removing a significant amount of repetitive code.
In practice there is always at least one profile, and I
don't think there will ever be cards without profiles.
Therefore, I added assertions to pa_card_new() stating that
the card new data must always contain at least one profile.
Now a lot of code can be simplified, because it's guaranteed
that the profiles hashmap and the active_profile field are
always non-NULL.
In my opinion, pa_card_set_profile() should assert that name
is not NULL, and it would be the job of the client interface
to filter out NULLs from the client input, but this is done
this way also when setting sink and source ports, so for
consistency I'll do this this way for now.
This forms the base for being able to expose all ports of all
profiles (even inactive ones) to clients.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
This will allow modules to know when a card profile has changed
and take appropriate action. This might prove useful when developing
UCM so that the appropriate verb can be set.
