[pulseaudio-discuss] [PATCH v0 09/16] bluetooth: Move streams during shutdown

[Mikel Astiz]

Hi Tanu,

On Wed, Oct 17, 2012 at 3:29 PM, Tanu Kaskinen <tanuk at iki.fi> wrote:
> On Mon, 2012-10-15 at 04:28 +0200, Mikel Astiz wrote:
>> Hi Tanu,
>>
>> On Sun, Oct 14, 2012 at 6:47 PM, Tanu Kaskinen <tanuk at iki.fi> wrote:
>> > On Fri, 2012-09-28 at 17:45 +0200, Mikel Astiz wrote:
>> >> From: Mikel Astiz <mikel.astiz at bmw-carit.de>
>> >>
>> >> If sink and sources exist during shutdown, the streams need to be moved
>> >> exactly as when the profile is being set to off.
>> >
>> > Why? I thought that moving streams during profile change is done because
>> > it's supposedly a good policy to keep the streams at the same device
>> > before and after a profile switch. That doesn't apply during device
>> > unload, so am I missing the real purpose for the moving, or is this
>> > patch unnecessary?
>>
>> This might be a lack of knowledge from my side about stream moving.
>>
>> What I understood from the code (specially from the bluetooth module)
>> is that the modules needed to report the core that something should be
>> done with these streams, and then routing policies would apply
>> (possibly implemented in some other policy module).
>
> No, there's no need to report that something needs to be done with the
> streams. That information is already available through the sink unlink
> hook - when a sink is about to get unlinked, policy modules can react to
> that in some way. An example of that is module-rescue-streams, which
> moves the streams somewhere.
>
> module-rescue-streams does not, however, implement the same policy as
> what module-bluetooth-device does currently. The sink/source of the new
> profile is not yet created when the sink/source of the old profile is
> unlinked, and module-rescue-streams has no idea that the "right"
> sink/source will appear soon, so it moves the streams away from the
> bluetooth device.

OK, I understand now. So the moving was probably there to handle
HSP<->A2DP transitions for headset use-cases. I doubt however if this
is really needed, assuming the routing policies would be able to route
the audio independently from where it was routed before.

Luiz, do you recall why this moving has been implemented?

> If it's deemed necessary, module-bluetooth-policy could react to the
> profile change events and do what module-bluetooth-device is currently
> doing internally.

I wonder if PA has the necessary hooks to implement this, since
SINK_HOOK_UNLINK wouldn't have enough information about the new card
profile. Perhaps the core would need to be extended with something
like HOOK_SET_CARD_PROFILE_START/_FINISH?

For the moment, unless someone points out a good reason to have such a
policy, I will submit another patchset including the removal of this
stream-moving code.

Cheers,
Mikel