Hi Mikel, On Wed, Oct 17, 2012 at 8:17 PM, Mikel Astiz <mikel.astiz.oss at gmail.com> wrote: > 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? Nope, in fact it might exist since the very beginning where things like module-rescue-streams did not exist. >> 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 -- Luiz Augusto von Dentz
