Hello,
I'm trying to get a bluetooth headset working on an embedded Linux
environment. I don't have the available resources to drag in all of
Pulse Audio, so this is being done with essentially just bluez
and the alsa-libs.
It all seems to connect & pair properly, but when I go to play audio
no sound comes out. There are no complaints, and the 'aplay' command
runs for approximately the correct amount of time before exiting
cleanly. Using hcidump, I can see that the audio data is being
transmitted.
In the process of investigating this, I found that the amixer command
was unable to talk to the bluetooth controls. I eventually tracked
this down to a bug in audio/ctl_bluetooth.c. Having fixed it,
I am now able to list the controls, but unable to change their values
(I have also made it so that it errors out if it goes to change
an integer, and the change doesn't take, rather than looping forever).
Does anyone know what I might be missing, or where I should start
looking next?
Regards,
Andre
--- a/audio/ctl_bluetooth.c 2011-07-13 15:53:11.000000000 +1200
+++ b/audio/ctl_bluetooth.c 2011-07-13 16:27:04.000000000 +1200
@@ -156,7 +156,7 @@
req->mode = mode;
req->key = key;
- ret = send(data->sock, req, BT_SUGGESTED_BUFFER_SIZE, MSG_NOSIGNAL);
+ ret = send(data->sock, req, sizeof(*req), MSG_NOSIGNAL);
if (ret <= 0) {
SYSERR("Unable to request new volume value to server");
return -errno;
@@ -225,7 +225,7 @@
struct bluetooth_data *data = ext->private_data;
char buf[BT_SUGGESTED_BUFFER_SIZE];
struct bt_control_rsp *rsp = (void *) buf;
- long current;
+ long current, new;
int ret, keyvalue;
DBG("ext %p key %ld", ext, key);
@@ -245,7 +245,16 @@
if (ret < 0)
break;
- current = keyvalue;
+ ret = bluetooth_read_integer(ext, key, &new);
+ if (ret < 0)
+ return ret;
+
+ if (new == current) {
+ SNDERR("Unable to move volume %s",
+ keyvalue == BT_CONTROL_KEY_VOL_UP ? "up" : "down");
+ return -EAGAIN;
+ }
+ current = new;
}
return ret;
Hi Johan,
> You can use whatever audio subsystem you like as long as it can hook up
> to the interface that BlueZ provides. The Media API itself hasn't been
> designed for any specific audio subsystem as such, but PulseAudio
> support for it was developed in parallel so it's what probably works
> best right now. And as I said, if you really need something else, such
> as ALSA user space plugins, feel free to take on the effort to port them
> to the Media API. The only reason they're about to get dropped is that
> no-one has shown the interest and resources to port them over and it
> doesn't make sense to keep maintaining two parallel API's (the old unix
> socket based and the new D-Bus based Media API). Btw, I also hope that
> you've done some proper study to conclude that PulseAudio doesn't suit
> your needs and are not just going on a "hunch" about it.
Thanks for that. Can you tell me if there are any other upper layer
systems that support the Media API?
Regarding the usage of pulse audio, our primary restriction at the
moment is disk space, so minimising the number of libraries used is of
great importance. We only have 8MB available on the final system, so as
you can imagine bringing in large libraries is not always possible. The
study you mention is what we're conducting at the moment. I'd welcome
any alternatives that you can suggest. Given what has been discussed so
far, we are currently doing further investigation into using PulseAudio.
Regards,
Andre
Hi Andre,
On Thu, Jul 14, 2011, Andre Renaud wrote:
> On 13/07/11 20:09, Johan Hedberg wrote:
> > Regarding the other issues, unfortunately I can't really help you there.
> > I've never really looked into these ALSA user-space plugins in detail.
> > It's not a big surprise though that it doesn't work: it seems like the
> > last time ctl_bluetooth.c got major changes was back in 2007 (i.e.
> > no-one seems to have had much interest in maintaining it since then).
> >
> > You should also know that unless someone puts effort into adding support
> > for the D-Bus Media API (doc/media-api.txt) then pcm_bluetooth.c and
> > ctl_bluetooth.c will be removed in the BlueZ 5.0 release along with the
> > pure unix socket based interface for audio.
>
> Can you confirm for me then that Pulse Audio is the only real supported
> mechanism for getting Bluetooth headsets to work under Linux? If support
> for the ctl/pcm bluetooth modules is about to be dropped, I'm pretty
> sure we're not going to want to start out with that mechanism.
You can use whatever audio subsystem you like as long as it can hook up
to the interface that BlueZ provides. The Media API itself hasn't been
designed for any specific audio subsystem as such, but PulseAudio
support for it was developed in parallel so it's what probably works
best right now. And as I said, if you really need something else, such
as ALSA user space plugins, feel free to take on the effort to port them
to the Media API. The only reason they're about to get dropped is that
no-one has shown the interest and resources to port them over and it
doesn't make sense to keep maintaining two parallel API's (the old unix
socket based and the new D-Bus based Media API). Btw, I also hope that
you've done some proper study to conclude that PulseAudio doesn't suit
your needs and are not just going on a "hunch" about it.
Johan
Hi Johan,
On 13/07/11 20:09, Johan Hedberg wrote:
> Regarding the other issues, unfortunately I can't really help you there.
> I've never really looked into these ALSA user-space plugins in detail.
> It's not a big surprise though that it doesn't work: it seems like the
> last time ctl_bluetooth.c got major changes was back in 2007 (i.e.
> no-one seems to have had much interest in maintaining it since then).
>
> You should also know that unless someone puts effort into adding support
> for the D-Bus Media API (doc/media-api.txt) then pcm_bluetooth.c and
> ctl_bluetooth.c will be removed in the BlueZ 5.0 release along with the
> pure unix socket based interface for audio.
Can you confirm for me then that Pulse Audio is the only real supported
mechanism for getting Bluetooth headsets to work under Linux? If support
for the ctl/pcm bluetooth modules is about to be dropped, I'm pretty
sure we're not going to want to start out with that mechanism.
Regards,
Andre
Hi Andre,
On Wed, Jul 13, 2011, Andre Renaud wrote:
> I'm trying to get a bluetooth headset working on an embedded Linux
> environment. I don't have the available resources to drag in all of
> Pulse Audio, so this is being done with essentially just bluez
> and the alsa-libs.
>
> It all seems to connect & pair properly, but when I go to play audio
> no sound comes out. There are no complaints, and the 'aplay' command
> runs for approximately the correct amount of time before exiting
> cleanly. Using hcidump, I can see that the audio data is being
> transmitted.
>
> In the process of investigating this, I found that the amixer command
> was unable to talk to the bluetooth controls. I eventually tracked
> this down to a bug in audio/ctl_bluetooth.c. Having fixed it,
> I am now able to list the controls, but unable to change their values
> (I have also made it so that it errors out if it goes to change
> an integer, and the change doesn't take, rather than looping forever).
>
> Does anyone know what I might be missing, or where I should start
> looking next?
About your patch, could you please send something that can be fed to
"git am". Typically git format-patch + git send-email should be enough
for this. Before that however, fix your code indentation. The BlueZ
coding style is to use *only* tabs whereas what you sent uses spaces.
Regarding the other issues, unfortunately I can't really help you there.
I've never really looked into these ALSA user-space plugins in detail.
It's not a big surprise though that it doesn't work: it seems like the
last time ctl_bluetooth.c got major changes was back in 2007 (i.e.
no-one seems to have had much interest in maintaining it since then).
You should also know that unless someone puts effort into adding support
for the D-Bus Media API (doc/media-api.txt) then pcm_bluetooth.c and
ctl_bluetooth.c will be removed in the BlueZ 5.0 release along with the
pure unix socket based interface for audio.
Johan