[pulseaudio-discuss] [PATCH v2 0/3] Suspending loopback

[Mikel Astiz]

Hi,

On Fri, Sep 21, 2012 at 2:00 PM, Dalleau, Frederic
<frederic.dalleau at intel.com> wrote:
> Hi Tanu,
>
> On Fri, Sep 21, 2012 at 10:01 AM, Tanu Kaskinen <tanuk at iki.fi> wrote:
>> On Thu, 2012-09-20 at 17:41 +0200, Dalleau, Frederic wrote:
>>> Note that there is still the problem that module-suspend-on-idle do
>>> not suspend the source.
>>> I'm wondering if the source-output can be tagged so that
>>> module-suspend-on-idle does not take it into account,
>>> I have seen the following flags
>>> PA_SOURCE_OUTPUT_DONT_INHIBIT_AUTO_SUSPEND, could this work?
>>
>> I don't think that's a good idea. If you're looping back the audio from
>> a bluetooth source to an alsa sink, and the loopback source output is
>> the only stream using the bluetooth source, then the flag would cause
>> the bluetooth source to get suspended even though there's still audio
>> coming from the bluetooth source that you want to go to the alsa sink.
>>
>> Was the scenario that the audio stops at the bluetooth level due to the
>> stream state changing from "playing" to "connected"? In this case you
>> would want the source to suspend itself. Couldn't this logic be added to
>> module-bluetooth-policy? Or even to module-bluetooth-device - the source
>> is pretty useless in the "connected" state, so I think nobody will
>> complain if it's always suspended in the "connected" state.
>
> In fact, I'm pressing pause in the media player on the phone.
> So stream socket is still connected, but no audio is flowing. The
> sink-input keeps
> saying "could not peek into queue". And after I press play again, I got
> "Requesting rewind due to end of underrun".
> Now that I say that, I just remember that an A2DP message called
> suspend is sent by the phone.
> And start when the play button is pressed again.
> Need to look more in depth

If I get this right, the issue has been addressed by my patchset
"Revisiting Bluetooth modules".

If any of the two ends (source or sink) wants to suspend the audio,
they can jut suspend the sink or source (PA_SUSPEND_USER), which would
trigger an a2dp suspend command leading to the suspension on both
sides.

Suspending on idle would make sense only for the source role, not only
for A2DP but also for HSP/HFP (see patch v2 20/22). If someone wanted
to do something more complex, the loopback policy in
module-bluetooth-policy would have to be disabled.

Cheers,
Mikel