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
