[pulseaudio-discuss] How to change profile of bluetooth headset for different applications?

[Colin Guthrie]

'Twas brillig, and Tanu Kaskinen at 26/05/11 13:08 did gyre and gimble:
> On Mon, 2011-05-23 at 18:18 +0100, Colin Guthrie wrote:
>> How about this:
>>
>> Define a new card property similar in concept to
>> PA_PROP_DEVICE_INTENDED_ROLES ("device.intended_roles") called
>> PA_PROP_DEVICE_INTENDED_PROFILE ("device.intended_profile").
>>
>> In bluetooth device, when loading a headset that has both HSP and A2DP,
>> populate the device with the following code:
>>
>> if (supports_hsp && supports_a2dp)
>> {
>>   char *k;
>>
>>   k = pa_sprintf_malloc("%s.%s", PA_PROP_DEVICE_INTENDED_PROFILE, "music");
>>   pa_proplist_sets(card_data.proplist, k, "a2dp");
>>   pa_xfree(k);
>>
>>   k = pa_sprintf_malloc("%s.%s", PA_PROP_DEVICE_INTENDED_PROFILE, "video");
>>   pa_proplist_sets(card_data.proplist, k, "a2dp");
>>   pa_xfree(k);
>>
>>   k = pa_sprintf_malloc("%s.%s", PA_PROP_DEVICE_INTENDED_PROFILE, "phone");
>>   pa_proplist_sets(card_data.proplist, k, "hsp");
>>   pa_xfree(k);
>> }
>>
>> This should result in "pacmd list-cards" dumping a proplist that includes:
>>
>>  device.intended_profile.music = a2dp
>>  device.intended_profile.video = a2dp
>>  device.intended_profile.phone = hsp
>>
>>
>>
>> Then a separate module (module-intended-profiles?) could take care of
>> listening quite generically for streams landing on sink and do the
>> following logic:
>>
>>
>> if (!si->sink || !si->sink->card)
>> 	return PA_HOOK_OK;
>>
>> char *role = pa_proplist_gets(si->proplist, PA_PROP_MEDIA_ROLE);
>> if (!role)
>> 	return PA_HOOK_OK;
>>
>> char *k = pa_sprintf_malloc("%s.%s", PA_PROP_DEVICE_INTENDED_PROFILE, role);
>> pa_card *card = si->sink->card;
>> char *profile = pa_proplist_gets(card->proplist, k);
>> pa_xfree(k);
>> if (!profile)
>> 	return PA_HOOK_OK;
>>
>> if (!pa_streq(card->active_profile, profile)) {
>>    /* Save the current profile for later restoration */
>>    ...
>>
>>    if (pa_card_set_profile(card, profile, FALSE) < 0)
>>    /* Find the sink of this card as the above call will likely have
>> changed it */
>>    sink = pa_idxset_first(card->sinks, NULL);
>>
>>    pa_sink_input_move_to(si, sink, FALSE);
>> }
>>
>>
>> This code is then completely generic. I'm not 100% sure how well this
>> will work in practice as there may be some nasty races etc. but I think
>> this general approach could work... Perhaps others (i.e. Tanu :D) have
>> better suggestions?
> 
> If the priority lists would exist already, the module deciding the
> routing could examine the stream properties and pick the sink+port with
> the highest priority that can be made available - if the sink+port isn't
> immediately available, but can be made available, then the routing
> module would change the profile and port as needed.

Cool, sounds good to me.

> But the priority lists are not available. I believe the logic that you
> propose is otherwise good, except that I don't see how the stream could
> "land" on the bluetooth (a2dp) sink automatically on phone calls.
> module-bluetooth-device tags only hsp sinks with the phone tag, not a2dp
> sinks, so module-intended-roles can't do the required magic. If the hsp
> sink doesn't exist because the a2dp profile is selected, I don't think
> there's currently any logic to route the stream to the bluetooth sink.
> If, however, by some magic the phone stream would be routed to the a2dp
> sink, then I think your proposal would work fine.

Some of Amanda's earlier emails on this list were about other modules
tweaks (namely to switch-on-connect) to force the use of the bluetooth
device more strongly that module-intended-roles currently does, so I
suspect that the "making the stream use the bluetooth device in any
mode" problem is already solved for them.


> For better suggestions, I don't think I have any. Except that use the
> policy framework - Lin posted from an intel.com address, so I assume he
> or she (sorry, I don't know Chinese names) is working on Meego, and I've
> thought that Meego got the policy framework from Maemo. In Maemo the
> routing is handled by module-policy-enforcement (which gets the command
> to enable the bluetooth-hsp routing mode from the policy framework), and
> it works pretty nicely for this kind of use cases.

Interesting, thanks for the info. It's kinda hard to keep up to date
with branches that I don't actively follow :)

Cheers

Col



-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]