[pulseaudio-discuss] don't stop_stream_fd when suspending sink/source in bluetooth-device module

Lennart Poettering lennart at poettering.net
Tue Jun 30 07:26:41 PDT 2009


On Thu, 25.06.09 16:46, Bu, Long (long.bu at intel.com) wrote:

> Now the suspend call back will call stop_stream_fd(u) which will
> send BT_STOP_STREAM command. This eventually causes some connected devices(I tested with DELL BH200 and Motorola HT800) to disconnect.(BlueZ asks connected devices to disconnect audio link only but some devices actually disconnect the RFComm link also).  And you can not use the Bluetooth anymore without reconnecting it. The module-bluetooth-device also gets unloaded
> 
> The benefit of stop_stream_fd when suspending is to save some power
> for HSP/HFP case since communication on sco link occurs even there
> is no audio data. But for some devices that disconnect on
> BT_STOP_STREAM, it really brings some bad use experience.
> 
> So I think it's good to remove stop_stream_fd for now as in the
> attached patch.

Hmm. I discussed this now with the bluez folks. They suggest that this
is the wrong approach. BT_STOP_STREAM is intended to be used in cases
like this, and that they in fact got complaints when they weren't
suspending the headsets but sending silence instead.

So, uh. Not sure what to do about this.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4



More information about the pulseaudio-discuss mailing list