From: Mikel Astiz <mikel.astiz@xxxxxxxxxxxx> The sink can be resumed while the source is still in PA_SOURCE_INIT. This is the case if a module such as module-stream-restore routes the audio to the sink during pa_sink_put(), leading to an inconsistent state: the sink stays RUNNING but the transport is not actually acquired. --- This seems to be the less intrusive change to fix the issue reported by Arun. I'm still not very happy about the number of conditions we have while handling sink/source state transitions, which seem overly complex, but let's address that after 3.0. src/modules/bluetooth/module-bluetooth-device.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/modules/bluetooth/module-bluetooth-device.c b/src/modules/bluetooth/module-bluetooth-device.c index dd1bb86..56e32b4 100644 --- a/src/modules/bluetooth/module-bluetooth-device.c +++ b/src/modules/bluetooth/module-bluetooth-device.c @@ -465,7 +465,7 @@ static int sink_process_msg(pa_msgobject *o, int code, void *data, int64_t offse break; /* Resume the device if the source was suspended as well */ - if (!u->source || u->source->state == PA_SOURCE_SUSPENDED) { + if (!u->source || !PA_SOURCE_IS_OPENED(u->source->thread_info.state)) { if (bt_transport_acquire(u, TRUE) < 0) failed = TRUE; } @@ -540,7 +540,7 @@ static int source_process_msg(pa_msgobject *o, int code, void *data, int64_t off break; /* Resume the device if the sink was suspended as well */ - if (!u->sink || u->sink->thread_info.state == PA_SINK_SUSPENDED) { + if (!u->sink || !PA_SINK_IS_OPENED(u->sink->thread_info.state)) { if (bt_transport_acquire(u, TRUE) < 0) failed = TRUE; } -- 1.7.11.7