Hello,
I am working with an embedded device which has a Marvell 8688 based
bluetooth chip. We would like to use an external headset, but rather
than have the audio be transmitted over the HCI layer, we'd like it to
be sent directly out the PCM lines from the bluetooth chip, thus Linux
really doesn't see any audio data, but is responsible for setting up the
link/keys/authentication etc...
Are there any instructions on how to go about this? I've had a quick
look around, and this doesn't seem to be a particularly popular
configuration.
Regards,
Andre
Hi Andre,
On Fri, Sep 02, 2011, Andre Renaud wrote:
> Another issue I'm trying to get my head around, is that the system I'm
> working on doesn't have audio attached to the CPU. The PCM lines are
> going to an external FPGA which is entirely independent. So the Linux
> kernel has no Alsa drivers, and no audio codec. Due to space limitations
> of the filesystem, subsystems like PulseAudio are probably not going to
> be available.
I suppose you still have *some* component in the system which knows
about the need for a SCO link? All you'd need is to have this component
register an endpoint through the BlueZ Media API and have it request the
SCO link whenever you need it. Luiz already pointed out in his email the
test/simple-endpoint script which should give you some idea of what to
do. When there's a HFP or HSP connection you'll get the D-Bus object
path of the media transport object through the SetConfiguration callback
of the endpoint you registered and then you can call the Acquire method
that the transport object provides to get the actual SCO link.
> I think this essentially comes down to vendor specific HCI writes to
> toggle the audio path, but I'm not sure if I have a full understanding
> of how it all works.
>
> Can anyone tell me how they went about setting up an audio connection
> with an Bluetooth headset, and then configured the audio to go over the
> PCM channel?
The PCM routing part will always be hardware dependent. So what someone
else did won't necessarily help you much unless they had the exact same
hardware as you. If the setting isn't hard-coded in the controller you'd
typically set it through some vendor-dependent command during the
initialization phase.
Johan
Hi Brad,
On Thu, Sep 1, 2011 at 6:31 PM, Brad Midgley <[email protected]> wrote:
> Johan,
>
>> If your system uses PulseAudio you're in luck since it has built-in
>> support for this. However, pulse expects the kernel to provide an ALSA
>> device abstraction for the PCM hardware link to the Bluetooth
>> controller. You can tell the bluetooth-device module the name of this
>> special ALSA device through the sco_sink and sco_source parameters.
>
> Are you aware of anyone who has put these pieces together in something
> that we can look at? I've seen discussed what it would look like a
> couple of times but not specifics yet.
MeeGo harmattan use sco_sink and sco_source, passed to PA bluetooth
module, instead of the socket/HCI routing. What I think we could have
been done is somehow require the driver to tag alsa device properly so
we can automatically detect and route the audio properly without
having to hardcode the alsa device in sco_sink/sco_source.
> I see the doc/media-api.txt. Are there tests or examples of the
> minimal media calls to make sco connection monitoring work?
We can probably use the capabilities of the endpoint to set the
routing so PA do the detections, actually I guess this could probably
remove any need to have the audio routing hardcoded in audio.conf. For
the media/endpoint you can play around with test/simple-endpoint to
automatically acquire the transport when configured.
--
Luiz Augusto von Dentz
Hi Johan,
On 01/09/11 19:24, Johan Hedberg wrote:
> It might not be common on Linux PC's but most embedded systems (e.g.
> phones) running Linux/BlueZ use PCM routing. Essentially your audio
> subsystem needs to "know" that PCM routing is in place and that the SCO
> socket received over the (now deprecated) audio unix socket interface or
> the (new) Media interface isn't much more than a /dev/null (it's
> a bit more useful than that since it lets the audio subsystem know that
> there's a SCO connection and allows monitoring its lifetime through
> POLLHUP/POLLERR).
>
> If your system uses PulseAudio you're in luck since it has built-in
> support for this. However, pulse expects the kernel to provide an ALSA
> device abstraction for the PCM hardware link to the Bluetooth
> controller. You can tell the bluetooth-device module the name of this
> special ALSA device through the sco_sink and sco_source parameters.
Another issue I'm trying to get my head around, is that the system I'm
working on doesn't have audio attached to the CPU. The PCM lines are
going to an external FPGA which is entirely independent. So the Linux
kernel has no Alsa drivers, and no audio codec. Due to space limitations
of the filesystem, subsystems like PulseAudio are probably not going to
be available.
I think this essentially comes down to vendor specific HCI writes to
toggle the audio path, but I'm not sure if I have a full understanding
of how it all works.
Can anyone tell me how they went about setting up an audio connection
with an Bluetooth headset, and then configured the audio to go over the
PCM channel?
Regards,
Andre
Johan,
> If your system uses PulseAudio you're in luck since it has built-in
> support for this. However, pulse expects the kernel to provide an ALSA
> device abstraction for the PCM hardware link to the Bluetooth
> controller. You can tell the bluetooth-device module the name of this
> special ALSA device through the sco_sink and sco_source parameters.
Are you aware of anyone who has put these pieces together in something
that we can look at? I've seen discussed what it would look like a
couple of times but not specifics yet.
I see the doc/media-api.txt. Are there tests or examples of the
minimal media calls to make sco connection monitoring work?
--
Brad Midgley
Hi Andre,
On Thu, Sep 01, 2011, Andre Renaud wrote:
> I am working with an embedded device which has a Marvell 8688 based
> bluetooth chip. We would like to use an external headset, but rather
> than have the audio be transmitted over the HCI layer, we'd like it to
> be sent directly out the PCM lines from the bluetooth chip, thus Linux
> really doesn't see any audio data, but is responsible for setting up the
> link/keys/authentication etc...
>
> Are there any instructions on how to go about this? I've had a quick
> look around, and this doesn't seem to be a particularly popular
> configuration.
It might not be common on Linux PC's but most embedded systems (e.g.
phones) running Linux/BlueZ use PCM routing. Essentially your audio
subsystem needs to "know" that PCM routing is in place and that the SCO
socket received over the (now deprecated) audio unix socket interface or
the (new) Media interface isn't much more than a /dev/null (it's
a bit more useful than that since it lets the audio subsystem know that
there's a SCO connection and allows monitoring its lifetime through
POLLHUP/POLLERR).
If your system uses PulseAudio you're in luck since it has built-in
support for this. However, pulse expects the kernel to provide an ALSA
device abstraction for the PCM hardware link to the Bluetooth
controller. You can tell the bluetooth-device module the name of this
special ALSA device through the sco_sink and sco_source parameters.
Johan