[pulseaudio-discuss] [PATCH v1 2/8] bluetooth: Check return value of init_profile()
Tanu Kaskinen
tanuk at iki.fi
Thu Oct 18 10:32:52 PDT 2012
On Thu, 2012-10-18 at 10:27 +0200, Mikel Astiz wrote:
> From: Mikel Astiz <mikel.astiz at bmw-carit.de>
>
> If profile could not be successfully initialized, the card should be
> set to PROFILE_OFF automatically. If sinks or sources exist, they need
> to be destroyed, therefore stop_thread() is called.
I agree that the "off" profile should be chosen in case of failure in
init_profile(), but I have a small issue with the implementation. There
will be two nested profile switches going on at the same time (there's
the original switch, and "inside" that there's the switch to "off"). I
think that's a bit ugly. I would guess that there wouldn't be much
practical problems, though, so I'm ok with this patch if you don't want
to implement the following proposal:
Cards could designate one profile as the "fallback" profile.
pa_card_set_profile() would work so that if the set_profile() callback
fails, then the card is switched to the fallback profile (and this
profile switch must not fail - the fallback profile is supposed to be
one that can always be switched to, no matter what).
This would allow us also to add a hook between the initial set_profile()
call and the fallback activation - some policy module might want to
catch the profile switch failure, and override the fallback profile to
something else. That's not very relevant now, but I think it will be
relevant with any priority list based routing.
> + if (pa_card_set_profile(u->card, "off", FALSE) < 0)
> + pa_log_debug("Failed to switch profile to off");
I think this should be:
pa_assert_se(pa_card_set_profile(u->card, "off", false) >= 0);
Activating the "off" profile can't fail, as far as I can see.
--
Tanu
More information about the pulseaudio-discuss
mailing list