[pulseaudio-discuss] [PATCH v0 3/5] bluetooth: Do not switch to profile unless Playing

[Mikel Astiz]

Hi Tanu,

On Wed, Jul 25, 2012 at 7:07 PM, Tanu Kaskinen <tanuk at iki.fi> wrote:
> On Fri, 2012-07-06 at 11:19 +0200, Mikel Astiz wrote:
>> From: Mikel Astiz <mikel.astiz at bmw-carit.de>
>>
>> If no audio stream exists to the remote device during discovery,
>> setting the profile to hfgw or a2dp_source would request it. This is
>> something that should not be done automatically.
>
> I've asked this already from someone else, but didn't get an answer: is
> it possible at all to initiate A2DP streaming from the receiving end?
>
> Out of curiosity, if it's possible to initiate streaming also from the
> receiving end, how does pulseaudio behave when it's the sending end and
> the A2DP receiver says that "start playing"? Does it work, if the
> currently active profile in pulseaudio is already a2dp? Does it work, if
> the currently active profile in pulseaudio is not a2dp? I'd guess it
> doesn't work automatically in that case, but do things go smoothly if
> you change the profile manually after the play request has arrived?

The terms sending-end and receiving-end are a bit confusing since
PulseAudio can have both A2DP roles, sink and source. I'm more
familiar with the Sink role (PA is the receiving end) but I think the
pattern is similar.

So (I hope) answering to your question: yes, the remote end can also
start playing.

AFAIK the way this is modelled in PulseAudio is not very consistent,
specially if you consider also HFP.

Regarding the card state, I would propose that the implication is
one-way: if the profile is set to a2dp, the stream needs to be
playing. Not necessarily the other way round: even if the stream is
playing, the profile could be set to off, for example, or hfp.

This would mean that, if the profile was off and you manually switch
to a2dp, the stream should start playing.

Currently (and IMO incorrectly) module-bluetooth-device and
module-bluetooth-discover include some policies to handle the initial
state and the transitions. This needs to be revisited though: my
proposal would be to move all policies outside these modules (so no
automatic profile switching), and use the port availability flags to
expose which streams are playing (and thus the profile should probably
be switched accordingly, but from some other policy module).

I'm not sure if I answered to your question.

Cheers,
Mikel