Hi,
I'm using the new bluez media api to set bluetooth headsets into
playing mode and get the fd's of the corresponding sockets with a
program written in C. This works fine with just one headset, but I'm
using up to three at the same time over three bluetooth adapters. So
my program (bt-audio) creates a dbus-service with three paths
(/test/endpoint0, ...1, ...2) and each path has an interface
org.bluez.MediaEndpoint with the four needed methods
(SetConfiguration etc.). Then it scans for turned on headsets and
calls RegisterEndpoint on the appropriate adapter-path. Then bluez
calls three times SetConfiguration on my service. So basically like
in the python-example "simple-endpoint". After that my app calls
three times Acquire with "rw" on each of the given transport-paths to
receive the socket-fd's.
As I said, this works well and I can play and record some raw-files
with very good quality. But when one of the headsets is turned off,
the other two are put out of playing-mode. When I retry to put them
back in playing-mode by calling UnregisterEndpoint and then
RegisterEndpoint again, I just get
"GDBus.Error:org.bluez.Error.NotAuthorized: Operation Not Authorized"
and see "sco_bind: Address already in use" in syslog. When retrying
too often, bluetoothd segfaults (but this may be related to the way i
tried some recovery of this problem in my code) with:
kernel: [34309.873606] bluetoothd[29235]: segfault at 6e652f74 ip
b76b9b20 sp bf93c430 error 4 in bluetoothd[b768c000+7e000]
Only after restarting my program (and thus re-registering my
dbus-service), I am able to put the headsets back in playing mode again.
I also tried this use-case with your simple-endpoint python-script by
modifying it like this:
def acquire_cb(fd, imtu, omtu):
print "Acquire successfull! New fd: %s with iMTU %i and oMTU %i" %
(fd, imtu, omtu)
def acquire_error(error):
print "Acquire failed: %s" % (error)
mainloop.quit()
...
@dbus.service.method("org.bluez.MediaEndpoint", in_signature="oay",
out_signature="")
def SetConfiguration(self, transport, config):
print "SetConfiguration (%s, %s)" % (transport, config)
media_transport = dbus.Interface(bus.get_object("org.bluez",
transport), "org.bluez.MediaTransport")
media_transport.Acquire("rw", reply_handler=acquire_cb,
error_handler=acquire_error)
return
So even after starting two or three processes of this script (each
with a different hciX), I get the same behaviour: putting all
headsets in playing mode is no problem, but turning off one headset
puts the others out of playing mode. Trying to put them back in
playing mode requires a restart of the scripts, otherwise I just get
the same error: "Acquire failed: org.bluez.Error.NotAuthorized:
Operation Not Authorized".
So why are the other headsets always put out of playing mode and why
can't you put them back in playing mode again? Looks like a bug to
me, hopefully someone of you can help. I attached the syslog cutout
of this problem, too (first section is with my C-program, second with
the python-script).
Thanks,
Peter
Hi,
At 00:16 29.06.2011, Lukasz Rymanowski wrote:
>Hi Luiz,
>
>On Tue, Jun 28, 2011 at 11:48 PM, Luiz Augusto von Dentz
><[email protected]> wrote:
> > Hi Lukasz,
> >
> > On Tue, Jun 28, 2011 at 11:07 PM, Lukasz Rymanowski
> > <[email protected]> wrote:
> >> Hi Peter,
> >>
> >> Can you try attached patch ?
> >> At least you should not lose audio on all the headsets when
> >> disconnecting one of them.
> >
> > Good catch, the headset watch is not registered per device so we have
> > to do the matching inside the callback like you did, one thing that
> > perhaps is worth doing is to make the matching before the switch so if
> > the endpoint has a device then we match it with the device given to
> > the callback.
>
>I thought about it but we can do matching only if transport exist.
>Second thing is that in state HEADSET_STATE_CONNECTING we are actually
>interested to do something if transport does not exist yet (look into
>media_endpoint_set_configuration() )
>So it looks like different states have different approach.
>Anyway, let's wait for test result.
OK, so the disconnect problem is fixed with the patch. So when one
headset disconnects, the other ones stay in playing mode.
But there are still some issues with (re)connecting headsets into playing mode:
1. When there are at least two "free" endpoints registered and a
headset connects, you get an "Operation Not Authorized" (with the
simple-endpoint script and with my C-code) and a bluetoothd segfault
(just with the simple-endpoint script) when you try to call "Acquire"
to put the headset in playing mode and get the fd.
For example: Register 3 endpoints with the script by modifying it like this:
path1 = manager.FindAdapter(sys.argv[1])
media1 = dbus.Interface(bus.get_object("org.bluez", path1),
"org.bluez.Media")
path1 = "/test/endpoint1"
endpoint1 = Endpoint(bus, path1)
path2 = manager.FindAdapter(sys.argv[2])
media2 = dbus.Interface(bus.get_object("org.bluez", path2),
"org.bluez.Media")
path2 = "/test/endpoint2"
endpoint2 = Endpoint(bus, path2)
path3 = manager.FindAdapter(sys.argv[3])
media3 = dbus.Interface(bus.get_object("org.bluez", path3),
"org.bluez.Media")
path3 = "/test/endpoint3"
endpoint3 = Endpoint(bus, path3)
mainloop = gobject.MainLoop()
properties = dbus.Dictionary({ "UUID" : HFP_AG_UUID, "Codec"
: PCM_CODEC, "Capabilities" : PCM_CONFIGURATION })
print properties
media1.RegisterEndpoint(path1, properties)
media2.RegisterEndpoint(path2, properties)
media3.RegisterEndpoint(path3, properties)
mainloop.run()
Don't forget to add calling "Acquire" in SetConfiguration like this
(see my first mail):
media_transport = dbus.Interface(bus.get_object("org.bluez",
transport), "org.bluez.MediaTransport")
media_transport.Acquire("rw", reply_handler=acquire_cb,
error_handler=acquire_error)
Then connect a headset and you get:
./simple-endpoint hci0 hci1 hci2
dbus.Dictionary({'Codec': dbus.Byte(0), 'UUID':
'0000111F-0000-1000-8000-00805F9B34FB', 'Capabilities':
dbus.Array([], signature=dbus.Signature('ay'))}, signature=None)
SetConfiguration (/org/bluez/7917/hci0/dev_00_23_7F_45_2A_6C/fd0,
dbus.Dictionary({dbus.String(u'NREC'): dbus.Boolean(True,
variant_level=1), dbus.String(u'UUID'):
dbus.String(u'0000111F-0000-1000-8000-00805F9B34FB',
variant_level=1), dbus.String(u'InbandRingtone'): dbus.Boolean(True,
variant_level=1), dbus.String(u'Codec'): dbus.Byte(0,
variant_level=1), dbus.String(u'Routing'): dbus.String(u'HCI',
variant_level=1), dbus.String(u'Device'):
dbus.ObjectPath('/org/bluez/7917/hci0/dev_00_23_7F_45_2A_6C',
variant_level=1), dbus.String(u'Configuration'): dbus.Array([],
signature=dbus.Signature('y'), variant_level=1)},
signature=dbus.Signature('sv')))
SetConfiguration (/org/bluez/7917/hci0/dev_00_23_7F_45_2A_6C/fd1,
dbus.Dictionary({dbus.String(u'NREC'): dbus.Boolean(True,
variant_level=1), dbus.String(u'UUID'):
dbus.String(u'0000111F-0000-1000-8000-00805F9B34FB',
variant_level=1), dbus.String(u'InbandRingtone'): dbus.Boolean(True,
variant_level=1), dbus.String(u'Codec'): dbus.Byte(0,
variant_level=1), dbus.String(u'Routing'): dbus.String(u'HCI',
variant_level=1), dbus.String(u'Device'):
dbus.ObjectPath('/org/bluez/7917/hci0/dev_00_23_7F_45_2A_6C',
variant_level=1), dbus.String(u'Configuration'): dbus.Array([],
signature=dbus.Signature('y'), variant_level=1)},
signature=dbus.Signature('sv')))
SetConfiguration (/org/bluez/7917/hci0/dev_00_23_7F_45_2A_6C/fd2,
dbus.Dictionary({dbus.String(u'NREC'): dbus.Boolean(True,
variant_level=1), dbus.String(u'UUID'):
dbus.String(u'0000111F-0000-1000-8000-00805F9B34FB',
variant_level=1), dbus.String(u'InbandRingtone'): dbus.Boolean(True,
variant_level=1), dbus.String(u'Codec'): dbus.Byte(0,
variant_level=1), dbus.String(u'Routing'): dbus.String(u'HCI',
variant_level=1), dbus.String(u'Device'):
dbus.ObjectPath('/org/bluez/7917/hci0/dev_00_23_7F_45_2A_6C',
variant_level=1), dbus.String(u'Configuration'): dbus.Array([],
signature=dbus.Signature('y'), variant_level=1)},
signature=dbus.Signature('sv')))
Acquire failed: org.bluez.Error.NotAuthorized: Operation Not Authorized
In addition, bluetoothd segfaults: bluetoothd[7917]: segfault at 4d
ip b7589e11 sp bfe4f190 error 4 in libdbus-1.so.3.5.5[b7576000+3c000]
With my C-code I also get "Operation Not Authorized", but not the
segfault. See attached logs "hs_connect_python_onp.syslog" and
"hs_connect_c_onp.syslog".
2. This problem occurs just in my C-code: There are 3 endpoints and 3
headsets are in playing mode. I turn off 1 headset, it disconnects
and after some time I turn it on again. It reconnects and is
automatically put back in playing mode because bluez calls
SetConfiguration (probably because there is only 1 "free" endpoint it
calls on the right one) and there "Acquire" is called and the headset
goes into playing mode. At least this is how it works with the
simple-endpoint script (log for that ist
"hs_reconnect_python.syslog"). But in my C-code (although it makes
exactly the same as the python-script), I always get
"bluetoothd[28181]: sco_bind: Address already in use (98)" (see
"hs_reconnect_c.syslog"). Only when trying to put it in playing mode
for the first time after application start it works fine. Any ideas?
> >
> >
> > --
> > Luiz Augusto von Dentz
> >
>
>/Lukasz
>--
Thanks,
Peter
Hi Luiz,
On Tue, Jun 28, 2011 at 11:48 PM, Luiz Augusto von Dentz
<[email protected]> wrote:
> Hi Lukasz,
>
> On Tue, Jun 28, 2011 at 11:07 PM, Lukasz Rymanowski
> <[email protected]> wrote:
>> Hi Peter,
>>
>> Can you try attached patch ?
>> At least you should not lose audio on all the headsets when
>> disconnecting one of them.
>
> Good catch, the headset watch is not registered per device so we have
> to do the matching inside the callback like you did, one thing that
> perhaps is worth doing is to make the matching before the switch so if
> the endpoint has a device then we match it with the device given to
> the callback.
I thought about it but we can do matching only if transport exist.
Second thing is that in state HEADSET_STATE_CONNECTING we are actually
interested to do something if transport does not exist yet (look into
media_endpoint_set_configuration() )
So it looks like different states have different approach.
Anyway, let's wait for test result.
>
>
> --
> Luiz Augusto von Dentz
>
/Lukasz
Hi Lukasz,
On Tue, Jun 28, 2011 at 11:07 PM, Lukasz Rymanowski
<[email protected]> wrote:
> Hi Peter,
>
> Can you try attached patch ?
> At least you should not lose audio on all the headsets when
> disconnecting one of them.
Good catch, the headset watch is not registered per device so we have
to do the matching inside the callback like you did, one thing that
perhaps is worth doing is to make the matching before the switch so if
the endpoint has a device then we match it with the device given to
the callback.
--
Luiz Augusto von Dentz
Hi Peter,
Can you try attached patch ?
At least you should not lose audio on all the headsets when
disconnecting one of them.
\Lukasz
Hi Luiz,
At 08:49 23.06.2011, Luiz Augusto von Dentz wrote:
>Hi Peter,
>
>On Thu, Jun 23, 2011 at 12:23 AM, Peter Kornatowski <[email protected]> wrote:
> > Hi,
> >
> > I'm using the new bluez media api to set bluetooth headsets into playing
> > mode and get the fd's of the corresponding sockets with a program
> written in
> > C. This works fine with just one headset, but I'm using up to three at the
> > same time over three bluetooth adapters. So my program (bt-audio) creates a
> > dbus-service with three paths (/test/endpoint0, ...1, ...2) and each path
> > has an interface org.bluez.MediaEndpoint with the four needed methods
> > (SetConfiguration etc.). Then it scans for turned on headsets and calls
> > RegisterEndpoint on the appropriate adapter-path. Then bluez calls three
> > times SetConfiguration on my service. So basically like in the
> > python-example "simple-endpoint". After that my app calls three times
> > Acquire with "rw" on each of the given transport-paths to receive the
> > socket-fd's.
> > As I said, this works well and I can play and record some raw-files with
> > very good quality. But when one of the headsets is turned off,
> the other two
> > are put out of playing-mode. When I retry to put them back in playing-mode
> > by calling UnregisterEndpoint and then RegisterEndpoint again, I just get
> > "GDBus.Error:org.bluez.Error.NotAuthorized: Operation Not Authorized" and
> > see "sco_bind: Address already in use" in syslog. When retrying too often,
> > bluetoothd segfaults (but this may be related to the way i tried some
> > recovery of this problem in my code) with:
> > kernel: [34309.873606] bluetoothd[29235]: segfault at 6e652f74 ip b76b9b20
> > sp bf93c430 error 4 in bluetoothd[b768c000+7e000]
> >
> > Only after restarting my program (and thus re-registering my dbus-service),
> > I am able to put the headsets back in playing mode again.
> >
> > I also tried this use-case with your simple-endpoint python-script by
> > modifying it like this:
> >
> > def acquire_cb(fd, imtu, omtu):
> > print "Acquire successfull! New fd: %s with iMTU %i and oMTU %i" %
> > (fd, imtu, omtu)
> > def acquire_error(error):
> > print "Acquire failed: %s" % (error)
> > mainloop.quit()
> >
> > ...
> >
> > @dbus.service.method("org.bluez.MediaEndpoint", in_signature="oay",
> > out_signature="")
> > def SetConfiguration(self, transport, config):
> > print "SetConfiguration (%s, %s)" % (transport, config)
> > media_transport = dbus.Interface(bus.get_object("org.bluez",
> > transport), "org.bluez.MediaTransport")
> > media_transport.Acquire("rw", reply_handler=acquire_cb,
> > error_handler=acquire_error)
> > return
> >
> > So even after starting two or three processes of this script (each with a
> > different hciX), I get the same behaviour: putting all headsets in playing
> > mode is no problem, but turning off one headset puts the others out of
> > playing mode. Trying to put them back in playing mode requires a restart of
> > the scripts, otherwise I just get the same error: "Acquire failed:
> > org.bluez.Error.NotAuthorized: Operation Not Authorized".
> >
> > So why are the other headsets always put out of playing mode and why can't
> > you put them back in playing mode again? Looks like a bug to me, hopefully
> > someone of you can help. I attached the syslog cutout of this problem, too
> > (first section is with my C-program, second with the python-script).
>
>Interesting, this could be a bug in SCO socket can you try that with
>a2dp too? In the meantime I gonna try to reproduce it myself, btw what
>kernel are you using?
>
>--
>Luiz Augusto von Dentz
>--
I'm using Debian with kernel 2.6.32-5.
I tried to reproduce the problem with a2dp, but got stuck before
getting a headset into playing mode. Tried it with two different
headsets (both a2dp capable), connected them through all different
interfaces (headset, audio, audiosink) and always got the the
headsets into connected state. But then after starting the
simple-endpoint script for sbcsource or mp3source, the dbus-service
registered with path /test/endpoint, but bluez didn't call
SetConfiguration, so I couldn't call "Acquire" because the interface
and the fdX path weren't there (checked with d-feet, too). The only
stuff i got from syslog (with bluetoothd -d) was:
Jun 27 19:35:49 peter bluetoothd[27327]:
audio/avdtp.c:avdtp_register_sep() SEP 0xb8b2e1a8 registered: type:0
codec:1 seid:2
Jun 27 19:35:49 peter bluetoothd[27327]: Endpoint registered:
sender=:1.673 path=/test/endpoint
When trying to start the simple-endpoint script with sbcsink or
mp3sink, all I got was:
dbus.exceptions.DBusException: org.bluez.Error.NotSupported:
Operation is not supported
So, what am I missing? Have you tried to reproduce the bug with hfp?
Best regards,
Peter
Hi Peter,
On Thu, Jun 23, 2011 at 12:23 AM, Peter Kornatowski <[email protected]> wrote:
> Hi,
>
> I'm using the new bluez media api to set bluetooth headsets into playing
> mode and get the fd's of the corresponding sockets with a program written in
> C. This works fine with just one headset, but I'm using up to three at the
> same time over three bluetooth adapters. So my program (bt-audio) creates a
> dbus-service with three paths (/test/endpoint0, ...1, ...2) and each path
> has an interface org.bluez.MediaEndpoint with the four needed methods
> (SetConfiguration etc.). Then it scans for turned on headsets and calls
> RegisterEndpoint on the appropriate adapter-path. Then bluez calls three
> times SetConfiguration on my service. So basically like in the
> python-example "simple-endpoint". After that my app calls three times
> Acquire with "rw" on each of the given transport-paths to receive the
> socket-fd's.
> As I said, this works well and I can play and record some raw-files with
> very good quality. But when one of the headsets is turned off, the other two
> are put out of playing-mode. When I retry to put them back in playing-mode
> by calling UnregisterEndpoint and then RegisterEndpoint again, I just get
> "GDBus.Error:org.bluez.Error.NotAuthorized: Operation Not Authorized" and
> see "sco_bind: Address already in use" in syslog. When retrying too often,
> bluetoothd segfaults (but this may be related to the way i tried some
> recovery of this problem in my code) with:
> kernel: [34309.873606] bluetoothd[29235]: segfault at 6e652f74 ip b76b9b20
> sp bf93c430 error 4 in bluetoothd[b768c000+7e000]
>
> Only after restarting my program (and thus re-registering my dbus-service),
> I am able to put the headsets back in playing mode again.
>
> I also tried this use-case with your simple-endpoint python-script by
> modifying it like this:
>
> def acquire_cb(fd, imtu, omtu):
> ? ? ? ?print "Acquire successfull! New fd: %s with iMTU %i and oMTU %i" %
> (fd, imtu, omtu)
> def acquire_error(error):
> ? ? ? ?print "Acquire failed: %s" % (error)
> ? ? ? ?mainloop.quit()
>
> ...
>
> @dbus.service.method("org.bluez.MediaEndpoint", in_signature="oay",
> out_signature="")
> def SetConfiguration(self, transport, config):
> ? ? ? ?print "SetConfiguration (%s, %s)" % (transport, config)
> ? ? ? ?media_transport = dbus.Interface(bus.get_object("org.bluez",
> transport), "org.bluez.MediaTransport")
> ? ? ? ?media_transport.Acquire("rw", reply_handler=acquire_cb,
> error_handler=acquire_error)
> ? ? ? ?return
>
> So even after starting two or three processes of this script (each with a
> different hciX), I get the same behaviour: putting all headsets in playing
> mode is no problem, but turning off one headset puts the others out of
> playing mode. Trying to put them back in playing mode requires a restart of
> the scripts, otherwise I just get the same error: "Acquire failed:
> org.bluez.Error.NotAuthorized: Operation Not Authorized".
>
> So why are the other headsets always put out of playing mode and why can't
> you put them back in playing mode again? Looks like a bug to me, hopefully
> someone of you can help. I attached the syslog cutout of this problem, too
> (first section is with my C-program, second with the python-script).
Interesting, this could be a bug in SCO socket can you try that with
a2dp too? In the meantime I gonna try to reproduce it myself, btw what
kernel are you using?
--
Luiz Augusto von Dentz
At 00:07 12.07.2011, Peter Kornatowski wrote:
>At 21:43 08.07.2011, Peter Kornatowski wrote:
>>Hi Luiz,
>>
>>At 12:08 08.07.2011, Luiz Augusto von Dentz wrote:
>>>Hi Peter,
>>>
>>>On Thu, Jul 7, 2011 at 10:57 PM, Peter Kornatowski <[email protected]> wrote:
>>> > I'm calling Acquire when SetConfiguration is called by bluez
>>> (isn't that the
>>> > correct spot, cause there you get the transport path?). I
>>> attached the whole
>>> > modified script, so you can see exactly what I'm doing.
>>>
>>>As I explained in the last email you have to reply to the
>>>SetConfiguration before you are able to do Acquire, that is on purpose
>>>to avoid a possible deadlock where you are the application is waiting
>>>for Acquire to complete but bluetoothd is waiting the application to
>>>reply to SetConfiguration, bluetoothd won't block but the application
>>>may block trying to Acquire and by doing that it is not able to reply
>>>to SetConfiguration.
>>
>>This is why I'm calling Acquire asynchronously. But ok, I will test
>>it with a postponed Acquire.
>
>Tested it with a seperate python-script for calling Acquire
>(attached it). Modified the previous script so that it doesn't call
>Acquire anymore.
>So when registering two endpoints and connecting one headset, I see
>bluez calling SetConfiguration for both endpoints (so two transport
>paths with just different fdX at the end). I then call Acquire with
>the new script for one endpoint at get the headset into playing mode
>every time. When trying to call Acquire for the second headset I
>always get Operation Not Authorized (which is fine I guess, but the
>second SetConfiguration call in the first place is not). When
>stopping this last scquire-script with ctrl+c (just the one that
>produced Operation Not Authorized), bluetoothd always segfaults.
>Stopping the other acquire-script or the endpoint-dual doesn't
>segfault bluetoothd. I could reproduce this with my C code as well.
>
>Also with endpoint and Acquire being in two different scripts I
>could play around a little and found out that starting more
>endpoints than there are connected headsets is not a good idea, even
>when you don't call Acquire. So to workaround this behaviour I have
>to wait for a headset to connect, then register just one endpoint
>for it and call Acquire. For the next headset that connects I have
>to do the same. And when a headset disconnects, the endpoint has to
>be unregistered and closed as well. Or is this the intended way of
>doing it anyway?
OK, so I implemented it this way and I don't get Operation Not
Authorized or bluetoothd segfaults anymore. But I still have the
"sco_bind: Address in use" problem I wrote about some e-mails ago.
The first time I call Acquire for each headset it works fine, but
after disconnecting and reconnecting a headset it always ends with
the error message. And I even unregister and re-register the endpoint
object. And the error message sounds like there is a problem with the
socket, but I thought binding and releasing the socket is handled
internally by bluez and not by the media api. On the other hand, I
couldn't reproduce the problem with any of the python scripts...
I attached the syslog and hopefully someone will see something
unusual. Because I tried out stuff for many hours and just can't get
it to work. This is the way I implemented it roughly (just the main
dbus functions):
After headset connect:
g_dbus_connection_register_object(service_connection,
"/test/endpoint1", introspection_data->interfaces[0],
&interface_vtable, NULL, NULL, &error);
g_dbus_proxy_new_sync(bluez_connection, G_DBUS_PROXY_FLAGS_NONE,
NULL, "org.bluez", adapter_path, "org.bluez.Media", NULL, &error);
g_dbus_proxy_call(bluez_media_proxy, "RegisterEndpoint", props,
G_DBUS_CALL_FLAGS_NONE, -1, NULL, (GAsyncReadyCallback)reg_ep_cb, NULL);
Then SetConfiguration is called by bluez, and there I call:
g_dbus_method_invocation_return_value(invocation, NULL);
g_dbus_proxy_new_for_bus_sync(G_BUS_TYPE_SYSTEM,
G_DBUS_PROXY_FLAGS_NONE, NULL, "org.bluez", transport_path,
"org.bluez.MediaTransport", NULL, &error);
g_dbus_message_new_method_call("org.bluez", transport_path,
"org.bluez.MediaTransport", "Acquire");
g_dbus_message_set_body(method_call_message, g_variant_new("(s)", "rw"));
g_dbus_connection_send_message_with_reply(media_transport_connection,
method_call_message, G_DBUS_SEND_MESSAGE_FLAGS_NONE, -1, NULL, NULL,
acquire_cb, NULL);
Then in the acquire_cb I get the file descriptor (at least for the
first time this headset connects).
When a headset disconnects, I call:
g_dbus_proxy_call(media_transport, "Release", g_variant_new("(s)",
"rw"), G_DBUS_CALL_FLAGS_NONE, -1, NULL,
(GAsyncReadyCallback)release_cb, NULL);
g_dbus_proxy_call(bluez_media, "UnregisterEndpoint",
g_variant_new("(o)", "/test/endpoint1"), G_DBUS_CALL_FLAGS_NONE, -1,
NULL, (GAsyncReadyCallback)unreg_ep_cb, NULL);
g_dbus_connection_unregister_object(service_connection, registration_id);
Any hints are appreciated.
Thanks,
Peter
>>> > It also works for the first headset or if all headsets are in
>>> connected mode
>>> > and you start the script, so generally it should be ok.
>>> > But it doesn't work if you start the script and then connect the first
>>> > headset (or start the script after just one headset is in
>>> connected mode).
>>> > Then the headset gets into playing mode, but bluez tries to put it into
>>> > playing mode on the other endpoint, too (at least it looks that way to me
>>> > cause SetConfiguration is being called twice). So then Acquire is being
>>> > called twice, too. For one call I get the file descriptor, but
>>> for the other
>>> > call I get "Operation Not Authorized". Maybe because the second
>>> > SetConfiguration is called for the other endpoint, which is on the other
>>> > adapter with which the headset is not paired (each headset is only paired
>>> > with one adapter). On the other hand, the transport path from both
>>> > SetConfiguration calls is for the same adapter... But when you
>>> then connect
>>> > the second headset (which is paired with the other adapter),
>>> bluez doesn't
>>> > call SetConfiguration for it (probably because this endpoint is still
>>> > "blocked" by the first headset, but it shouldn't be).
>>>
>>>The Operation Not Authorized in because you didn't reply to
>>>SetConfiguration, also bluetoothd will try to match the profile
>>>capabilities with the endpoint capabilities and then call
>>>SetConfiguration to the endpoint to confirm if it is able to handle
>>>the transport, in theory I don't see any problem to the same endpoint
>>>to get multiple SetConfiguration as long it is for different devices,
>>>but perhaps we need to limit to only one transport per endpoint which
>>>is usually the case for a2dp since the sep has the in_use flag.
>>
>>Where do you see that I'm not replying to SetConfiguration? Because
>>of the asynchronous Acquire call it should always reply.
>>But the limit would probably be a good idea.
>>
>>
>>> > Additionally, when you try to end the script with ctrl+c now, bluetoothd
>>> > segfaults with: segfault at 3c ip b75359d5 sp bfd25c10 error 4 in
>>> > libdbus-1.so.3.5.7[b7521000+48000]
>>> > I tried the whole use case as user and as root, but no difference. I also
>>> > attached the syslog output (bluetoothd started with -d).
>>>
>>>The syslog doesn't seems to indicate any crashes, did you left it out?
>>>Btw, to get more information about the crash please run bluetooth with
>>>valgrind e.g:
>>>
>>>sudo G_SLICE=always-malloc G_DEBUG=gc-friendly,resident-module
>>>valgrind --trace-children=yes ./bluetoothd -dn
>>
>>I didn't leave out anything. I attached the valgrind log. This is what I did:
>>1. Started bluetoothd with valgrind.
>>2. Started simple-endpoint-dual (see my last e-mail) with no
>>headsets in connected mode.
>>3. Connected one headset (got one file descriptor and one Operation
>>Not Authorized).
>>4. Ended simple-endpoint-dual with ctrl+c (and bluetoothd segfaults).
>>
>>
>>>--
>>>Luiz Augusto von Dentz
>>>--
>>
>>Peter
>>
>>
>
>
At 21:43 08.07.2011, Peter Kornatowski wrote:
>Hi Luiz,
>
>At 12:08 08.07.2011, Luiz Augusto von Dentz wrote:
>>Hi Peter,
>>
>>On Thu, Jul 7, 2011 at 10:57 PM, Peter Kornatowski <[email protected]> wrote:
>> > I'm calling Acquire when SetConfiguration is called by bluez
>> (isn't that the
>> > correct spot, cause there you get the transport path?). I
>> attached the whole
>> > modified script, so you can see exactly what I'm doing.
>>
>>As I explained in the last email you have to reply to the
>>SetConfiguration before you are able to do Acquire, that is on purpose
>>to avoid a possible deadlock where you are the application is waiting
>>for Acquire to complete but bluetoothd is waiting the application to
>>reply to SetConfiguration, bluetoothd won't block but the application
>>may block trying to Acquire and by doing that it is not able to reply
>>to SetConfiguration.
>
>This is why I'm calling Acquire asynchronously. But ok, I will test
>it with a postponed Acquire.
Tested it with a seperate python-script for calling Acquire (attached
it). Modified the previous script so that it doesn't call Acquire anymore.
So when registering two endpoints and connecting one headset, I see
bluez calling SetConfiguration for both endpoints (so two transport
paths with just different fdX at the end). I then call Acquire with
the new script for one endpoint at get the headset into playing mode
every time. When trying to call Acquire for the second headset I
always get Operation Not Authorized (which is fine I guess, but the
second SetConfiguration call in the first place is not). When
stopping this last scquire-script with ctrl+c (just the one that
produced Operation Not Authorized), bluetoothd always segfaults.
Stopping the other acquire-script or the endpoint-dual doesn't
segfault bluetoothd. I could reproduce this with my C code as well.
Also with endpoint and Acquire being in two different scripts I could
play around a little and found out that starting more endpoints than
there are connected headsets is not a good idea, even when you don't
call Acquire. So to workaround this behaviour I have to wait for a
headset to connect, then register just one endpoint for it and call
Acquire. For the next headset that connects I have to do the same.
And when a headset disconnects, the endpoint has to be unregistered
and closed as well. Or is this the intended way of doing it anyway?
>> > It also works for the first headset or if all headsets are in
>> connected mode
>> > and you start the script, so generally it should be ok.
>> > But it doesn't work if you start the script and then connect the first
>> > headset (or start the script after just one headset is in connected mode).
>> > Then the headset gets into playing mode, but bluez tries to put it into
>> > playing mode on the other endpoint, too (at least it looks that way to me
>> > cause SetConfiguration is being called twice). So then Acquire is being
>> > called twice, too. For one call I get the file descriptor, but
>> for the other
>> > call I get "Operation Not Authorized". Maybe because the second
>> > SetConfiguration is called for the other endpoint, which is on the other
>> > adapter with which the headset is not paired (each headset is only paired
>> > with one adapter). On the other hand, the transport path from both
>> > SetConfiguration calls is for the same adapter... But when you
>> then connect
>> > the second headset (which is paired with the other adapter), bluez doesn't
>> > call SetConfiguration for it (probably because this endpoint is still
>> > "blocked" by the first headset, but it shouldn't be).
>>
>>The Operation Not Authorized in because you didn't reply to
>>SetConfiguration, also bluetoothd will try to match the profile
>>capabilities with the endpoint capabilities and then call
>>SetConfiguration to the endpoint to confirm if it is able to handle
>>the transport, in theory I don't see any problem to the same endpoint
>>to get multiple SetConfiguration as long it is for different devices,
>>but perhaps we need to limit to only one transport per endpoint which
>>is usually the case for a2dp since the sep has the in_use flag.
>
>Where do you see that I'm not replying to SetConfiguration? Because
>of the asynchronous Acquire call it should always reply.
>But the limit would probably be a good idea.
>
>
>> > Additionally, when you try to end the script with ctrl+c now, bluetoothd
>> > segfaults with: segfault at 3c ip b75359d5 sp bfd25c10 error 4 in
>> > libdbus-1.so.3.5.7[b7521000+48000]
>> > I tried the whole use case as user and as root, but no difference. I also
>> > attached the syslog output (bluetoothd started with -d).
>>
>>The syslog doesn't seems to indicate any crashes, did you left it out?
>>Btw, to get more information about the crash please run bluetooth with
>>valgrind e.g:
>>
>>sudo G_SLICE=always-malloc G_DEBUG=gc-friendly,resident-module
>>valgrind --trace-children=yes ./bluetoothd -dn
>
>I didn't leave out anything. I attached the valgrind log. This is what I did:
>1. Started bluetoothd with valgrind.
>2. Started simple-endpoint-dual (see my last e-mail) with no
>headsets in connected mode.
>3. Connected one headset (got one file descriptor and one Operation
>Not Authorized).
>4. Ended simple-endpoint-dual with ctrl+c (and bluetoothd segfaults).
>
>
>>--
>>Luiz Augusto von Dentz
>>--
>
>Peter
>
>
>
Hi Luiz,
At 12:08 08.07.2011, Luiz Augusto von Dentz wrote:
>Hi Peter,
>
>On Thu, Jul 7, 2011 at 10:57 PM, Peter Kornatowski <[email protected]> wrote:
> > I'm calling Acquire when SetConfiguration is called by bluez
> (isn't that the
> > correct spot, cause there you get the transport path?). I
> attached the whole
> > modified script, so you can see exactly what I'm doing.
>
>As I explained in the last email you have to reply to the
>SetConfiguration before you are able to do Acquire, that is on purpose
>to avoid a possible deadlock where you are the application is waiting
>for Acquire to complete but bluetoothd is waiting the application to
>reply to SetConfiguration, bluetoothd won't block but the application
>may block trying to Acquire and by doing that it is not able to reply
>to SetConfiguration.
This is why I'm calling Acquire asynchronously. But ok, I will test
it with a postponed Acquire.
> > It also works for the first headset or if all headsets are in
> connected mode
> > and you start the script, so generally it should be ok.
> > But it doesn't work if you start the script and then connect the first
> > headset (or start the script after just one headset is in connected mode).
> > Then the headset gets into playing mode, but bluez tries to put it into
> > playing mode on the other endpoint, too (at least it looks that way to me
> > cause SetConfiguration is being called twice). So then Acquire is being
> > called twice, too. For one call I get the file descriptor, but
> for the other
> > call I get "Operation Not Authorized". Maybe because the second
> > SetConfiguration is called for the other endpoint, which is on the other
> > adapter with which the headset is not paired (each headset is only paired
> > with one adapter). On the other hand, the transport path from both
> > SetConfiguration calls is for the same adapter... But when you then connect
> > the second headset (which is paired with the other adapter), bluez doesn't
> > call SetConfiguration for it (probably because this endpoint is still
> > "blocked" by the first headset, but it shouldn't be).
>
>The Operation Not Authorized in because you didn't reply to
>SetConfiguration, also bluetoothd will try to match the profile
>capabilities with the endpoint capabilities and then call
>SetConfiguration to the endpoint to confirm if it is able to handle
>the transport, in theory I don't see any problem to the same endpoint
>to get multiple SetConfiguration as long it is for different devices,
>but perhaps we need to limit to only one transport per endpoint which
>is usually the case for a2dp since the sep has the in_use flag.
Where do you see that I'm not replying to SetConfiguration? Because
of the asynchronous Acquire call it should always reply.
But the limit would probably be a good idea.
> > Additionally, when you try to end the script with ctrl+c now, bluetoothd
> > segfaults with: segfault at 3c ip b75359d5 sp bfd25c10 error 4 in
> > libdbus-1.so.3.5.7[b7521000+48000]
> > I tried the whole use case as user and as root, but no difference. I also
> > attached the syslog output (bluetoothd started with -d).
>
>The syslog doesn't seems to indicate any crashes, did you left it out?
>Btw, to get more information about the crash please run bluetooth with
>valgrind e.g:
>
>sudo G_SLICE=always-malloc G_DEBUG=gc-friendly,resident-module
>valgrind --trace-children=yes ./bluetoothd -dn
I didn't leave out anything. I attached the valgrind log. This is what I did:
1. Started bluetoothd with valgrind.
2. Started simple-endpoint-dual (see my last e-mail) with no headsets
in connected mode.
3. Connected one headset (got one file descriptor and one Operation
Not Authorized).
4. Ended simple-endpoint-dual with ctrl+c (and bluetoothd segfaults).
>--
>Luiz Augusto von Dentz
>--
Peter
Hi Luiz,
At 14:49 07.07.2011, Luiz Augusto von Dentz wrote:
>Hi Peter,
>
>On Thu, Jul 7, 2011 at 11:25 AM, Peter Kornatowski <[email protected]> wrote:
> > Hi Luiz,
> >
> > At 22:35 06.07.2011, Luiz Augusto von Dentz wrote:
> >>
> >> Hi Peter,
> >>
> >> On Wed, Jul 6, 2011 at 10:54 PM, Peter Kornatowski <[email protected]> wrote:
> >> > I downloaded and checked the new bluez version 4.95. I'm wondering why
> >> > the
> >> > patch of Lukasz didn't get applied? As I wrote in my last e-mail, it
> >> > works
> >> > for not losing playing mode of all headsets when disconnecting just one.
> >>
> >> I don't remember actually seeing a proper patch to the mailing list,
> >> that might explain why it wasn't applied yet.
> >
> > So Lukasz, could you make a proper patch out of it, cause it's your code?
> >
> >> > Did someone of you had a chance to look into the other problems I wrote
> >> > about in my last e-mail? This would help me a lot.
> >>
> >> Nope, I was actually waiting for more input since you mentioned this
> >> only happened with some code your wrote.
> >
> > The first problem I wrote about also occures with the
> simple-endpoint script
> > located in the test directory of bluez. You just have to add the "Acquire"
> > call to "SetConfiguration" to actually set the headset in playing mode. I
> > also posted the lines of code I added, so you can easily try to reproduce
> > it. The second problem just occurs with my code, that's right.
> But maybe you
> > have some general ideas. Otherwise I'll have to dig in by myself. But it
> > would be very helpful when you look at least into the first problem.
>
>Your are probably is trying to Acquire the transport before
>SetConfiguration completes so that will return an error since the
>configuration is not accepted yet by the endpoint. If that is causing
>a crash than it needs to be fixed, otherwise you basically need to
>reply to SetConfiguration before trying to Acquire the transport.
I'm calling Acquire when SetConfiguration is called by bluez (isn't
that the correct spot, cause there you get the transport path?). I
attached the whole modified script, so you can see exactly what I'm doing.
It also works for the first headset or if all headsets are in
connected mode and you start the script, so generally it should be ok.
But it doesn't work if you start the script and then connect the
first headset (or start the script after just one headset is in
connected mode). Then the headset gets into playing mode, but bluez
tries to put it into playing mode on the other endpoint, too (at
least it looks that way to me cause SetConfiguration is being called
twice). So then Acquire is being called twice, too. For one call I
get the file descriptor, but for the other call I get "Operation Not
Authorized". Maybe because the second SetConfiguration is called for
the other endpoint, which is on the other adapter with which the
headset is not paired (each headset is only paired with one adapter).
On the other hand, the transport path from both SetConfiguration
calls is for the same adapter... But when you then connect the second
headset (which is paired with the other adapter), bluez doesn't call
SetConfiguration for it (probably because this endpoint is still
"blocked" by the first headset, but it shouldn't be).
Additionally, when you try to end the script with ctrl+c now,
bluetoothd segfaults with: segfault at 3c ip b75359d5 sp bfd25c10
error 4 in libdbus-1.so.3.5.7[b7521000+48000]
I tried the whole use case as user and as root, but no difference. I
also attached the syslog output (bluetoothd started with -d).
>--
>Luiz Augusto von Dentz
>--
Thanks,
Peter
Hi Luiz,
At 22:35 06.07.2011, Luiz Augusto von Dentz wrote:
>Hi Peter,
>
>On Wed, Jul 6, 2011 at 10:54 PM, Peter Kornatowski <[email protected]> wrote:
> > I downloaded and checked the new bluez version 4.95. I'm wondering why the
> > patch of Lukasz didn't get applied? As I wrote in my last e-mail, it works
> > for not losing playing mode of all headsets when disconnecting just one.
>
>I don't remember actually seeing a proper patch to the mailing list,
>that might explain why it wasn't applied yet.
So Lukasz, could you make a proper patch out of it, cause it's your code?
> > Did someone of you had a chance to look into the other problems I wrote
> > about in my last e-mail? This would help me a lot.
>
>Nope, I was actually waiting for more input since you mentioned this
>only happened with some code your wrote.
The first problem I wrote about also occures with the simple-endpoint
script located in the test directory of bluez. You just have to add
the "Acquire" call to "SetConfiguration" to actually set the headset
in playing mode. I also posted the lines of code I added, so you can
easily try to reproduce it. The second problem just occurs with my
code, that's right. But maybe you have some general ideas. Otherwise
I'll have to dig in by myself. But it would be very helpful when you
look at least into the first problem.
>--
>Luiz Augusto von Dentz
>--
Thanks,
Peter
Hi Peter,
On Wed, Jul 6, 2011 at 10:54 PM, Peter Kornatowski <[email protected]> wrote:
> I downloaded and checked the new bluez version 4.95. I'm wondering why the
> patch of Lukasz didn't get applied? As I wrote in my last e-mail, it works
> for not losing playing mode of all headsets when disconnecting just one.
I don't remember actually seeing a proper patch to the mailing list,
that might explain why it wasn't applied yet.
> Did someone of you had a chance to look into the other problems I wrote
> about in my last e-mail? This would help me a lot.
Nope, I was actually waiting for more input since you mentioned this
only happened with some code your wrote.
--
Luiz Augusto von Dentz
At 22:08 29.06.2011, Peter Kornatowski wrote:
>Hi,
>
>At 00:16 29.06.2011, Lukasz Rymanowski wrote:
>>Hi Luiz,
>>
>>On Tue, Jun 28, 2011 at 11:48 PM, Luiz Augusto von Dentz
>><[email protected]> wrote:
>> > Hi Lukasz,
>> >
>> > On Tue, Jun 28, 2011 at 11:07 PM, Lukasz Rymanowski
>> > <[email protected]> wrote:
>> >> Hi Peter,
>> >>
>> >> Can you try attached patch ?
>> >> At least you should not lose audio on all the headsets when
>> >> disconnecting one of them.
>> >
>> > Good catch, the headset watch is not registered per device so we have
>> > to do the matching inside the callback like you did, one thing that
>> > perhaps is worth doing is to make the matching before the switch so if
>> > the endpoint has a device then we match it with the device given to
>> > the callback.
>>
>>I thought about it but we can do matching only if transport exist.
>>Second thing is that in state HEADSET_STATE_CONNECTING we are actually
>>interested to do something if transport does not exist yet (look into
>>media_endpoint_set_configuration() )
>>So it looks like different states have different approach.
>>Anyway, let's wait for test result.
>
>
>OK, so the disconnect problem is fixed with the patch. So when one
>headset disconnects, the other ones stay in playing mode.
>But there are still some issues with (re)connecting headsets into
>playing mode:
>
>1. When there are at least two "free" endpoints registered and a
>headset connects, you get an "Operation Not Authorized" (with the
>simple-endpoint script and with my C-code) and a bluetoothd segfault
>(just with the simple-endpoint script) when you try to call
>"Acquire" to put the headset in playing mode and get the fd.
>For example: Register 3 endpoints with the script by modifying it like this:
>
> path1 = manager.FindAdapter(sys.argv[1])
> media1 = dbus.Interface(bus.get_object("org.bluez", path1),
> "org.bluez.Media")
> path1 = "/test/endpoint1"
> endpoint1 = Endpoint(bus, path1)
> path2 = manager.FindAdapter(sys.argv[2])
> media2 = dbus.Interface(bus.get_object("org.bluez", path2),
> "org.bluez.Media")
> path2 = "/test/endpoint2"
> endpoint2 = Endpoint(bus, path2)
> path3 = manager.FindAdapter(sys.argv[3])
> media3 = dbus.Interface(bus.get_object("org.bluez", path3),
> "org.bluez.Media")
> path3 = "/test/endpoint3"
> endpoint3 = Endpoint(bus, path3)
> mainloop = gobject.MainLoop()
> properties = dbus.Dictionary({ "UUID" : HFP_AG_UUID,
> "Codec" : PCM_CODEC, "Capabilities" : PCM_CONFIGURATION })
> print properties
> media1.RegisterEndpoint(path1, properties)
> media2.RegisterEndpoint(path2, properties)
> media3.RegisterEndpoint(path3, properties)
> mainloop.run()
>
>Don't forget to add calling "Acquire" in SetConfiguration like this
>(see my first mail):
> media_transport =
> dbus.Interface(bus.get_object("org.bluez", transport),
> "org.bluez.MediaTransport")
> media_transport.Acquire("rw", reply_handler=acquire_cb,
> error_handler=acquire_error)
>
>Then connect a headset and you get:
>
>./simple-endpoint hci0 hci1 hci2
>dbus.Dictionary({'Codec': dbus.Byte(0), 'UUID':
>'0000111F-0000-1000-8000-00805F9B34FB', 'Capabilities':
>dbus.Array([], signature=dbus.Signature('ay'))}, signature=None)
>SetConfiguration (/org/bluez/7917/hci0/dev_00_23_7F_45_2A_6C/fd0,
>dbus.Dictionary({dbus.String(u'NREC'): dbus.Boolean(True,
>variant_level=1), dbus.String(u'UUID'):
>dbus.String(u'0000111F-0000-1000-8000-00805F9B34FB',
>variant_level=1), dbus.String(u'InbandRingtone'): dbus.Boolean(True,
>variant_level=1), dbus.String(u'Codec'): dbus.Byte(0,
>variant_level=1), dbus.String(u'Routing'): dbus.String(u'HCI',
>variant_level=1), dbus.String(u'Device'):
>dbus.ObjectPath('/org/bluez/7917/hci0/dev_00_23_7F_45_2A_6C',
>variant_level=1), dbus.String(u'Configuration'): dbus.Array([],
>signature=dbus.Signature('y'), variant_level=1)},
>signature=dbus.Signature('sv')))
>SetConfiguration (/org/bluez/7917/hci0/dev_00_23_7F_45_2A_6C/fd1,
>dbus.Dictionary({dbus.String(u'NREC'): dbus.Boolean(True,
>variant_level=1), dbus.String(u'UUID'):
>dbus.String(u'0000111F-0000-1000-8000-00805F9B34FB',
>variant_level=1), dbus.String(u'InbandRingtone'): dbus.Boolean(True,
>variant_level=1), dbus.String(u'Codec'): dbus.Byte(0,
>variant_level=1), dbus.String(u'Routing'): dbus.String(u'HCI',
>variant_level=1), dbus.String(u'Device'):
>dbus.ObjectPath('/org/bluez/7917/hci0/dev_00_23_7F_45_2A_6C',
>variant_level=1), dbus.String(u'Configuration'): dbus.Array([],
>signature=dbus.Signature('y'), variant_level=1)},
>signature=dbus.Signature('sv')))
>SetConfiguration (/org/bluez/7917/hci0/dev_00_23_7F_45_2A_6C/fd2,
>dbus.Dictionary({dbus.String(u'NREC'): dbus.Boolean(True,
>variant_level=1), dbus.String(u'UUID'):
>dbus.String(u'0000111F-0000-1000-8000-00805F9B34FB',
>variant_level=1), dbus.String(u'InbandRingtone'): dbus.Boolean(True,
>variant_level=1), dbus.String(u'Codec'): dbus.Byte(0,
>variant_level=1), dbus.String(u'Routing'): dbus.String(u'HCI',
>variant_level=1), dbus.String(u'Device'):
>dbus.ObjectPath('/org/bluez/7917/hci0/dev_00_23_7F_45_2A_6C',
>variant_level=1), dbus.String(u'Configuration'): dbus.Array([],
>signature=dbus.Signature('y'), variant_level=1)},
>signature=dbus.Signature('sv')))
>Acquire failed: org.bluez.Error.NotAuthorized: Operation Not Authorized
>
>In addition, bluetoothd segfaults: bluetoothd[7917]: segfault at 4d
>ip b7589e11 sp bfe4f190 error 4 in libdbus-1.so.3.5.5[b7576000+3c000]
>
>With my C-code I also get "Operation Not Authorized", but not the
>segfault. See attached logs "hs_connect_python_onp.syslog" and
>"hs_connect_c_onp.syslog".
>
>
>2. This problem occurs just in my C-code: There are 3 endpoints and
>3 headsets are in playing mode. I turn off 1 headset, it disconnects
>and after some time I turn it on again. It reconnects and is
>automatically put back in playing mode because bluez calls
>SetConfiguration (probably because there is only 1 "free" endpoint
>it calls on the right one) and there "Acquire" is called and the
>headset goes into playing mode. At least this is how it works with
>the simple-endpoint script (log for that ist
>"hs_reconnect_python.syslog"). But in my C-code (although it makes
>exactly the same as the python-script), I always get
>"bluetoothd[28181]: sco_bind: Address already in use (98)" (see
>"hs_reconnect_c.syslog"). Only when trying to put it in playing mode
>for the first time after application start it works fine. Any ideas?
>
>
>
>> >
>> >
>> > --
>> > Luiz Augusto von Dentz
>> >
>>
>>/Lukasz
>>--
>
>Thanks,
>Peter
I downloaded and checked the new bluez version 4.95. I'm wondering
why the patch of Lukasz didn't get applied? As I wrote in my last
e-mail, it works for not losing playing mode of all headsets when
disconnecting just one.
Did someone of you had a chance to look into the other problems I
wrote about in my last e-mail? This would help me a lot.
Thanks,
Peter