[FFE] Enable the Source and Gateway audio profiles in bluez by default

[Mathieu Trudel-Lapierre]

The Source and Gateway profiles should be enabled in bluez's /etc/bluetooth/audio.conf.

These profiles allow for the systems bluetooth daemon to advertise itself as an A2DP and HSP/HFP sink; which allows using the system as an output device for A2DP (stereo sound) output (having sound from phone -> computer for instance), and as an output device/control endpoint/headset in the HSP/HFP profile (thus allowing support for answering calls from a phone on the computer, for instance, and playing mono audio streams).

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: bluez 4.98-2ubuntu1
ProcVersionSignature: Ubuntu 3.2.0-17.27-generic 3.2.6
Uname: Linux 3.2.0-17-generic x86_64
ApportVersion: 1.94-0ubuntu1
Architecture: amd64
Date: Tue Mar 6 20:06:35 2012
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Alpha amd64 (20120209.2)
InterestingModules: bnep rfcomm btusb bluetooth
MachineType: Dell Inc. Vostro V131
ProcEnviron:
 LANGUAGE=fr_CA:fr
 TERM=xterm
 PATH=(custom, user)
 LANG=fr_CA.UTF-8
 SHELL=/bin/zsh
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.2.0-17-generic root=/dev/mapper/hostname-root ro quiet splash vt.handoff=7
SourcePackage: bluez
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 10/24/2011
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A03
dmi.board.name: 0C06WP
dmi.board.vendor: Dell Inc.
dmi.board.version: A03
dmi.chassis.type: 8
dmi.chassis.vendor: Dell Inc.
dmi.chassis.version: Not Specified
dmi.modalias: dmi:bvnDellInc.:bvrA03:bd10/24/2011:svnDellInc.:pnVostroV131:pvrNotSpecified:rvnDellInc.:rn0C06WP:rvrA03:cvnDellInc.:ct8:cvrNotSpecified:
dmi.product.name: Vostro V131
dmi.product.version: Not Specified
dmi.sys.vendor: Dell Inc.
hciconfig:
 hci0: Type: BR/EDR Bus: USB
  BD Address: AC:72:89:85:33:3C ACL MTU: 310:10 SCO MTU: 64:8
  UP RUNNING PSCAN ISCAN
  RX bytes:874 acl:0 sco:0 events:39 errors:0
  TX bytes:896 acl:0 sco:0 commands:38 errors:0
modified.conffile..etc.bluetooth.audio.conf: [modified]
mtime.conffile..etc.bluetooth.audio.conf: 2012-03-06T12:36:54.993530

[Mathieu Trudel-Lapierre (cyphermox)]

These profiles are already pretty stable and mature, and seem to be relatively often suggested to be enabled for the audio support cases in the original description. Seems like it's pretty low risk as using these profiles still requires some additional manual work of configuring pulseaudio streams to take them into account, for instance.

[Mathieu Trudel-Lapierre (cyphermox)]

Seems like the better idea to enable these profiles in code directly as a patch, and keep the audio.conf configuration file as the way to override these settings.

[Martin Pitt (pitti)]

Hello Mathieu,

I have some questions about this:

Does enabling it in the configuration file automatically activate the bluetooth adapter all the time, or will that only get active once you actually pair with a device? In other words, does this have an effect on the power consumption if the computer is not paired?

I guess the most common case for this are mobile phones. Has this been tested with an Android and an iPhone, to make sure that it at least works on the most popular devices? How much testing coverage did this get?

Thanks!

[Mathieu Trudel-Lapierre (cyphermox)]

No, there is still the need to be paired with a device for the device to be activated (i.e. not idle, drawing more power than if it's normally enabled but not paired with anything).

This is just a change to the profiles that are seen by other devices as available on the system; so that the system will then also appear as a headset capable of stereo.

There's a slight catch to it though: if the external device has bluetooth enabled and the pairing was previously done, the device might try to automatically pair again with the system. This will enable a connection and potentially use more power. I've tested this with my own Android phone; I unfortunately don't have an iPhone to test this with (but it's a valid test).

[Martin Pitt (pitti)]

So by default there is no change in the power usage, and once you paired with another BT device using your computer as an audio sink, it's actually the right thing to do to reconfigure that once the device pairs again. Thanks for the clarification!

Please go ahead then, and send a call for testing so that we can make sure that this also works with iOS clients.

[Launchpad Janitor (janitor)]

This bug was fixed in the package bluez - 4.98-2ubuntu2

---------------
bluez (4.98-2ubuntu2) precise; urgency=low

  * debian/patches/enable_audio_profiles.patch: enable the Gateway and Source
    audio profiles by default. (LP: #948613)
 -- Mathieu Trudel-Lapierre <email address hidden> Wed, 07 Mar 2012 10:44:35 -0500

[Steve Langasek (vorlon)]

On Wed, Mar 07, 2012 at 06:02:51AM -0000, Martin Pitt wrote:
> I guess the most common case for this are mobile phones. Has this been
> tested with an Android and an iPhone, to make sure that it at least
> works on the most popular devices? How much testing coverage did this
> get?

It's certainly been tested with Android. I don't have an iPhone, but I
don't think testing this should be a prerequisite, as bluetooth is designed
to give full control over which profiles are paired or not. So there may be
a one-time behavior change as seen from the phone that users will need to
address, but nothing that would rightfully be considered a bug anyway.

At a minimum, we should reconcile the comment in the config file with the
behavior. I think the better way to do that is to make the current comment
correct (so that these profiles are all enabled by default), but if that's
not acceptable, we should fix the comment to reflect reality.

[DarkStarSword (darkstarsword)]

Was this regression tested? That patch made it's way into Debian where it broke A2DP headphones:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%23724735

I haven't tested the Ubuntu package so I can't really comment on whether it broke Ubuntu as well, or if Ubuntu has some other piece we are missing in Debian that makes it work.

> I don't think testing this should be a prerequisite

... !!!!

[Steve Langasek (vorlon)]

On Mon, Oct 14, 2013 at 11:39:01PM -0000, DarkStarSword wrote:
> > I don't think testing this should be a prerequisite

Nice selective quoting.

[Mathieu Trudel-Lapierre (cyphermox)]

Yes, this was tested and it was working and not causing regressions, otherwise it would not have been uploaded. It is possible that things are broken now due to changes upstream -- that particular section of code has changed quite a lot recently.

[Ｖ字龍(Vdragon) (vdragon)]

Hi,
AFAICS this patch has caused bug 1199059 , please check it out if it's related, thanks!