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

Dalleau, Frederic frederic.dalleau at intel.com
Fri Sep 21 05:00:10 PDT 2012


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

Regards,
Frédéric


More information about the pulseaudio-discuss mailing list