Android bluetooth and ALSA plugin interaction
alex petrov
I saw Android 2.3's source and can't understand where and how Android
loads ALSA plugin libasound_module_ctl_bluetooth.la ?
I can see ALSA configure file bluetooth.conf:
pcm.rawbluetooth {
@args [ ADDRESS ]
@args.ADDRESS {
type string
}
type bluetooth
device $ADDRESS
}
pcm.bluetooth {
@args [ ADDRESS ]
@args.ADDRESS {
type string
}
type plug
slave {
pcm {
type bluetooth
device $ADDRESS
}
}
}
But I can't understand who uses this file to configure ALSA.
When HSP/HFP connection had established class BluetoothHandsfree calls
methods of AudioManager like setParameters, setBluetoothScoOn
Does AudioManager configure ALSA ?
Pavan Savoy
> I'm bluetooth developer and now works with Android/bluez BT.
> I saw Android 2.3's source and can't understand where and how Android
> loads ALSA plugin libasound_module_ctl_bluetooth.la ?
> I can see ALSA configure file bluetooth.conf:
ALSA plugin isn't used in Bluetooth on Android.
There is a seperate liba2dp.c which does what alsa plugin does.
So the liba2dp.so needs to be loaded, which links to the A2dpAudioInterface
>
> pcm.rawbluetooth {
> @args [ ADDRESS ]
> @args.ADDRESS {
> type string
> }
> type bluetooth
> device $ADDRESS
> }
>
> pcm.bluetooth {
> @args [ ADDRESS ]
> @args.ADDRESS {
> type string
> }
> type plug
> slave {
> pcm {
> type bluetooth
> device $ADDRESS
> }
> }
> }
>
> But I can't understand who uses this file to configure ALSA.
> When HSP/HFP connection had established class BluetoothHandsfree calls
> methods of AudioManager like setParameters, setBluetoothScoOn
>
> Does AudioManager configure ALSA ?
>
> --
> You received this message because you are subscribed to the Google Groups "android-platform" group.
> To post to this group, send email to android-...@googlegroups.com.
> To unsubscribe from this group, send email to android-platfo...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/android-platform?hl=en.
>
>
--
--Pavan Savoy
alex petrov
> ALSA plugin isn't used in Bluetooth on Android.
> There is a seperate liba2dp.c which does what alsa plugin does.
>
> So the liba2dp.so needs to be loaded, which links to the A2dpAudioInterface
Thank you very much, I see that in real bluetoothd works with
audioflinger.
Does it mean that A2dpAudioInterface/liba2dp<->ipc.c is universal
interface for SCO/A2DP pcm data transmission or there are another way
for hsp/hfp?
Pavan Savoy
In A2DP the music data needs to go thru' UART (hci0 for BlueZ) and
hence the liba2dp.
i.e the Music Player needs to communicate with Bluetoothd.
For HFP/HSP, Android's SCO implementation of the audio gateway talks
to blueZ's headset implementation over DBUS for control and connection
establishment and uses vendor defined logic for voice data.
As in the data coming/going in/out of modem into BT-chip is vendor
specific implementation and Android doesn't restrict in any way.
alex petrov
On Aug 10, 12:01 am, Pavan Savoy <pavan.sa...@gmail.com> wrote:
> > On Aug 9, 7:09 pm, Pavan Savoy <pavan.sa...@gmail.com> wrote:
> >> ALSA plugin isn't used in Bluetooth on Android.
> >> There is a seperate liba2dp.c which does what alsa plugin does.
>
> >> So the liba2dp.so needs to be loaded, which links to the A2dpAudioInterface
> >> --Pavan Savoy
>
> > Thank you very much, I see that in real bluetoothd works with
> > audioflinger.
> > Does it mean that A2dpAudioInterface/liba2dp<->ipc.c is universal
> > interface for SCO/A2DP pcm data transmission or there are another way
> > for hsp/hfp?
>
> In A2DP the music data needs to go thru' UART (hci0 for BlueZ) and
> hence the liba2dp.
> i.e the Music Player needs to communicate with Bluetoothd.
using dbus commands, but how I see in com.android.bluetooth class
BluetoothHandsfree uses class ScoSocket to start SCO connection
between Android/bluez stack and remote device. class ScoSocket is
wrapper under bluez socket with protocol BTPROTO_SCO. In this time
bluetoothd waits connection by socket and after this configures
bluez's socket. After this SCO connection is established.
A2DP connection is really started by dbus bluez api
do I understand correctly?
> For HFP/HSP, Android's SCO implementation of the audio gateway talks
> to blueZ's headset implementation over DBUS for control and connection
> establishment and uses vendor defined logic for voice data.
> As in the data coming/going in/out of modem into BT-chip is vendor
> specific implementation and Android doesn't restrict in any way.
Wow! Is it mean that low-level android audio system directly sends/
receives pcm data into/from "vendor
> specific implementation" and receive without Android/bluez participation?
And does android.media AndroidManager.java configure this
communication?
And really, why these profiles in android were so hardly changed ( AT
commands parsing and sco/rfcomm connection transfered into android
framework from bluez ) ? =)
And thank you very much, you radically change my vision of these
profiles =)
Pavan Savoy
humn, May be I am presenting it all wrong.
HFP/HSP has 2 parts right?
control or signalling which is an rfcomm channel
& SCO which is the data channel.
signalling via the rfcomm for the hfp/hsp happens via the bluetoothd over dbus.
SCO happens the way you mentioned it, when there is an incoming call.
The data pushed to BT chip via various means (not UART) is
encapsulated to SCO and sent over air.
This various means of pushing data to BT chip is what I meant by
vendor specific...
A2DP on the other hand, has both signalling and the data going over
the UART, which is at sink.c for control via dbus and liba2dp for the
data.
I am yet to see implementation for the SCO in android to send PCM data
over hci0 (say something like USB interface)....
>> For HFP/HSP, Android's SCO implementation of the audio gateway talks
>> to blueZ's headset implementation over DBUS for control and connection
>> establishment and uses vendor defined logic for voice data.
>> As in the data coming/going in/out of modem into BT-chip is vendor
>> specific implementation and Android doesn't restrict in any way.
>
>> --Pavan Savoy
>
> Wow! Is it mean that low-level android audio system directly sends/
> receives pcm data into/from "vendor
>> specific implementation" and receive without Android/bluez participation?
> And does android.media AndroidManager.java configure this
> communication?
>
> And really, why these profiles in android were so hardly changed ( AT
> commands parsing and sco/rfcomm connection transfered into android
> framework from bluez ) ? =)
>
> And thank you very much, you radically change my vision of these
> profiles =)
>
aaaaaaaa bbbbbbbb
Pavan Savoy
> Ok, I see all android applications that work with the mediaserver can stream
> audio using an A2DP
> But I just a little test android 2.3 and can't understand - do only phone
> rings can work with SCO ?
> And what drivers approximately are works in this case (HSP/HFP except
> bluetooth.ko, sco.ko, rfcomm.ko)?
I wouldn't think any other drivers are in works - except for handling
signaling channel stuff.
However, I would let the Android framework experts comment on what can
be done or should be done for say applications like Skype or any other
VOIP apps to make use of Bluetooth SCO headset.
I suppose this would require the Voice data to be accessible from
Android somewhere ???
Jaikumar Ganesh
> On Thu, Aug 11, 2011 at 10:45 AM, aaaaaaaa bbbbbbbb <alex...@gmail.com> wrote:
>> Ok, I see all android applications that work with the mediaserver can stream
>> audio using an A2DP
>> But I just a little test android 2.3 and can't understand - do only phone
>> rings can work with SCO ?
>> And what drivers approximately are works in this case (HSP/HFP except
>> bluetooth.ko, sco.ko, rfcomm.ko)?
>
> I wouldn't think any other drivers are in works - except for handling
> signaling channel stuff.
>
> However, I would let the Android framework experts comment on what can
> be done or should be done for say applications like Skype or any other
> VOIP apps to make use of Bluetooth SCO headset.
> I suppose this would require the Voice data to be accessible from
> Android somewhere ???
Any app which wants to use SCO audio, should use the AudioManager
public APIs to start and stop Bluetooth SCO.
aaaaaaaa bbbbbbbb
Pavan Savoy
> Yeah, the AudioManager represents API functions setParameters, setParameter,
> setBluetoothScoOn for work with SCO
> If I understand correctly the AudioManager uses AudioSystem and the
> AudioSystem sets routing parameters for AudioFlinger using JNI
> How Pawan said AudioFlinger loads liba2dp.so that communicates with a stack
> Is it right?
> And in this case using API it's all applications that use AudioFlinger can
> stream and capture using HSP.
That would be a2dp, However on the SCO front,
I am still in doubt how an application like skype can pick up voice
data from an wlan0/rmnet0/pp0 sort of interface and send it across to
BT chip ?
I suppose profiles are getting mixed up here :) between my question
and alex's concern....
Adam Jiang
HCI is not designed for SCO connections. SCO data is usually received
from modem and passed though CPU and get into BT module directly on
hardware. As you just mentioned, it is vendor specific stuff, however,
it is going on a linkage connected with several I2S/PCM routing. Since
SCO data should be some kind of realtime, it is usually only 8K sample
rate, this route is handled by vendor's HAL when any stream is defined
in this format with setParameters().
Bjarke Freund-Hansen
> I am yet to see implementation for the SCO in android to send PCM data
> over hci0 (say something like USB interface)....
HCI is not designed for SCO connections. SCO data is usually received
from modem and passed though CPU and get into BT module directly on
hardware. As you just mentioned, it is vendor specific stuff, however,
it is going on a linkage connected with several I2S/PCM routing. Since
SCO data should be some kind of realtime, it is usually only 8K sample
rate, this route is handled by vendor's HAL when any stream is defined
in this format with setParameters().