Hello bluetooth developers.
I have a few questions about BlueZ,PulseAudio.
If there are any plan to develop. I want to discuss how to implement the
below.
1. How to handle New Codec(A2DP) between BlueZ and PulseAudio
As far as I understand puleaduio add_card() working by UUID info.
however , in case of mpeg and other codec, we can't use it.
I think AudioSink dbus interface should provide codec info that headset
supports. Based on it, PulseaAudio can know headset support codec info.
Bluez audio.conf should have option related to this.
2. auto_connect.
Could you explain this purpose?
4. Is there anyone could explain sco_sink, sco_source? If there are ALSA
code related to it, could you tell me the link that explain ?
BR
Chanyeol Park
> > - ?For cell phone call, to let PA know a cell phone call begins so that it can set
> BT profile to "Off" and pause music, are you suggesting we write a PA module
> to detect cell modem call event?
>
> Not exactly, we could probably have some mechanism to tag streams e.g.
> the dialer app tags its stream as 'voice' and the media player as
> 'music', this way PA don't need to depend on any telephony stack to do
> the profile switch.
I feel this method has a gap:
Since the voice data from cell modem bypass PA in such a system, will the dialer app create the sink-input/source-output stream tagged as 'voice' or 'phone' for PA?
If the phone streams do not appear in PA, PA cannot know the time to switch profile by checking the stream's media role.
Please correct me if I misunderstand something.
Great thanks
Mengdong
Hi,
On Wed, Oct 12, 2011 at 8:20 AM, Lin, Mengdong <[email protected]> wrote:
> I don't mean simultaneous A2DP stream and SCO, but hope PA can pause music on a cell or voip call and change BT profile from A2DP to HSP for the call.
It sure can, but right now there is no policy for doing that in PA,
now that 1.0 was release we should probably try to make it happen.
> But for a system that does not export SCO path to the software stack (and if PA is used as the audio server)
> - ?I think it cannot support VOIP call, because PA cannot exchange data between application and ALSA (via sco_sink/sco_source) or Bluez. Is this right?
Yep, VoIP is not support in such systems, so I hope people doing the
hardware/firmware realize that this is quite a huge limitation.
> ?MeeGo harmattan is not such a system, I think, if it uses sco_sink/sco_source then it just exports SCO path through ALSA.
>
> - ?For cell phone call, to let PA know a cell phone call begins so that it can set BT profile to "Off" and pause music, are you suggesting we write a PA module to detect cell modem call event?
Not exactly, we could probably have some mechanism to tag streams e.g.
the dialer app tags its stream as 'voice' and the media player as
'music', this way PA don't need to depend on any telephony stack to do
the profile switch.
> You have mentioned this is a common design for non-smart phones. Is PA suitable to play the role of audio server in such a design?
It is, we just need a way to configure PA to handle it e.g. by having
'none' as sco_sink/sco_source we should set the profile to 'off'.
--
Luiz Augusto von Dentz
Great thanks for your clarification, Luiz! I still have some questions.
> >> ... Apparently some system don't even bother
> >> exporting this audio path to the software stack because it is only
> >> active while on call, if this is your case then it means we cannot
> >> control the audio routing in software and we probably should do
> >> nothing (e.g. set sco_sink/sco_source to "none" and when HFP/HSP is
> >> active set card profile to 'Off'), but note that this type of
> >> configuration has many limitation for instance a system like that
> >> cannot do navigation or voice commands using SCO.
> >
> > Hi Luiz,
> >
> > Would you kindly share more information on a system that does not export
> SCO audio path to the software stack? Is it a typical design for handset?
>
> Apparently it is common design in handset world, but probably not so
> common in smartphones where some other use cases need to be supported
> such as navigation, voice command and voip calls.
>
> > If I have a BT headset that can support both A2DP and HSP profile, and I want
> to hear music in A2DP and make a phone call in HSP profile on such a system, is
> it possible?
> > If it's possible, how can pulseaudio set BT headset to A2DP profile for music
> and change to 'Off' profile on call? Can PA know when a call begins or ends on
> such a system, in order to change BT profile?
>
> If you mean simultaneously A2DP stream and SCO then probably not, most
> headset simple cannot do audio mixing so it is either SCO _or_ A2DP,
> also there are recommendation to always switch the profiles but not to
> use them simultaneously e.g. suspend A2DP streaming while SCO is
> connected. As for PA knowing when to switch we probably need to work
> on that, other systems like MeeGo harmattan have external components
> to do that, but IMO it would have been much better to have such thing
> directly in PA as a module.
>
I don't mean simultaneous A2DP stream and SCO, but hope PA can pause music on a cell or voip call and change BT profile from A2DP to HSP for the call.
But for a system that does not export SCO path to the software stack (and if PA is used as the audio server)
- I think it cannot support VOIP call, because PA cannot exchange data between application and ALSA (via sco_sink/sco_source) or Bluez. Is this right?
MeeGo harmattan is not such a system, I think, if it uses sco_sink/sco_source then it just exports SCO path through ALSA.
- For cell phone call, to let PA know a cell phone call begins so that it can set BT profile to "Off" and pause music, are you suggesting we write a PA module to detect cell modem call event?
You have mentioned this is a common design for non-smart phones. Is PA suitable to play the role of audio server in such a design?
Thanks
Mengdong
Hi,
On Tue, Oct 11, 2011 at 9:19 AM, Lin, Mengdong <[email protected]> wrote:
>> > 4. Is there anyone could explain sco_sink, sco_source? If there are ALSA
>> > code related to it, could you tell me the link that explain ?
>
>> ? Apparently some system don't even bother
>> exporting this audio path to the software stack because it is only
>> active while on call, if this is your case then it means we cannot
>> control the audio routing in software and we probably should do
>> nothing (e.g. set sco_sink/sco_source to "none" and when HFP/HSP is
>> active set card profile to 'Off'), but note that this type of
>> configuration has many limitation for instance a system like that
>> cannot do navigation or voice commands using SCO.
>
> Hi Luiz,
>
> Would you kindly share more information on a system that does not export SCO audio path to the software stack? Is it a typical design for handset?
Apparently it is common design in handset world, but probably not so
common in smartphones where some other use cases need to be supported
such as navigation, voice command and voip calls.
> If I have a BT headset that can support both A2DP and HSP profile, and I want to hear music in A2DP and make a phone call in HSP profile on such a system, is it possible?
> If it?s possible, how can pulseaudio set BT headset to A2DP profile for music and change to ?Off? profile on call? Can PA know when a call begins or ends on such a system, in order to change BT profile?
If you mean simultaneously A2DP stream and SCO then probably not, most
headset simple cannot do audio mixing so it is either SCO _or_ A2DP,
also there are recommendation to always switch the profiles but not to
use them simultaneously e.g. suspend A2DP streaming while SCO is
connected. As for PA knowing when to switch we probably need to work
on that, other systems like MeeGo harmattan have external components
to do that, but IMO it would have been much better to have such thing
directly in PA as a module.
--
Luiz Augusto von Dentz
PiA+IDQuIElzIHRoZXJlIGFueW9uZSBjb3VsZCBleHBsYWluIHNjb19zaW5rLCBzY29fc291cmNl
PyBJZiB0aGVyZSBhcmUgQUxTQQ0KPiA+IGNvZGUgcmVsYXRlZCB0byBpdCwgY291bGQgeW91IHRl
bGwgbWUgdGhlIGxpbmsgdGhhdCBleHBsYWluID8NCg0KPiDigKYgQXBwYXJlbnRseSBzb21lIHN5
c3RlbSBkb24ndCBldmVuIGJvdGhlcg0KPiBleHBvcnRpbmcgdGhpcyBhdWRpbyBwYXRoIHRvIHRo
ZSBzb2Z0d2FyZSBzdGFjayBiZWNhdXNlIGl0IGlzIG9ubHkNCj4gYWN0aXZlIHdoaWxlIG9uIGNh
bGwsIGlmIHRoaXMgaXMgeW91ciBjYXNlIHRoZW4gaXQgbWVhbnMgd2UgY2Fubm90DQo+IGNvbnRy
b2wgdGhlIGF1ZGlvIHJvdXRpbmcgaW4gc29mdHdhcmUgYW5kIHdlIHByb2JhYmx5IHNob3VsZCBk
bw0KPiBub3RoaW5nIChlLmcuIHNldCBzY29fc2luay9zY29fc291cmNlIHRvICJub25lIiBhbmQg
d2hlbiBIRlAvSFNQIGlzDQo+IGFjdGl2ZSBzZXQgY2FyZCBwcm9maWxlIHRvICdPZmYnKSwgYnV0
IG5vdGUgdGhhdCB0aGlzIHR5cGUgb2YNCj4gY29uZmlndXJhdGlvbiBoYXMgbWFueSBsaW1pdGF0
aW9uIGZvciBpbnN0YW5jZSBhIHN5c3RlbSBsaWtlIHRoYXQNCj4gY2Fubm90IGRvIG5hdmlnYXRp
b24gb3Igdm9pY2UgY29tbWFuZHMgdXNpbmcgU0NPLg0KDQpIaSBMdWl6LA0KDQpXb3VsZCB5b3Ug
a2luZGx5IHNoYXJlIG1vcmUgaW5mb3JtYXRpb24gb24gYSBzeXN0ZW0gdGhhdCBkb2VzIG5vdCBl
eHBvcnQgU0NPIGF1ZGlvIHBhdGggdG8gdGhlIHNvZnR3YXJlIHN0YWNrPyBJcyBpdCBhIHR5cGlj
YWwgZGVzaWduIGZvciBoYW5kc2V0Pw0KSWYgSSBoYXZlIGEgQlQgaGVhZHNldCB0aGF0IGNhbiBz
dXBwb3J0IGJvdGggQTJEUCBhbmQgSFNQIHByb2ZpbGUsIGFuZCBJIHdhbnQgdG8gaGVhciBtdXNp
YyBpbiBBMkRQIGFuZCBtYWtlIGEgcGhvbmUgY2FsbCBpbiBIU1AgcHJvZmlsZSBvbiBzdWNoIGEg
c3lzdGVtLCBpcyBpdCBwb3NzaWJsZT8gDQpJZiBpdOKAmXMgcG9zc2libGUsIGhvdyBjYW4gcHVs
c2VhdWRpbyBzZXQgQlQgaGVhZHNldCB0byBBMkRQIHByb2ZpbGUgZm9yIG11c2ljIGFuZCBjaGFu
Z2UgdG8g4oCYT2Zm4oCZIHByb2ZpbGUgb24gY2FsbD8gQ2FuIFBBIGtub3cgd2hlbiBhIGNhbGwg
YmVnaW5zIG9yIGVuZHMgb24gc3VjaCBhIHN5c3RlbSwgaW4gb3JkZXIgdG8gY2hhbmdlIEJUIHBy
b2ZpbGU/DQoNCkdyZWF0IFRoYW5rcw0KTWVuZ2RvbmcNCg0K
On Mon, 2011-10-10 at 17:11 +0900, Chan-yeol Park wrote:
> Hello bluetooth developers.
>
> I have a few questions about BlueZ,PulseAudio.
> If there are any plan to develop. I want to discuss how to implement the
> below.
>
> 1. How to handle New Codec(A2DP) between BlueZ and PulseAudio
> As far as I understand puleaduio add_card() working by UUID info.
> however , in case of mpeg and other codec, we can't use it.
JFYI, I have a branch that does switching between PCM-MPEG using the old
Unix sockets API at:
http://cgit.collabora.com/git/user/arun/pulseaudio.git/log/?h=passthrough
There's a bug w.r.t. applying the correct sample rate (44.1 kHz works
fine, 48 kHz audio seems to be playing at 44.1 kHz).
Cheers,
Arun
Hi Chan-yeol,
On Mon, Oct 10, 2011 at 11:11 AM, Chan-yeol Park
<[email protected]> wrote:
> Hello bluetooth developers.
>
> I have a few questions about BlueZ,PulseAudio.
> If there are any plan to develop. I want to discuss how to implement the
> below.
>
> 1. How to handle New Codec(A2DP) between BlueZ and PulseAudio
> As far as I understand puleaduio add_card() working by UUID info.
> however , in case of mpeg and other codec, we can't use it.
You can have whatever you want as capabilities including new codecs,
so yes it is, or intended to be, possible to have your own SEP
capabilities. UUID in that case only defines the profile/role of the
endpoint you are registering, in fact with test/simple-endpoint it is
already possible to register mp3 endpoints.
> I think AudioSink dbus interface should provide codec info that headset
> supports. Based on it, PulseaAudio can know headset support codec info.
We are trying to avoid using device object to expose this info because
it creates a need of device detection on the clients which is not that
trivial to get it right e.g. PA module-bluetooth-discover. Also the
matching capabilities is done by bluetoothd, PA just receives the
transport configuration, the only thing that is not possible right now
is to force one specific endpoint over the others, what you can do
however is to register this specific endpoint using a dedicated
process/connection (e.g. a media player) and then call Audio.Connect
or AudioSink.Connect from that same process/connection, in other words
the sender's endpoint have higher priority than the other endpoint
registered.
Note that PA cannot mix audio encoded so it just a pass through, so it
is kind tricky to detect whether to use an endpoint or not specially
if the application is not streaming only encoded data.
> Bluez audio.conf should have option related to this.
>
> 2. auto_connect.
> Could you explain this purpose?
This is only valid for the only API, when set this indicates to
bluetoothd that if the device is not connected to start connecting to
it, which means PA will be blocked until it connects which IMO is a
bad.
> 4. Is there anyone could explain sco_sink, sco_source? If there are ALSA
> code related to it, could you tell me the link that explain ?
This is used when SCO packets are not routed to HCI, SCO socket
read/writes won't do anything, in that case we need a device to
read/write the data. Apparently some system don't even bother
exporting this audio path to the software stack because it is only
active while on call, if this is your case then it means we cannot
control the audio routing in software and we probably should do
nothing (e.g. set sco_sink/sco_source to "none" and when HFP/HSP is
active set card profile to 'Off'), but note that this type of
configuration has many limitation for instance a system like that
cannot do navigation or voice commands using SCO.
--
Luiz Augusto von Dentz
Hi Chanyeol,
> >> I have a few questions about BlueZ,PulseAudio.
> >> If there are any plan to develop. I want to discuss how to implement the
> >> below.
> >>
> >> 1. How to handle New Codec(A2DP) between BlueZ and PulseAudio
> >> As far as I understand puleaduio add_card() working by UUID info.
> >> however , in case of mpeg and other codec, we can't use it.
> > You can have whatever you want as capabilities including new codecs,
> > so yes it is, or intended to be, possible to have your own SEP
> > capabilities. UUID in that case only defines the profile/role of the
> > endpoint you are registering, in fact with test/simple-endpoint it is
> > already possible to register mp3 endpoints.
> >
> >> I think AudioSink dbus interface should provide codec info that headset
> >> supports. Based on it, PulseaAudio can know headset support codec info.
> > We are trying to avoid using device object to expose this info because
> > it creates a need of device detection on the clients which is not that
> > trivial to get it right e.g. PA module-bluetooth-discover. Also the
> > matching capabilities is done by bluetoothd, PA just receives the
> > transport configuration, the only thing that is not possible right now
> > is to force one specific endpoint over the others, what you can do
> > however is to register this specific endpoint using a dedicated
> > process/connection (e.g. a media player) and then call Audio.Connect
> > or AudioSink.Connect from that same process/connection, in other words
> > the sender's endpoint have higher priority than the other endpoint
> > registered.
> >
> > Note that PA cannot mix audio encoded so it just a pass through, so it
> > is kind tricky to detect whether to use an endpoint or not specially
> > if the application is not streaming only encoded data.
> >
> >> Bluez audio.conf should have option related to this.
> >>
> >> 2. auto_connect.
> >> Could you explain this purpose?
> > This is only valid for the only API, when set this indicates to
> > bluetoothd that if the device is not connected to start connecting to
> > it, which means PA will be blocked until it connects which IMO is a
> > bad.
> >
> >> 4. Is there anyone could explain sco_sink, sco_source? If there are ALSA
> >> code related to it, could you tell me the link that explain ?
> > This is used when SCO packets are not routed to HCI, SCO socket
> > read/writes won't do anything, in that case we need a device to
> > read/write the data. Apparently some system don't even bother
> > exporting this audio path to the software stack because it is only
> > active while on call, if this is your case then it means we cannot
> > control the audio routing in software and we probably should do
> > nothing (e.g. set sco_sink/sco_source to "none" and when HFP/HSP is
> > active set card profile to 'Off'), but note that this type of
> > configuration has many limitation for instance a system like that
> > cannot do navigation or voice commands using SCO.
> >
> There is an example:
> Headset A2DP Sink(SEP 1:SBC,SEP 3:MP3),
> Player A2DP Source(SEP 1:SBC, SEP 2: MP3)
>
> Some user wants to use SBC codec connection or some user may want to use
> MP3.
>
> However in the bluez, there is no module or interface to handle user
> preference as far as I understand.
>
> And my understand is that bluez current implementation just try to find
> the nearest sep combination.
> If they search from SEP 1, naturally SBC codec is selected..
>
> Could you explain my question?
there is no user preference here. The user can not make the right
choice. Such an option does not make any sense.
The selection should pick the SEP combination that fits most closely to
your actual audio source file. If that file is in MP3 format, then
picking MP3 is preferable, if it is not then this is SBC.
If your audio source is not natively support by the sink then the best
choice is most likely SBC. This can be argued if the system has a DSP
designed for MP3 encoding and decoding, but in most cases the best
choice is to just go with SBC instead.
Also BlueZ allows you to reconfigure from SBC to MP3 on the fly. If one
audio file is present as MP3, it can stream MP3 to the sink. If the
other one is a WAV file, then it can switch to use SBC. The system is
designed to dynamically switch between any supported audio formats.
Regards
Marcel
Hello
On 2011년 10월 10일 22:59, Luiz Augusto von Dentz wrote:
> Hi Chan-yeol,
>
> On Mon, Oct 10, 2011 at 11:11 AM, Chan-yeol Park
> <[email protected]> wrote:
>> Hello bluetooth developers.
>>
>> I have a few questions about BlueZ,PulseAudio.
>> If there are any plan to develop. I want to discuss how to implement the
>> below.
>>
>> 1. How to handle New Codec(A2DP) between BlueZ and PulseAudio
>> As far as I understand puleaduio add_card() working by UUID info.
>> however , in case of mpeg and other codec, we can't use it.
> You can have whatever you want as capabilities including new codecs,
> so yes it is, or intended to be, possible to have your own SEP
> capabilities. UUID in that case only defines the profile/role of the
> endpoint you are registering, in fact with test/simple-endpoint it is
> already possible to register mp3 endpoints.
>
>> I think AudioSink dbus interface should provide codec info that headset
>> supports. Based on it, PulseaAudio can know headset support codec info.
> We are trying to avoid using device object to expose this info because
> it creates a need of device detection on the clients which is not that
> trivial to get it right e.g. PA module-bluetooth-discover. Also the
> matching capabilities is done by bluetoothd, PA just receives the
> transport configuration, the only thing that is not possible right now
> is to force one specific endpoint over the others, what you can do
> however is to register this specific endpoint using a dedicated
> process/connection (e.g. a media player) and then call Audio.Connect
> or AudioSink.Connect from that same process/connection, in other words
> the sender's endpoint have higher priority than the other endpoint
> registered.
>
> Note that PA cannot mix audio encoded so it just a pass through, so it
> is kind tricky to detect whether to use an endpoint or not specially
> if the application is not streaming only encoded data.
>
>> Bluez audio.conf should have option related to this.
>>
>> 2. auto_connect.
>> Could you explain this purpose?
> This is only valid for the only API, when set this indicates to
> bluetoothd that if the device is not connected to start connecting to
> it, which means PA will be blocked until it connects which IMO is a
> bad.
>
>> 4. Is there anyone could explain sco_sink, sco_source? If there are ALSA
>> code related to it, could you tell me the link that explain ?
> This is used when SCO packets are not routed to HCI, SCO socket
> read/writes won't do anything, in that case we need a device to
> read/write the data. Apparently some system don't even bother
> exporting this audio path to the software stack because it is only
> active while on call, if this is your case then it means we cannot
> control the audio routing in software and we probably should do
> nothing (e.g. set sco_sink/sco_source to "none" and when HFP/HSP is
> active set card profile to 'Off'), but note that this type of
> configuration has many limitation for instance a system like that
> cannot do navigation or voice commands using SCO.
>
There is an example:
Headset A2DP Sink(SEP 1:SBC,SEP 3:MP3),
Player A2DP Source(SEP 1:SBC, SEP 2: MP3)
Some user wants to use SBC codec connection or some user may want to use
MP3.
However in the bluez, there is no module or interface to handle user
preference as far as I understand.
And my understand is that bluez current implementation just try to find
the nearest sep combination.
If they search from SEP 1, naturally SBC codec is selected..
Could you explain my question?
BR
Chanyeol Park