Re: Media API with more than one headset

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Peter,

On Thu, Jun 23, 2011 at 12:23 AM, Peter Kornatowski <pkorn@xxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux