[pulseaudio-discuss] [PATCH v0] bluetooth: Fix unacquired transports during sink resume
tanuk at iki.fi
Mon Dec 3 16:43:57 PST 2012
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.
More information about the pulseaudio-discuss