media transport -- when is acquire ok to call?

media transport -- when is acquire ok to call?

[Mike]

I'm having some trouble with MediaEndpoint/MediaTransport and A2DP.
When I get the "SetConfiguration" call, I wait 2 seconds and then call
"Acquire", generally giving BlueZ enough time get the D-Bus interface
ready to go.  However, the delay isn't always long enough.  Shown
below is a time when my phone is attempting to pair with BlueZ.  The
error "org.bluez.Error.NotAuthorized" is output from my application.
In this case, the problem is that the audio source is still in the
CONFIGURED state, not in the OPEN state.  Is there a recommended
method of how long to wait before calling acquire?  Or should I rely
on the AudioSource "State" property to become connected (or playing)?
Is there any reason I can't get the transport when in the Configured
state (does the fd not exist yet?)?  Or why is "a2dp_resume" being
called on open (which is what is rejecting my acquire call)?

Thanks,
Mike

bluetoothd[751]: src/adapter.c:adapter_get_device() 00:17:E3:3B:4F:DD
bluetoothd[751]: src/adapter.c:adapter_create_device() 00:17:E3:3B:4F:DD
bluetoothd[751]: src/device.c:device_create() Creating device
/org/bluez/751/hci0/dev_00_17_E3_3B_4F_DD
bluetoothd[751]: src/device.c:btd_device_ref() 0x2a0d4ef0: ref=1
bluetoothd[751]: src/device.c:device_set_temporary() temporary 1
bluetoothd[751]: plugins/hciops.c:remote_features_information() hci0 status 0
bluetoothd[751]: plugins/hciops.c:remote_name_information() hci0 status 0
bluetoothd[751]: audio/avdtp.c:avdtp_confirm_cb() AVDTP: incoming
connect from 00:17:E3:3B:4F:DD
bluetoothd[751]: src/adapter.c:adapter_get_device() 00:17:E3:3B:4F:DD
bluetoothd[751]: src/device.c:btd_device_ref() 0x2a0d4ef0: ref=2
bluetoothd[751]: audio/device.c:audio_device_register() Registered
interface org.bluez.Audio on path
/org/bluez/751/hci0/dev_00_17_E3_3B_4F_DD
bluetoothd[751]: src/device.c:device_probe_drivers() Probing drivers
for 00:17:E3:3B:4F:DD
bluetoothd[751]: audio/manager.c:handle_uuid() server not enabled for
0000110d-0000-1000-8000-00805f9b34fb (0x110d)
bluetoothd[751]: src/agent.c:agent_authorize() authorize request was
sent for /org/bluez/751/hci0/dev_00_17_E3_3B_4F_DD
bluetoothd[751]: plugins/hciops.c:link_key_request() hci0 dba 00:17:E3:3B:4F:DD
bluetoothd[751]: plugins/hciops.c:get_auth_info() hci0 dba 00:17:E3:3B:4F:DD
bluetoothd[751]: plugins/hciops.c:link_key_request() kernel auth
requirements = 0x04
bluetoothd[751]: plugins/hciops.c:link_key_request() Matching key not found
bluetoothd[751]: plugins/hciops.c:pin_code_request() hci0 PIN request
for 00:17:E3:3B:4F:DD
bluetoothd[751]: src/adapter.c:adapter_get_device() 00:17:E3:3B:4F:DD
bluetoothd[751]: src/device.c:device_request_authentication()
Requesting agent authentication for 00:17:E3:3B:4F:DD
bluetoothd[751]: plugins/hciops.c:hciops_pincode_reply() hci0 dba
00:17:E3:3B:4F:DD
bluetoothd[751]: audio/avdtp.c:avdtp_connect_cb() AVDTP: connected
signaling channel to 00:17:E3:3B:4F:DD
bluetoothd[751]: audio/avdtp.c:avdtp_connect_cb() AVDTP imtu=672, omtu=1024
bluetoothd[751]: audio/avdtp.c:session_cb()
bluetoothd[751]: audio/avdtp.c:avdtp_parse_cmd() Received DISCOVER_CMD
bluetoothd[751]: audio/avdtp.c:session_cb()
bluetoothd[751]: audio/avdtp.c:avdtp_parse_cmd() Received  GET_CAPABILITIES_CMD
bluetoothd[751]: audio/a2dp.c:endpoint_getcap_ind() Sink 0x2a0d40a8:
Get_Capability_Ind
bluetoothd[751]: audio/avdtp.c:session_cb()
bluetoothd[751]: audio/avdtp.c:avdtp_parse_cmd() Received SET_CONFIGURATION_CMD
bluetoothd[751]: src/device.c:device_probe_drivers() Probing drivers
for 00:17:E3:3B:4F:DD
bluetoothd[751]: audio/manager.c:handle_uuid() Found Audio Source
bluetoothd[751]: audio/source.c:source_init() Registered interface
org.bluez.AudioSource on path
/org/bluez/751/hci0/dev_00_17_E3_3B_4F_DD
bluetoothd[751]: audio/a2dp.c:endpoint_setconf_ind() Sink 0x2a0d40a8:
Set_Configuration_Ind
bluetoothd[751]: audio/avdtp.c:avdtp_ref() 0x2a0d2a00: ref=2
bluetoothd[751]: audio/a2dp.c:setup_ref() 0x2a0a6e00: ref=1
bluetoothd[751]: audio/media.c:media_endpoint_async_call() Calling
SetConfiguration: name = :1.40 path = /com/starkey/a2dp/endpoint
bluetoothd[751]: audio/avdtp.c:avdtp_ref() 0x2a0d2a00: ref=3
bluetoothd[751]: audio/avdtp.c:avdtp_sep_set_state() stream state
changed: IDLE -> CONFIGURED
bluetoothd[751]: audio/a2dp.c:setup_unref() 0x2a0a6e00: ref=0
bluetoothd[751]: audio/a2dp.c:setup_free() 0x2a0a6e00
bluetoothd[751]: audio/avdtp.c:avdtp_unref() 0x2a0d2a00: ref=2
bluetoothd[751]: audio/avdtp.c:session_cb()
bluetoothd[751]: audio/avdtp.c:avdtp_parse_cmd() Received OPEN_CMD
bluetoothd[751]: audio/a2dp.c:open_ind() Sink 0x2a0d40a8: Open_Ind
bluetoothd[751]: audio/transport.c:media_transport_acquire() Transport
/org/bluez/751/hci0/dev_00_17_E3_3B_4F_DD/fd1: read lock acquired
bluetoothd[751]: audio/transport.c:media_transport_acquire() Transport
/org/bluez/751/hci0/dev_00_17_E3_3B_4F_DD/fd1: write lock acquired
bluetoothd[751]: audio/transport.c:media_owner_create() Owner created:
sender=:1.40 accesstype=rw
bluetoothd[751]: audio/avdtp.c:avdtp_ref() 0x2a0d2a00: ref=3
bluetoothd[751]: audio/transport.c:media_transport_release() Transport
/org/bluez/751/hci0/dev_00_17_E3_3B_4F_DD/fd1: read lock released
bluetoothd[751]: audio/transport.c:media_transport_release() Transport
/org/bluez/751/hci0/dev_00_17_E3_3B_4F_DD/fd1: write lock released
bluetoothd[751]: audio/transport.c:media_owner_free() Owner :1.40
getting the reply from the cb failed
GDBus.Error:org.bluez.Error.NotAuthorized: Operation Not Authorized
bluetoothd[751]: plugins/hciops.c:link_key_notify() hci0 dba
00:17:E3:3B:4F:DD type 0
bluetoothd[751]: plugins/hciops.c:link_key_notify() key type 0x00 old
key type 0xff
bluetoothd[751]: plugins/hciops.c:link_key_notify() local auth 0x04
and remote auth 0xff
bluetoothd[751]: src/adapter.c:adapter_get_device() 00:17:E3:3B:4F:DD
bluetoothd[751]: src/event.c:btd_event_link_key_notify() storing link
key of type 0x00
bluetoothd[751]: src/device.c:device_set_bonded() bonded 1
bluetoothd[751]: src/device.c:device_set_temporary() temporary 0
bluetoothd[751]: plugins/hciops.c:bonding_complete() status 0x00
bluetoothd[751]: src/adapter.c:adapter_get_device() 00:17:E3:3B:4F:DD
bluetoothd[751]: src/device.c:device_bonding_complete() bonding (nil)
status 0x00
bluetoothd[751]: src/device.c:device_bonding_complete() setting timer
for reverse service discovery
bluetoothd[751]: plugins/hciops.c:auth_complete() hci0 status 0
bluetoothd[751]: plugins/hciops.c:bonding_complete() status 0x00
bluetoothd[751]: src/adapter.c:adapter_get_device() 00:17:E3:3B:4F:DD
bluetoothd[751]: src/device.c:device_bonding_complete() bonding (nil)
status 0x00
bluetoothd[751]: audio/avdtp.c:avdtp_confirm_cb() AVDTP: incoming
connect from 00:17:E3:3B:4F:DD
bluetoothd[751]: src/device.c:device_probe_drivers() Probing drivers
for 00:17:E3:3B:4F:DD
bluetoothd[751]: audio/manager.c:handle_uuid() Found Handsfree AG record
bluetoothd[751]: audio/manager.c:gateway_auth_cb() Accepted AG
connection from 00:17:E3:3B:4F:DD for
/org/bluez/751/hci0/dev_00_17_E3_3B_4F_DD
bluetoothd[751]: audio/avdtp.c:avdtp_connect_cb() AVDTP: connected
transport channel to 00:17:E3:3B:4F:DD
bluetoothd[751]: audio/avdtp.c:avdtp_sep_set_state() stream state
changed: CONFIGURED -> OPEN

Re: media transport -- when is acquire ok to call?

[Luiz Augusto von Dentz]

Hi Mike,

On Wed, Mar 21, 2012 at 4:02 PM, Mike <puffy.taco@gmail.com> wrote:
> I'm having some trouble with MediaEndpoint/MediaTransport and A2DP.
> When I get the "SetConfiguration" call, I wait 2 seconds and then call
> "Acquire", generally giving BlueZ enough time get the D-Bus interface
> ready to go.  However, the delay isn't always long enough.  Shown
> below is a time when my phone is attempting to pair with BlueZ.  The
> error "org.bluez.Error.NotAuthorized" is output from my application.
> In this case, the problem is that the audio source is still in the
> CONFIGURED state, not in the OPEN state.  Is there a recommended
> method of how long to wait before calling acquire?  Or should I rely
> on the AudioSource "State" property to become connected (or playing)?
> Is there any reason I can't get the transport when in the Configured
> state (does the fd not exist yet?)?  Or why is "a2dp_resume" being
> called on open (which is what is rejecting my acquire call)?

In case of PA we do wait for Audio.Connected property before loading
the module which does call MediaTransport.Acquire, but 2 seconds is
too much there might be something else holding the setup, do you reply
right away the SetConfiguration, if you do try to Acquire while
bluetoothd is waiting you to reply it might fail.

> bluetoothd[751]: audio/avdtp.c:avdtp_parse_cmd() Received OPEN_CMD
> bluetoothd[751]: audio/a2dp.c:open_ind() Sink 0x2a0d40a8: Open_Ind
> bluetoothd[751]: audio/transport.c:media_transport_acquire() Transport
> /org/bluez/751/hci0/dev_00_17_E3_3B_4F_DD/fd1: read lock acquired
> bluetoothd[751]: audio/transport.c:media_transport_acquire() Transport
> /org/bluez/751/hci0/dev_00_17_E3_3B_4F_DD/fd1: write lock acquired
> bluetoothd[751]: audio/transport.c:media_owner_create() Owner created:
> sender=:1.40 accesstype=rw
> bluetoothd[751]: audio/avdtp.c:avdtp_ref() 0x2a0d2a00: ref=3
> bluetoothd[751]: audio/transport.c:media_transport_release() Transport
> /org/bluez/751/hci0/dev_00_17_E3_3B_4F_DD/fd1: read lock released
> bluetoothd[751]: audio/transport.c:media_transport_release() Transport
> /org/bluez/751/hci0/dev_00_17_E3_3B_4F_DD/fd1: write lock released
> bluetoothd[751]: audio/transport.c:media_owner_free() Owner :1.40
> getting the reply from the cb failed
> GDBus.Error:org.bluez.Error.NotAuthorized: Operation Not Authorized

Strange, if what you said is true why there is no "SEP in bad state
for resume" error? Anyway I think we can fix this by checking the
current state of the SEP and waiting it to go OPEN to resume, so the
client don't have to keep tracking of Audio.Connected.


-- 
Luiz Augusto von Dentz

Re: media transport -- when is acquire ok to call?

[Mike]

Hi Luiz,

On Thu, Mar 22, 2012 at 12:18 PM, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> Hi Mike,
>
> On Wed, Mar 21, 2012 at 4:02 PM, Mike <puffy.taco@gmail.com> wrote:
>> I'm having some trouble with MediaEndpoint/MediaTransport and A2DP.
>> When I get the "SetConfiguration" call, I wait 2 seconds and then call
>> "Acquire", generally giving BlueZ enough time get the D-Bus interface
>> ready to go.  However, the delay isn't always long enough.  Shown
>> below is a time when my phone is attempting to pair with BlueZ.  The
>> error "org.bluez.Error.NotAuthorized" is output from my application.
>> In this case, the problem is that the audio source is still in the
>> CONFIGURED state, not in the OPEN state.  Is there a recommended
>> method of how long to wait before calling acquire?  Or should I rely
>> on the AudioSource "State" property to become connected (or playing)?
>> Is there any reason I can't get the transport when in the Configured
>> state (does the fd not exist yet?)?  Or why is "a2dp_resume" being
>> called on open (which is what is rejecting my acquire call)?
>
> In case of PA we do wait for Audio.Connected property before loading
> the module which does call MediaTransport.Acquire, but 2 seconds is
> too much there might be something else holding the setup, do you reply
> right away the SetConfiguration, if you do try to Acquire while
> bluetoothd is waiting you to reply it might fail.

I do reply right away.  This is on an embedded device and it seems
like BlueZ needs just a bit of time to get the interface ready or else
I get 'Method "Acquire" with signature "s" on interface
"org.bluez.MediaTransport" doesn't exist'.

>> bluetoothd[751]: audio/avdtp.c:avdtp_parse_cmd() Received OPEN_CMD
>> bluetoothd[751]: audio/a2dp.c:open_ind() Sink 0x2a0d40a8: Open_Ind
>> bluetoothd[751]: audio/transport.c:media_transport_acquire() Transport
>> /org/bluez/751/hci0/dev_00_17_E3_3B_4F_DD/fd1: read lock acquired
>> bluetoothd[751]: audio/transport.c:media_transport_acquire() Transport
>> /org/bluez/751/hci0/dev_00_17_E3_3B_4F_DD/fd1: write lock acquired
>> bluetoothd[751]: audio/transport.c:media_owner_create() Owner created:
>> sender=:1.40 accesstype=rw
>> bluetoothd[751]: audio/avdtp.c:avdtp_ref() 0x2a0d2a00: ref=3
>> bluetoothd[751]: audio/transport.c:media_transport_release() Transport
>> /org/bluez/751/hci0/dev_00_17_E3_3B_4F_DD/fd1: read lock released
>> bluetoothd[751]: audio/transport.c:media_transport_release() Transport
>> /org/bluez/751/hci0/dev_00_17_E3_3B_4F_DD/fd1: write lock released
>> bluetoothd[751]: audio/transport.c:media_owner_free() Owner :1.40
>> getting the reply from the cb failed
>> GDBus.Error:org.bluez.Error.NotAuthorized: Operation Not Authorized
>
> Strange, if what you said is true why there is no "SEP in bad state
> for resume" error? Anyway I think we can fix this by checking the
> current state of the SEP and waiting it to go OPEN to resume, so the
> client don't have to keep tracking of Audio.Connected.

I just tried it again, as I'd seen that message before, and this time
it was happy enough to provide that error.

bluetoothd[734]: audio/avdtp.c:avdtp_parse_cmd() Received OPEN_CMD
bluetoothd[734]: audio/a2dp.c:open_ind() Sink 0x2a0f1ff8: Open_Ind
bluetoothd[734]: audio/transport.c:media_transport_acquire() Transport
/org/bluez/734/hci0/dev_00_17_E3_3B_4F_DD/fd0: read lock acquired
bluetoothd[734]: audio/transport.c:media_transport_acquire() Transport
/org/bluez/734/hci0/dev_00_17_E3_3B_4F_DD/fd0: write lock acquired
bluetoothd[734]: audio/transport.c:media_owner_create() Owner created:
sender=:1.12 accesstype=rw
bluetoothd[734]: audio/avdtp.c:avdtp_ref() 0x2a11d980: ref=3
bluetoothd[734]: audio/a2dp.c:a2dp_sep_lock() SEP 0x2a0f1ff8 locked
bluetoothd[734]: audio/avdtp.c:avdtp_ref() 0x2a11d980: ref=4
bluetoothd[734]: audio/a2dp.c:setup_ref() 0x2a0efb68: ref=1
bluetoothd[734]: SEP in bad state for resume

In this case, the OPEN_CMD is sent to my phone, but BlueZ and my phone
are in a pairing process and the phone won't reply to this until the
two are paired.  Incidentally, after fixing a bug in avdtp.c,

@@ -1520,7 +1520,7 @@ static gboolean avdtp_setconf_cmd(struct avdtp
*session, uint8_t transaction,
        case AVDTP_SEP_TYPE_SINK:
                if (!dev->source) {
                        btd_device_add_uuid(dev->btd_dev, A2DP_SOURCE_UUID);
-                       if (!dev->sink) {
+                       if (!dev->source) {

my phone will reboot itself after pairing.  I relaxed the REQ_TIMEOUT
to 60 seconds, and with this change, my phone no longer reboots after
pairing.  I assume that my phone gets confused that the A2DP link was
disconnected during the pairing operation.

Re: media transport -- when is acquire ok to call?

[Mike]

On Thu, Mar 22, 2012 at 3:53 PM, Mike <puffy.taco@gmail.com> wrote:
> Hi Luiz,
>
> On Thu, Mar 22, 2012 at 12:18 PM, Luiz Augusto von Dentz
> <luiz.dentz@gmail.com> wrote:
>> Hi Mike,
>>
>> On Wed, Mar 21, 2012 at 4:02 PM, Mike <puffy.taco@gmail.com> wrote:
>>> I'm having some trouble with MediaEndpoint/MediaTransport and A2DP.
>>> When I get the "SetConfiguration" call, I wait 2 seconds and then call
>>> "Acquire", generally giving BlueZ enough time get the D-Bus interface
>>> ready to go.  However, the delay isn't always long enough.  Shown
>>> below is a time when my phone is attempting to pair with BlueZ.  The
>>> error "org.bluez.Error.NotAuthorized" is output from my application.
>>> In this case, the problem is that the audio source is still in the
>>> CONFIGURED state, not in the OPEN state.  Is there a recommended
>>> method of how long to wait before calling acquire?  Or should I rely
>>> on the AudioSource "State" property to become connected (or playing)?
>>> Is there any reason I can't get the transport when in the Configured
>>> state (does the fd not exist yet?)?  Or why is "a2dp_resume" being
>>> called on open (which is what is rejecting my acquire call)?
>>
>> In case of PA we do wait for Audio.Connected property before loading
>> the module which does call MediaTransport.Acquire, but 2 seconds is
>> too much there might be something else holding the setup, do you reply
>> right away the SetConfiguration, if you do try to Acquire while
>> bluetoothd is waiting you to reply it might fail.
>
> I do reply right away.  This is on an embedded device and it seems
> like BlueZ needs just a bit of time to get the interface ready or else
> I get 'Method "Acquire" with signature "s" on interface
> "org.bluez.MediaTransport" doesn't exist'.
>
>>> bluetoothd[751]: audio/avdtp.c:avdtp_parse_cmd() Received OPEN_CMD
>>> bluetoothd[751]: audio/a2dp.c:open_ind() Sink 0x2a0d40a8: Open_Ind
>>> bluetoothd[751]: audio/transport.c:media_transport_acquire() Transport
>>> /org/bluez/751/hci0/dev_00_17_E3_3B_4F_DD/fd1: read lock acquired
>>> bluetoothd[751]: audio/transport.c:media_transport_acquire() Transport
>>> /org/bluez/751/hci0/dev_00_17_E3_3B_4F_DD/fd1: write lock acquired
>>> bluetoothd[751]: audio/transport.c:media_owner_create() Owner created:
>>> sender=:1.40 accesstype=rw
>>> bluetoothd[751]: audio/avdtp.c:avdtp_ref() 0x2a0d2a00: ref=3
>>> bluetoothd[751]: audio/transport.c:media_transport_release() Transport
>>> /org/bluez/751/hci0/dev_00_17_E3_3B_4F_DD/fd1: read lock released
>>> bluetoothd[751]: audio/transport.c:media_transport_release() Transport
>>> /org/bluez/751/hci0/dev_00_17_E3_3B_4F_DD/fd1: write lock released
>>> bluetoothd[751]: audio/transport.c:media_owner_free() Owner :1.40
>>> getting the reply from the cb failed
>>> GDBus.Error:org.bluez.Error.NotAuthorized: Operation Not Authorized
>>
>> Strange, if what you said is true why there is no "SEP in bad state
>> for resume" error? Anyway I think we can fix this by checking the
>> current state of the SEP and waiting it to go OPEN to resume, so the
>> client don't have to keep tracking of Audio.Connected.
>
> I just tried it again, as I'd seen that message before, and this time
> it was happy enough to provide that error.
>
> bluetoothd[734]: audio/avdtp.c:avdtp_parse_cmd() Received OPEN_CMD
> bluetoothd[734]: audio/a2dp.c:open_ind() Sink 0x2a0f1ff8: Open_Ind
> bluetoothd[734]: audio/transport.c:media_transport_acquire() Transport
> /org/bluez/734/hci0/dev_00_17_E3_3B_4F_DD/fd0: read lock acquired
> bluetoothd[734]: audio/transport.c:media_transport_acquire() Transport
> /org/bluez/734/hci0/dev_00_17_E3_3B_4F_DD/fd0: write lock acquired
> bluetoothd[734]: audio/transport.c:media_owner_create() Owner created:
> sender=:1.12 accesstype=rw
> bluetoothd[734]: audio/avdtp.c:avdtp_ref() 0x2a11d980: ref=3
> bluetoothd[734]: audio/a2dp.c:a2dp_sep_lock() SEP 0x2a0f1ff8 locked
> bluetoothd[734]: audio/avdtp.c:avdtp_ref() 0x2a11d980: ref=4
> bluetoothd[734]: audio/a2dp.c:setup_ref() 0x2a0efb68: ref=1
> bluetoothd[734]: SEP in bad state for resume
>
> In this case, the OPEN_CMD is sent to my phone, but BlueZ and my phone
> are in a pairing process and the phone won't reply to this until the
> two are paired.  Incidentally, after fixing a bug in avdtp.c,
>
> @@ -1520,7 +1520,7 @@ static gboolean avdtp_setconf_cmd(struct avdtp
> *session, uint8_t transaction,
>        case AVDTP_SEP_TYPE_SINK:
>                if (!dev->source) {
>                        btd_device_add_uuid(dev->btd_dev, A2DP_SOURCE_UUID);
> -                       if (!dev->sink) {
> +                       if (!dev->source) {
>
> my phone will reboot itself after pairing.  I relaxed the REQ_TIMEOUT
> to 60 seconds, and with this change, my phone no longer reboots after
> pairing.  I assume that my phone gets confused that the A2DP link was
> disconnected during the pairing operation.

I think I've figured out why I didn't see the SEP error print out.
The function resume_a2dp calls a2dp_sep_lock.  The only place this
ever gets unlocked is in a suspend call.  If a2dp_resume returns an
error code, the sep remains forever locked.  And it seems, the SEP
will no longer let acquire happen on future A2DP connections,
requiring bluetoothd to be restarted for this to work.

Re: media transport -- when is acquire ok to call?

[Dalleau, Frederic]

Hi Mike, Luiz,

> I think I've figured out why I didn't see the SEP error print out.
> The function resume_a2dp calls a2dp_sep_lock.  The only place this
> ever gets unlocked is in a suspend call.  If a2dp_resume returns an
> error code, the sep remains forever locked.  And it seems, the SEP
> will no longer let acquire happen on future A2DP connections,
> requiring bluetoothd to be restarted for this to work.

I'm experimenting similar issues right now on hfgw.
Could it be because the endpoint is crashing after acquiring?

Frédéric

Re: media transport -- when is acquire ok to call?

[Mike]

On Fri, Mar 23, 2012 at 9:25 AM, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> Hi Mike,
>
> On Thu, Mar 22, 2012 at 6:21 PM, Mike <puffy.taco@gmail.com> wrote:
>>> I do reply right away.  This is on an embedded device and it seems
>>> like BlueZ needs just a bit of time to get the interface ready or else
>>> I get 'Method "Acquire" with signature "s" on interface
>>> "org.bluez.MediaTransport" doesn't exist'.
>>>
>>>>> bluetoothd[751]: audio/avdtp.c:avdtp_parse_cmd() Received OPEN_CMD
>>>>> bluetoothd[751]: audio/a2dp.c:open_ind() Sink 0x2a0d40a8: Open_Ind
>>>>> bluetoothd[751]: audio/transport.c:media_transport_acquire() Transport
>>>>> /org/bluez/751/hci0/dev_00_17_E3_3B_4F_DD/fd1: read lock acquired
>>>>> bluetoothd[751]: audio/transport.c:media_transport_acquire() Transport
>>>>> /org/bluez/751/hci0/dev_00_17_E3_3B_4F_DD/fd1: write lock acquired
>>>>> bluetoothd[751]: audio/transport.c:media_owner_create() Owner created:
>>>>> sender=:1.40 accesstype=rw
>>>>> bluetoothd[751]: audio/avdtp.c:avdtp_ref() 0x2a0d2a00: ref=3
>>>>> bluetoothd[751]: audio/transport.c:media_transport_release() Transport
>>>>> /org/bluez/751/hci0/dev_00_17_E3_3B_4F_DD/fd1: read lock released
>>>>> bluetoothd[751]: audio/transport.c:media_transport_release() Transport
>>>>> /org/bluez/751/hci0/dev_00_17_E3_3B_4F_DD/fd1: write lock released
>>>>> bluetoothd[751]: audio/transport.c:media_owner_free() Owner :1.40
>>>>> getting the reply from the cb failed
>>>>> GDBus.Error:org.bluez.Error.NotAuthorized: Operation Not Authorized
>>>>
>>>> Strange, if what you said is true why there is no "SEP in bad state
>>>> for resume" error? Anyway I think we can fix this by checking the
>>>> current state of the SEP and waiting it to go OPEN to resume, so the
>>>> client don't have to keep tracking of Audio.Connected.
>>>
>>> I just tried it again, as I'd seen that message before, and this time
>>> it was happy enough to provide that error.
>>>
>>> bluetoothd[734]: audio/avdtp.c:avdtp_parse_cmd() Received OPEN_CMD
>>> bluetoothd[734]: audio/a2dp.c:open_ind() Sink 0x2a0f1ff8: Open_Ind
>>> bluetoothd[734]: audio/transport.c:media_transport_acquire() Transport
>>> /org/bluez/734/hci0/dev_00_17_E3_3B_4F_DD/fd0: read lock acquired
>>> bluetoothd[734]: audio/transport.c:media_transport_acquire() Transport
>>> /org/bluez/734/hci0/dev_00_17_E3_3B_4F_DD/fd0: write lock acquired
>>> bluetoothd[734]: audio/transport.c:media_owner_create() Owner created:
>>> sender=:1.12 accesstype=rw
>>> bluetoothd[734]: audio/avdtp.c:avdtp_ref() 0x2a11d980: ref=3
>>> bluetoothd[734]: audio/a2dp.c:a2dp_sep_lock() SEP 0x2a0f1ff8 locked
>>> bluetoothd[734]: audio/avdtp.c:avdtp_ref() 0x2a11d980: ref=4
>>> bluetoothd[734]: audio/a2dp.c:setup_ref() 0x2a0efb68: ref=1
>>> bluetoothd[734]: SEP in bad state for resume
>>>
>>> In this case, the OPEN_CMD is sent to my phone, but BlueZ and my phone
>>> are in a pairing process and the phone won't reply to this until the
>>> two are paired.  Incidentally, after fixing a bug in avdtp.c,
>
> Why the pairing is being triggered only on OPEN? It should have been
> triggered for the signalling channel, this is probably why is taking
> so long to connect the transport channel.

It does appear to trigger based on the signalling channel, however it
appears that the connection process continues on regardless.  I pasted
below a log, everything in the log occurs while my phone is still
asking me if I want to pair with the BlueZ device.  We don't get
beyond the OPEN_CMD into an actual OPEN state until the pairing
process completes.

bluetoothd[498]: plugins/hciops.c:conn_complete() status 0x00
bluetoothd[498]: src/adapter.c:adapter_get_device() 00:17:E3:3B:4F:DD
bluetoothd[498]: src/adapter.c:adapter_create_device() 00:17:E3:3B:4F:DD
bluetoothd[498]: src/device.c:device_create() Creating device
/org/bluez/498/hci0/dev_00_17_E3_3B_4F_DD
bluetoothd[498]: src/device.c:btd_device_ref() 0x2a0f53c0: ref=1
bluetoothd[498]: src/device.c:device_set_temporary() temporary 1
bluetoothd[498]: plugins/hciops.c:remote_features_information() hci0 status 0
bluetoothd[498]: plugins/hciops.c:remote_name_information() hci0 status 0
bluetoothd[498]: audio/avdtp.c:avdtp_confirm_cb() AVDTP: incoming
connect from 00:17:E3:3B:4F:DD
bluetoothd[498]: src/adapter.c:adapter_get_device() 00:17:E3:3B:4F:DD
bluetoothd[498]: src/device.c:btd_device_ref() 0x2a0f53c0: ref=2
bluetoothd[498]: audio/device.c:audio_device_register() Registered
interface org.bluez.Audio on path
/org/bluez/498/hci0/dev_00_17_E3_3B_4F_DD
bluetoothd[498]: src/device.c:device_probe_drivers() Probing drivers
for 00:17:E3:3B:4F:DD
bluetoothd[498]: audio/manager.c:handle_uuid() server not enabled for
0000110d-0000-1000-8000-00805f9b34fb (0x110d)
bluetoothd[498]: src/agent.c:agent_authorize() authorize request was
sent for /org/bluez/498/hci0/dev_00_17_E3_3B_4F_DD
bluetoothd[498]: plugins/hciops.c:link_key_request() hci0 dba 00:17:E3:3B:4F:DD
bluetoothd[498]: plugins/hciops.c:get_auth_info() hci0 dba 00:17:E3:3B:4F:DD
bluetoothd[498]: plugins/hciops.c:link_key_request() kernel auth
requirements = 0x04
bluetoothd[498]: plugins/hciops.c:link_key_request() Matching key not found
bluetoothd[498]: plugins/hciops.c:pin_code_request() hci0 PIN request
for 00:17:E3:3B:4F:DD
bluetoothd[498]: src/adapter.c:adapter_get_device() 00:17:E3:3B:4F:DD
bluetoothd[498]: src/device.c:device_request_authentication()
Requesting agent authentication for 00:17:E3:3B:4F:DD
bluetoothd[498]: plugins/hciops.c:hciops_pincode_reply() hci0 dba
00:17:E3:3B:4F:DD
bluetoothd[498]: audio/avdtp.c:avdtp_connect_cb() AVDTP: connected
signaling channel to 00:17:E3:3B:4F:DD
bluetoothd[498]: audio/avdtp.c:avdtp_connect_cb() AVDTP imtu=672, omtu=1024
bluetoothd[498]: audio/avdtp.c:session_cb()
bluetoothd[498]: audio/avdtp.c:avdtp_parse_cmd() Received DISCOVER_CMD
bluetoothd[498]: audio/avdtp.c:session_cb()
bluetoothd[498]: audio/avdtp.c:avdtp_parse_cmd() Received  GET_CAPABILITIES_CMD
bluetoothd[498]: audio/a2dp.c:endpoint_getcap_ind() Sink 0x2a0efb60:
Get_Capability_Ind
bluetoothd[498]: audio/avdtp.c:session_cb()
bluetoothd[498]: audio/avdtp.c:avdtp_parse_cmd() Received SET_CONFIGURATION_CMD
bluetoothd[498]: src/device.c:device_probe_drivers() Probing drivers
for 00:17:E3:3B:4F:DD
bluetoothd[498]: audio/manager.c:handle_uuid() Found Audio Source
bluetoothd[498]: audio/source.c:source_init() Registered interface
org.bluez.AudioSource on path
/org/bluez/498/hci0/dev_00_17_E3_3B_4F_DD
bluetoothd[498]: audio/a2dp.c:endpoint_setconf_ind() Sink 0x2a0efb60:
Set_Configuration_Ind
bluetoothd[498]: audio/avdtp.c:avdtp_ref() 0x2a0f5558: ref=2
bluetoothd[498]: audio/a2dp.c:setup_ref() 0x2a0f5da8: ref=1
bluetoothd[498]: audio/media.c:media_endpoint_async_call() Calling
SetConfiguration: name = :1.1 path = /a2dp/endpoint
bluetoothd[498]: audio/avdtp.c:avdtp_ref() 0x2a0f5558: ref=3
bluetoothd[498]: audio/avdtp.c:avdtp_sep_set_state() stream state
changed: IDLE -> CONFIGURED
bluetoothd[498]: audio/a2dp.c:setup_unref() 0x2a0f5da8: ref=0
bluetoothd[498]: audio/a2dp.c:setup_free() 0x2a0f5da8
bluetoothd[498]: audio/avdtp.c:avdtp_unref() 0x2a0f5558: ref=2
bluetoothd[498]: audio/avdtp.c:session_cb()
bluetoothd[498]: audio/avdtp.c:avdtp_parse_cmd() Received OPEN_CMD
bluetoothd[498]: audio/a2dp.c:open_ind() Sink 0x2a0efb60: Open_Ind
bluetoothd[498]: audio/transport.c:media_transport_acquire() Transport
/org/bluez/498/hci0/dev_00_17_E3_3B_4F_DD/fd0: read lock acquired
bluetoothd[498]: audio/transport.c:media_transport_acquire() Transport
/org/bluez/498/hci0/dev_00_17_E3_3B_4F_DD/fd0: write lock acquired
bluetoothd[498]: audio/transport.c:media_owner_create() Owner created:
sender=:1.1 accesstype=rw
bluetoothd[498]: audio/avdtp.c:avdtp_ref() 0x2a0f5558: ref=3
bluetoothd[498]: audio/a2dp.c:a2dp_sep_lock() SEP 0x2a0efb60 locked
bluetoothd[498]: audio/avdtp.c:avdtp_ref() 0x2a0f5558: ref=4
bluetoothd[498]: audio/a2dp.c:setup_ref() 0x2a0f5da8: ref=1
bluetoothd[498]: SEP in bad state for resume
bluetoothd[498]: audio/a2dp.c:setup_unref() 0x2a0f5da8: ref=0
bluetoothd[498]: audio/a2dp.c:setup_free() 0x2a0f5da8
bluetoothd[498]: audio/avdtp.c:avdtp_unref() 0x2a0f5558: ref=3
bluetoothd[498]: audio/transport.c:media_transport_release() Transport
/org/bluez/498/hci0/dev_00_17_E3_3B_4F_DD/fd0: read lock released
bluetoothd[498]: audio/transport.c:media_transport_release() Transport
/org/bluez/498/hci0/dev_00_17_E3_3B_4F_DD/fd0: write lock released
bluetoothd[498]: audio/transport.c:media_owner_free() Owner :1.1

>
>>> @@ -1520,7 +1520,7 @@ static gboolean avdtp_setconf_cmd(struct avdtp
>>> *session, uint8_t transaction,
>>>        case AVDTP_SEP_TYPE_SINK:
>>>                if (!dev->source) {
>>>                        btd_device_add_uuid(dev->btd_dev, A2DP_SOURCE_UUID);
>>> -                       if (!dev->sink) {
>>> +                       if (!dev->source) {
>
> Yep, this seems to be a copy/paste bug from the lines right above it,
> care to send a patch?

Done.

>>> my phone will reboot itself after pairing.  I relaxed the REQ_TIMEOUT
>>> to 60 seconds, and with this change, my phone no longer reboots after
>>> pairing.  I assume that my phone gets confused that the A2DP link was
>>> disconnected during the pairing operation.
>
> 60 seconds is way too long, it should be at least smaller than D-Bus
> default timeout which is 25 sec.

What exactly is this timeout waiting for?  I haven't figured that out
yet.  I assume it's waiting on something from my phone (the a2dp
source) and not D-Bus?

>> I think I've figured out why I didn't see the SEP error print out.
>> The function resume_a2dp calls a2dp_sep_lock.  The only place this
>> ever gets unlocked is in a suspend call.  If a2dp_resume returns an
>> error code, the sep remains forever locked.  And it seems, the SEP
>> will no longer let acquire happen on future A2DP connections,
>> requiring bluetoothd to be restarted for this to work.
>
> Yep, we should be able to fix this by checking the return of
> a2dp_resume and unlock in case it does fail (return 0).
>
> --
> Luiz Augusto von Dentz

Re: media transport -- when is acquire ok to call?

[Mike]

On Thu, Mar 22, 2012 at 12:18 PM, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> Hi Mike,
>
> On Wed, Mar 21, 2012 at 4:02 PM, Mike <puffy.taco@gmail.com> wrote:
>> I'm having some trouble with MediaEndpoint/MediaTransport and A2DP.
>> When I get the "SetConfiguration" call, I wait 2 seconds and then call
>> "Acquire", generally giving BlueZ enough time get the D-Bus interface
>> ready to go.  However, the delay isn't always long enough.  Shown
>> below is a time when my phone is attempting to pair with BlueZ.  The
>> error "org.bluez.Error.NotAuthorized" is output from my application.
>> In this case, the problem is that the audio source is still in the
>> CONFIGURED state, not in the OPEN state.  Is there a recommended
>> method of how long to wait before calling acquire?  Or should I rely
>> on the AudioSource "State" property to become connected (or playing)?
>> Is there any reason I can't get the transport when in the Configured
>> state (does the fd not exist yet?)?  Or why is "a2dp_resume" being
>> called on open (which is what is rejecting my acquire call)?
>
> In case of PA we do wait for Audio.Connected property before loading
> the module which does call MediaTransport.Acquire, but 2 seconds is
> too much there might be something else holding the setup, do you reply
> right away the SetConfiguration, if you do try to Acquire while
> bluetoothd is waiting you to reply it might fail.
>

Going back to this idea, it seems like MediaTransport should be
redesigned to push the file descriptor to the endpoint, rather than
the endpoint having to request it from the transport.  this would
solve this issue.  The main problem is that acquiring the endpoint
forces a call to resume.  In the case of HFP, this is bad.  I'm
currently needing to implement HFP "Audio Connection Transfer Towards
the AG".  Since I am the HS, all I need to do is drop the SCO
connection -- however, there is no interface to do this well.  I tried
implementing an SCO endpoint, since at least then the acquire and
release calls would bring up an SCO connection and then allow me to
drop it.  The issue here is that a phone that is connected via HFP
will have a MediaTransport even though the SCO connection will not yet
exist.  So, I get the SetConfiguration call which means I should be
good to go on calling acquire.  But, if I call acquire now, it will
create a useless SCO connection to my phone that then is dropped.
There's no reason at this point to open the SCO connection.  I would
rather be notified when the SCO connection exists, and have two
additional methods called suspend and resume.  In the case of HFP,
calling resume would eventually result in a new FD being pushed to me.

Re: media transport -- when is acquire ok to call?

[Luiz Augusto von Dentz]

Hi Mike,

On Fri, Mar 23, 2012 at 2:51 PM, Mike <puffy.taco@gmail.com> wrote:
>
> Going back to this idea, it seems like MediaTransport should be
> redesigned to push the file descriptor to the endpoint, rather than
> the endpoint having to request it from the transport.  this would
> solve this issue.  The main problem is that acquiring the endpoint
> forces a call to resume.  In the case of HFP, this is bad.  I'm
> currently needing to implement HFP "Audio Connection Transfer Towards
> the AG".  Since I am the HS, all I need to do is drop the SCO
> connection -- however, there is no interface to do this well.  I tried
> implementing an SCO endpoint, since at least then the acquire and
> release calls would bring up an SCO connection and then allow me to
> drop it.  The issue here is that a phone that is connected via HFP
> will have a MediaTransport even though the SCO connection will not yet
> exist.  So, I get the SetConfiguration call which means I should be
> good to go on calling acquire.  But, if I call acquire now, it will
> create a useless SCO connection to my phone that then is dropped.
> There's no reason at this point to open the SCO connection.  I would
> rather be notified when the SCO connection exists, and have two
> additional methods called suspend and resume.  In the case of HFP,
> calling resume would eventually result in a new FD being pushed to me.

Pushing maybe a good idea in case of not being the initiator the
connection as you mentioned, in the other hand the endpoint may not be
ready, or willing to use the fd, at that point so I would only signal
that it is now available, otherwise the concept of using it on-demand
in broken. Btw, this already is possible if you listen to
Headset.State, also the interface was designed to have the connection
on-demand, so you should only call Acquire when you gonna use the fd,
anyway even in the case of audio transfer you maybe the initiator and
should be able to directly control the connection via Acquire/Release
to be able to do that so Resume/Suspend would not be that great even
for IVI/carkit systems.



-- 
Luiz Augusto von Dentz

Re: media transport -- when is acquire ok to call?

[Luiz Augusto von Dentz]

Hi Mike,

On Fri, Mar 23, 2012 at 12:30 PM, Mike <puffy.taco@gmail.com> wrote:
> It does appear to trigger based on the signalling channel, however it
> appears that the connection process continues on regardless.  I pasted
> below a log, everything in the log occurs while my phone is still
> asking me if I want to pair with the BlueZ device.  We don't get
> beyond the OPEN_CMD into an actual OPEN state until the pairing
> process completes.

Why don't you pair it before hand, actually this should happen only
once in the first time you pair and then it should be stored
persistently so the next time you wont see this problem.

>> 60 seconds is way too long, it should be at least smaller than D-Bus
>> default timeout which is 25 sec.
>
> What exactly is this timeout waiting for?  I haven't figured that out
> yet.  I assume it's waiting on something from my phone (the a2dp
> source) and not D-Bus?

The client is would be waiting the reply of Acquire, so if you setup
something over D-Bus timeout there is a chance the device respond
correctly but the client will ignored because the method call already
timed out.

-- 
Luiz Augusto von Dentz

Re: media transport -- when is acquire ok to call?

[Mike]

Hi Luiz,

On Mon, Mar 26, 2012 at 10:01 AM, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> Hi Mike,
>
> On Fri, Mar 23, 2012 at 12:30 PM, Mike <puffy.taco@gmail.com> wrote:
>> It does appear to trigger based on the signalling channel, however it
>> appears that the connection process continues on regardless.  I pasted
>> below a log, everything in the log occurs while my phone is still
>> asking me if I want to pair with the BlueZ device.  We don't get
>> beyond the OPEN_CMD into an actual OPEN state until the pairing
>> process completes.
>
> Why don't you pair it before hand, actually this should happen only
> once in the first time you pair and then it should be stored
> persistently so the next time you wont see this problem.

True, but I'm testing all the possible user experiences and that's not
an acceptable solution.  The particular case I'm testing is that the
user deleted the pairing on one end but not the other.  I can't
control what the software on my phone does; I'm only reporting how it
interacts with BlueZ running on my device.  It's true that the next
time the connection occurs (provided we eventually figure out a SEP
lock fix), everything will work just fine.  I'm just trying to figure
out what goes wrong the first time.  So any pointers you have would be
great.

>>> 60 seconds is way too long, it should be at least smaller than D-Bus
>>> default timeout which is 25 sec.
>>
>> What exactly is this timeout waiting for?  I haven't figured that out
>> yet.  I assume it's waiting on something from my phone (the a2dp
>> source) and not D-Bus?
>
> The client is would be waiting the reply of Acquire, so if you setup
> something over D-Bus timeout there is a chance the device respond
> correctly but the client will ignored because the method call already
> timed out.

Well, this case helps out in a time where I didn't call Acquire (the
phone initiated the connection).  So it seems like there should be a
check for pairing before initiating the timer.  I'm not sure how that
would work or what would be needed to make that foolproof.  For my
situation, a much higher timeout was sufficient (I'm not saying that
it should be set to 60 in bluez.git -- just that for me it works).

Re: media transport -- when is acquire ok to call?

[Mike]

Hi Luiz,

On Mon, Mar 26, 2012 at 9:41 AM, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> Hi Mike,
>
> On Fri, Mar 23, 2012 at 2:51 PM, Mike <puffy.taco@gmail.com> wrote:
>>
>> Going back to this idea, it seems like MediaTransport should be
>> redesigned to push the file descriptor to the endpoint, rather than
>> the endpoint having to request it from the transport.  this would
>> solve this issue.  The main problem is that acquiring the endpoint
>> forces a call to resume.  In the case of HFP, this is bad.  I'm
>> currently needing to implement HFP "Audio Connection Transfer Towards
>> the AG".  Since I am the HS, all I need to do is drop the SCO
>> connection -- however, there is no interface to do this well.  I tried
>> implementing an SCO endpoint, since at least then the acquire and
>> release calls would bring up an SCO connection and then allow me to
>> drop it.  The issue here is that a phone that is connected via HFP
>> will have a MediaTransport even though the SCO connection will not yet
>> exist.  So, I get the SetConfiguration call which means I should be
>> good to go on calling acquire.  But, if I call acquire now, it will
>> create a useless SCO connection to my phone that then is dropped.
>> There's no reason at this point to open the SCO connection.  I would
>> rather be notified when the SCO connection exists, and have two
>> additional methods called suspend and resume.  In the case of HFP,
>> calling resume would eventually result in a new FD being pushed to me.
>
> Pushing maybe a good idea in case of not being the initiator the
> connection as you mentioned, in the other hand the endpoint may not be
> ready, or willing to use the fd, at that point so I would only signal
> that it is now available, otherwise the concept of using it on-demand
> in broken.

Isn't that the point of registering an endpoint?  If you have
registered, you are declaring you will accept data.

> Btw, this already is possible if you listen to
> Headset.State, also the interface was designed to have the connection
> on-demand, so you should only call Acquire when you gonna use the fd,
> anyway even in the case of audio transfer you maybe the initiator and
> should be able to directly control the connection via Acquire/Release
> to be able to do that so Resume/Suspend would not be that great even
> for IVI/carkit systems.

So that has me confused.  If the MediaTransport interface is somewhat
generic, why would I want to listen to another interface to know if I
should call Acquire?  In my case, I would need to listen to
HeadsetGateway.  As it is, the audio from my SCO connection is sent
over a PCM bus, so I currently do not even register an SCO endpoint,
because it was not needed.  I agree that if you are the initiator,
Acquire/Release is sufficient.  In my case, as the non-initiator, it
is not sufficient because I do not want to open an audio link by
calling acquire unless it already exists.

My perception is that the interface is written from the point of view
of the audio source (A2DP Audio Source or HFP AG), but this does not
translate as well to the audio sinks (A2DP Audio Sink or HFP HF).

Re: media transport -- when is acquire ok to call?

[Luiz Augusto von Dentz]

Hi Mike,

On Mon, Mar 26, 2012 at 12:44 PM, Mike <puffy.taco@gmail.com> wrote:
> True, but I'm testing all the possible user experiences and that's not
> an acceptable solution.  The particular case I'm testing is that the
> user deleted the pairing on one end but not the other.  I can't
> control what the software on my phone does; I'm only reporting how it
> interacts with BlueZ running on my device.  It's true that the next
> time the connection occurs (provided we eventually figure out a SEP
> lock fix), everything will work just fine.  I'm just trying to figure
> out what goes wrong the first time.  So any pointers you have would be
> great.

So you are deleting the link key on your phone and still initiating
the connection from it, that doesn't sound like a practical case since
by removing the key the phone should no longer remember your device.
Anyway, that seems that something else is broke because the connection
should be authenticated before accepted by userspace, in other words
the signalling channel connection should not be established before the
pairing completes.

>>> What exactly is this timeout waiting for?  I haven't figured that out
>>> yet.  I assume it's waiting on something from my phone (the a2dp
>>> source) and not D-Bus?
>>
>> The client is would be waiting the reply of Acquire, so if you setup
>> something over D-Bus timeout there is a chance the device respond
>> correctly but the client will ignored because the method call already
>> timed out.
>
> Well, this case helps out in a time where I didn't call Acquire (the
> phone initiated the connection).  So it seems like there should be a
> check for pairing before initiating the timer.  I'm not sure how that
> would work or what would be needed to make that foolproof.  For my
> situation, a much higher timeout was sufficient (I'm not saying that
> it should be set to 60 in bluez.git -- just that for me it works).

As I said the use case you are trying does not seem very practical,
and in any case to pass a file descriptor you will need a method call
which inevitably will have a timeout associated.

-- 
Luiz Augusto von Dentz

Re: media transport -- when is acquire ok to call?

[Mike]

Hi Luiz,

On Mon, Mar 26, 2012 at 11:40 AM, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> Hi Mike,
>
> On Mon, Mar 26, 2012 at 12:44 PM, Mike <puffy.taco@gmail.com> wrote:
>> True, but I'm testing all the possible user experiences and that's not
>> an acceptable solution.  The particular case I'm testing is that the
>> user deleted the pairing on one end but not the other.  I can't
>> control what the software on my phone does; I'm only reporting how it
>> interacts with BlueZ running on my device.  It's true that the next
>> time the connection occurs (provided we eventually figure out a SEP
>> lock fix), everything will work just fine.  I'm just trying to figure
>> out what goes wrong the first time.  So any pointers you have would be
>> great.
>
> So you are deleting the link key on your phone and still initiating
> the connection from it, that doesn't sound like a practical case since
> by removing the key the phone should no longer remember your device.
> Anyway, that seems that something else is broke because the connection
> should be authenticated before accepted by userspace, in other words
> the signalling channel connection should not be established before the
> pairing completes.

I'm probably not being clear on the specifics (they are clear in my
head!).  My phone is an old Motorola KRZR K1.  I do not delete the
link key here -- it assumes we're still paired and is attempting to
open the A2DP.  The device it is connecting to uses BlueZ in an HFP HF
role.  It is on this device (BlueZ) that I have deleted the link key.
So, the phone does remember the past pairing and is attempting at
connect as if the two are still paired -- making this a practical
case.  So I agree that something is broken here as to why the process
continues while pairing is occurring.

>>>> What exactly is this timeout waiting for?  I haven't figured that out
>>>> yet.  I assume it's waiting on something from my phone (the a2dp
>>>> source) and not D-Bus?
>>>
>>> The client is would be waiting the reply of Acquire, so if you setup
>>> something over D-Bus timeout there is a chance the device respond
>>> correctly but the client will ignored because the method call already
>>> timed out.
>>
>> Well, this case helps out in a time where I didn't call Acquire (the
>> phone initiated the connection).  So it seems like there should be a
>> check for pairing before initiating the timer.  I'm not sure how that
>> would work or what would be needed to make that foolproof.  For my
>> situation, a much higher timeout was sufficient (I'm not saying that
>> it should be set to 60 in bluez.git -- just that for me it works).

The timeout of 2 seconds is just fine when the two devices are paired.
 I only run into this issue of crashing my phone when the BlueZ device
deletes the pairing.  I'm sure it's my phone's fault for crashing, but
fixing the upper issue will fix this as well.

Mike

Re: media transport -- when is acquire ok to call?

[Luiz Augusto von Dentz]

Hi Mike,

On Mon, Mar 26, 2012 at 1:10 PM, Mike <puffy.taco@gmail.com> wrote:
>> Pushing maybe a good idea in case of not being the initiator the
>> connection as you mentioned, in the other hand the endpoint may not be
>> ready, or willing to use the fd, at that point so I would only signal
>> that it is now available, otherwise the concept of using it on-demand
>> in broken.
>
> Isn't that the point of registering an endpoint?  If you have
> registered, you are declaring you will accept data.

The endpoint takes care of the configuration, it doesn't mean you need
to Acquire the file descriptor, actually you should only acquire if
you are going to use it, so even if the phone connects and open the
SCO connection it doesn't mean you should pickup it right away since
different policies/routing might be implemented.

>> Btw, this already is possible if you listen to
>> Headset.State, also the interface was designed to have the connection
>> on-demand, so you should only call Acquire when you gonna use the fd,
>> anyway even in the case of audio transfer you maybe the initiator and
>> should be able to directly control the connection via Acquire/Release
>> to be able to do that so Resume/Suspend would not be that great even
>> for IVI/carkit systems.
>
> So that has me confused.  If the MediaTransport interface is somewhat
> generic, why would I want to listen to another interface to know if I
> should call Acquire?  In my case, I would need to listen to
> HeadsetGateway.  As it is, the audio from my SCO connection is sent
> over a PCM bus, so I currently do not even register an SCO endpoint,
> because it was not needed.  I agree that if you are the initiator,
> Acquire/Release is sufficient.  In my case, as the non-initiator, it
> is not sufficient because I do not want to open an audio link by
> calling acquire unless it already exists.

That is a broken design, PCM routing also needs proper endpoint
otherwise it is impossible to implement routing policies since the
audio is transparently routed, it only works if you have a single
purpose device. Also please pay attention that with audio transfer you
may be the initiator of SCO connection even in case of IVI/carkit
role.

> My perception is that the interface is written from the point of view
> of the audio source (A2DP Audio Source or HFP AG), but this does not
> translate as well to the audio sinks (A2DP Audio Sink or HFP HF).

Nope it should works in both cases, it only assumes that the endpoint
need to know when it should Acquire the file descriptor not bluetoothd
should push the file descriptor. Anyway I still believe pull is
better, because the client may not be ready or block (using threads)
and it know better when it needs the fd.

-- 
Luiz Augusto von Dentz

RE: media transport -- when is acquire ok to call?

[Mikel Astiz]

Hi Mike,
 
> So that has me confused.  If the MediaTransport interface is somewhat
> generic, why would I want to listen to another interface to know if I
> should call Acquire?  In my case, I would need to listen to
> HeadsetGateway.  As it is, the audio from my SCO connection is sent
> over a PCM bus, so I currently do not even register an SCO endpoint,
> because it was not needed.  I agree that if you are the initiator,
> Acquire/Release is sufficient.  In my case, as the non-initiator, it is
> not sufficient because I do not want to open an audio link by calling
> acquire unless it already exists.

I'm not sure if this solves your specific problem(s) but I would propose that the MediaTransport API is extended with a method such as TryAcquire (or alternatively Acquire can be extended with either one more parameter, or some specific flag in accesstype). In that case the transport would not be acquired unless the audio link already exists.

The current approach of listening to a state property and then calling Acquire is racy, no matter if the property is in the same interface or not.

Regarding your comment on the need to listen to a different interface, I don't think this should be a big problem. Having said that, the Playing state in HeadsetGateway (and equivalents) could be replaced by a state in MediaTransport. That actually seems more appropriate to me.

Cheers,
Mikel

Re: media transport -- when is acquire ok to call?

[Mike]

Hi Mikel,

On Tue, Mar 27, 2012 at 1:31 AM, Mikel Astiz <Mikel.Astiz@bmw-carit.de> wrote:
> Hi Mike,
>
>> So that has me confused.  If the MediaTransport interface is somewhat
>> generic, why would I want to listen to another interface to know if I
>> should call Acquire?  In my case, I would need to listen to
>> HeadsetGateway.  As it is, the audio from my SCO connection is sent
>> over a PCM bus, so I currently do not even register an SCO endpoint,
>> because it was not needed.  I agree that if you are the initiator,
>> Acquire/Release is sufficient.  In my case, as the non-initiator, it is
>> not sufficient because I do not want to open an audio link by calling
>> acquire unless it already exists.
>
> I'm not sure if this solves your specific problem(s) but I would propose that the MediaTransport API is extended with a method such as TryAcquire (or alternatively Acquire can be extended with either one more parameter, or some specific flag in accesstype). In that case the transport would not be acquired unless the audio link already exists.
>
> The current approach of listening to a state property and then calling Acquire is racy, no matter if the property is in the same interface or not.

I think your proposal would fix this race in a way that doesn't
fundamentally change the current design, so I'm in favor of it.

> Regarding your comment on the need to listen to a different interface, I don't think this should be a big problem. Having said that, the Playing state in HeadsetGateway (and equivalents) could be replaced by a state in MediaTransport. That actually seems more appropriate to me.

Agreed. The reason I don't like the current approach is that there is
no explicit connection between the MediaTransport object and the other
object that has the state property.

Mike

AW: media transport -- when is acquire ok to call?

[Mikel Astiz]

Hi Luiz,

> Hi Mikel,
> 
> On Tue, Mar 27, 2012 at 1:31 AM, Mikel Astiz <Mikel.Astiz@bmw-carit.de>
> wrote:
> > Hi Mike,
> >
> >> So that has me confused.  If the MediaTransport interface is somewhat
> >> generic, why would I want to listen to another interface to know if I
> >> should call Acquire?  In my case, I would need to listen to
> >> HeadsetGateway.  As it is, the audio from my SCO connection is sent
> >> over a PCM bus, so I currently do not even register an SCO endpoint,
> >> because it was not needed.  I agree that if you are the initiator,
> >> Acquire/Release is sufficient.  In my case, as the non-initiator, it
> >> is not sufficient because I do not want to open an audio link by
> >> calling acquire unless it already exists.
> >
> > I'm not sure if this solves your specific problem(s) but I would propose that
> the MediaTransport API is extended with a method such as TryAcquire (or
> alternatively Acquire can be extended with either one more parameter, or
> some specific flag in accesstype). In that case the transport would not be
> acquired unless the audio link already exists.
> >
> > The current approach of listening to a state property and then calling
> Acquire is racy, no matter if the property is in the same interface or not.
> 
> I think your proposal would fix this race in a way that doesn't fundamentally
> change the current design, so I'm in favor of it.
> 
> > Regarding your comment on the need to listen to a different interface, I
> don't think this should be a big problem. Having said that, the Playing state in
> HeadsetGateway (and equivalents) could be replaced by a state in
> MediaTransport. That actually seems more appropriate to me.
> 
> Agreed. The reason I don't like the current approach is that there is no
> explicit connection between the MediaTransport object and the other object
> that has the state property.
> 
> Mike

The issue above could be briefly discussed next week as well.

Cheers,
Mikel