[pulseaudio-discuss] [PATCH v0] bluetooth: Fix unacquired transports during sink resume

[Mikel Astiz]

Hi Tanu,

On Tue, Dec 4, 2012 at 1:43 AM, Tanu Kaskinen <tanuk at iki.fi> wrote:
> On Mon, 2012-12-03 at 10:57 +0100, Mikel Astiz wrote:
>> On Sun, Dec 2, 2012 at 4:05 AM, Tanu Kaskinen <tanuk at iki.fi> wrote:
>> > On Thu, 2012-11-29 at 14:33 +0100, Mikel Astiz wrote:
>> >> On Thu, Nov 29, 2012 at 4:55 AM, Tanu Kaskinen <tanuk at iki.fi> wrote:
>> >> > so that INIT->IDLE transitions will work too, if we decide some day that
>> >> > it's not a good idea to start the devices suspended. (I think it makes
>> >> > sense to start them suspended, but relying on module-suspend-on-idle for
>> >> > unsuspending is not good.)
>> >>
>> >> INIT->IDLE should already be working, since in this case the transport
>> >> is acquired before the thread is started. I just sent two patches
>> >> that would do this for headsets, since Arun was
>> >> also concerned about relying on the presence of
>> >> module-suspend-on-idle.
>> >
>> > Would the acquire in setup_transport() be necessary at all if the
>> > transport would be acquired in the PA_SINK_MESSAGE_SET_STATE handler
>> > also for the INIT->IDLE transition?
>>
>> I believe that the acquire would always be necessary in
>> setup_transport(), since this is the only way to find out which the
>> initial state of the sink/sources should be.
>
> The initial state should always be IDLE for headsets, so in that case
> there's nothing to decide, right? (Until the suspend-on-idle interaction
> gets sorted out, that is.) For a2dp_source/hfgw, couldn't you figure out
> the initial sink/source state from the bluetooth stream state instead of
> checking whether the transport has been acquired? If the stream is not
> playing, start suspended.

The issue is indeed about a2dp_source/hfgw.

The problem with checking the state before you acquire is that it's
racy: by the time you reach MESSAGE_SET_STATE (or even worse, the
BlueZ daemon) the state might have already changed. So the only real
way to confirm that the audio is streaming by acquiring.

This is not a strong argument for BlueZ 4.x since the D-Bus API does
not support such atomic test&set acquisitions (optional acquire).
That's why we have a FIXME in bt_transport_acquire(), where a similar
behavior is simulated but is still racy. However, this has already
been fixed for BlueZ 5 so I would suggest we continue with this
approach, so we don't have to move more code around in the near
future.

Cheers,
Mikel