If we want to create SCO link when A2DP is in streaming state, we
shall suspend A2DP first and then establish SCO link. Conversely, we
shall resume A2DP link when we drop SCO link. The entire description
can be found in the Simultaneous use of HFP, A2DP, and AVRCP Profiles
Whitepaper on bluetooth org web site.
(https://www.bluetooth.org/Technical/Specifications/whitepapers.htm).
My question is, I found there is no such sink_suspend or sink_resume
method in D-BUS API while these functions are all implemented in Bluez
audio module. I would like to know why don't put them to D-BUS API?
If we need to call these functions we have to expand the D-BUS API.
One more question is, is there a formal way to test SCO/A2DP
simultaneous case? we can't find a proper headset to test it because
those headsets are all well implemented with the simultaneous logic,
so there is no way to enter ourselves' code that handle this logic.
Can we test it by configurating some test tool such as PTS?
Thanks,
Zhu Lan
Hi,
On Thu, Jun 25, 2009, lan zhu wrote:
> My question is, I found there is no such sink_suspend or sink_resume
> method in D-BUS API while these functions are all implemented in Bluez
> audio module. I would like to know why don't put them to D-BUS API?
> If we need to call these functions we have to expand the D-BUS API.
You're forgetting the other control point to audio which is the UNIX
socket that alsa, gstreamer, pulseaudio, etc connect to to request audio
streams. The main purpose of the audio related D-Bus interfaces is to
control and monitor the profile-level connections but not the stream
states.
If you have an active audio stream (either SCO connection or A2DP stream
in streaming state) you also need some application providing data to the
stream (and consuming data from the stream in the SCO case). This is why
there's no control for it in the D-Bus interface. E.g. pulseaudio is able
to handle the switch from HFP/HSP to A2DP and back quite smoothly using
just the UNIX socket IPC messages. If you want to investigate how the
logic in the code goes with respect to this you can start by looking at
audio/unix.c.
If you have a good use case for not using the UNIX socket for controlling
the stream states we can naturally consider adding that to the D-Bus
interface, but right now I get the impression that you might simply not
have been aware that the principal control point for active audio streams
is the UNIX socket that audio clients can connect to.
> One more question is, is there a formal way to test SCO/A2DP
> simultaneous case? we can't find a proper headset to test it because
> those headsets are all well implemented with the simultaneous logic,
> so there is no way to enter ourselves' code that handle this logic.
> Can we test it by configurating some test tool such as PTS?
I'm not aware of any formal way and the PTS (afaik) doesn't have any
support for multi-profile testing.
Johan
Hi Johan,
2009/6/25 Johan Hedberg <[email protected]>:
> Hi,
>
> On Thu, Jun 25, 2009, lan zhu wrote:
>> My question is, ?I found there is no such sink_suspend or sink_resume
>> method in D-BUS API while these functions are all implemented in Bluez
>> audio module. I would like to know why don't put them to D-BUS API?
>> If we need to call these functions we have to expand the D-BUS API.
>
> You're forgetting the other control point to audio which is the UNIX
> socket that alsa, gstreamer, pulseaudio, etc connect to to request audio
> streams. The main purpose of the audio related D-Bus interfaces is to
> control and monitor the profile-level connections but not the stream
> states.
>
> If you have an active audio stream (either SCO connection or A2DP stream
> in streaming state) you also need some application providing data to the
> stream (and consuming data from the stream in the SCO case). This is why
> there's no control for it in the D-Bus interface. E.g. pulseaudio is able
> to handle the switch from HFP/HSP to A2DP and back quite smoothly using
> just the UNIX socket IPC messages. If you want to investigate how the
> logic in the code goes with respect to this you can start by looking at
> audio/unix.c.
>
> If you have a good use case for not using the UNIX socket for controlling
> the stream states we can naturally consider adding that to the D-Bus
> interface, but right now I get the impression that you might simply not
> have been aware that the principal control point for active audio streams
> is the UNIX socket that audio clients can connect to.
>
>> One more question is, is there a formal way to test SCO/A2DP
>> simultaneous case? we can't find a proper headset to test it because
>> those headsets are all well implemented with the simultaneous logic,
>> so there is no way to enter ourselves' code that handle this logic.
>> Can we test it by configurating some test tool such as PTS?
>
> I'm not aware of any formal way and the PTS (afaik) doesn't have any
> support for multi-profile testing.
>
> Johan
>
Thanks for your response. In Google android platform, AudioFlinger
calls the functions in liba2dp for streaming related functions. If we
suspend A2DP Sink in AaudioFlinger when handling SCO routing, it will
be a easy way to implement the A2DP/SCO interaction except for one
violation of the simultaneous whitepaper, that is, the sequence of
halting A2DP streaming and creating SCO. In the whitepaper the
sequence is defined as (1) halt A2DP stream (2) create SCO, but
because AudioFlinger only gets notification after SCO created
successfully, it has to create SCO at first and then halt A2DP stream.
Could you let me know if this sequence is acceptable? Will it bring
any issue in any unexpected cases?
Thanks,
Zhu Lan