-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi there,
I decided to invest some of my precious time into improving audio
support for BT headsets; I'm going to take over maintenance of the
snd-bt-sco project.
I already did some minor improvements, but I don't know how to address
some critical design issues.
Right now, the way it works is this:
there's a user space program that handles the rfcomm and sco connection
(my enhanced version listens on open rfcomm for a connection request by
the headset, and opens the sco channel on demand), and an alsa audio
device driver. The device driver polls audio data to and from the
headset; the connection is managed by the user-space program.
Of course this is possibly not the best way of implementing things, but
I'm a bit stuck here.
The nicest way of implementing a better audio support would be having a
daemon that
a) listens for an incoming rfcomm connection that is open by the headset
itself
b) waits for a connection attempt (say, alsa audio interface opened) and
initiate such a connection
c) has the (optional) possibilty of keeping an open rfcomm session.
Reason for this one is the not-so-short rfcomm handshake time. The
rfcomm channel does not drain to much power from the headset, so it
might be a good idea to keep a steady connection at least as an option.
I don't have any clues how to implement this; what do you experts mean?
Should I try to enhance sco support itself, or should this stuff
(connection handling) be done in user-space? What is the easiest way to
recognize incoming rfcomm connections (listener on hci devices or
something?)
I'm really new to bluetooth, but I think I can adopt. I already worked
on some audio drivers and porting from 2.4 to 2.6 kernel, so I'm not a
total newbie, at least, I hope so :)
thanks for spending your time & any suggestions,
~ Lars
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFAmtRcQWC6DTWkDAoRAm5VAJ9SOvKb0nN6T52Zmsgsyv7B9+woPQCeNyv7
pwr9T8IISJCBLi55MoISpb0=
=J4nD
-----END PGP SIGNATURE-----
-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver
higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
James Courtier-Dutton wrote:
| Nicholas A. Preyss wrote:
|> In my opinion, the whole connection handling should be done in
|> user-space. In kernel-space only a generic "sco channel" - "alsa
|> device" binding interface should stay.
|> nicholas
|
| I think it might be worth trying to find out if one can get alsa-lib to
| use a user-space device driver. Then everything will stay in user space
| until it reaches the bluez code.
I think alsa needs a kernel modul for sound interface handling, but this
is not much of a problem - I think, after revising the code again. But
it might be interesting to check how the other hotplug (USB audio
devices) are handled...
Right now, the snd-bt-sco module for alsa implements the alsa hwdep
interface that is used to transmit sco-specific data (the sco socket, to
be precisly) from the user-space connection handler to the alsa kernel
module after the connection is made up. I think this method is not bad,
because kernel stuff is done in the kernel (sco I/O and audio I/O on the
alsa interfaces), but the connection handling itself is done by the
user-space daemon. The hwdep interface is exactly for this purpose, I
think...
I think it would be best to improve the interoperability of those three.
One thing is the incoming connection listener; is it possible to attach
a listener to the hci0 device that notices the user-space daemon of a
connecting device (like, "listen for connection of bdaddr 00:12:23:45:78
and tell me when we get a slave-mode rfcomm channel")?
Additionally, we need a method to tell the user-space daemon that the BT
~ Headset audio device has been opened to ring the bell in the headset
and make it possible for the user to answer the call - or attach the sco
channel automagically. I'll check if this can be implemented through the
hwdep interface, too. Right now, only the volume settings are polled by
the user-space daemon; it should be possible to check for incoming
(audio) connections the same way.
Keeping all this stuff - bdaddr, channel, different ways of connection
and automatism - in a user-space daemon will make it easy to handle such
data with a configuration file, and you don't have to gamble around with
rmmod/modprobe all the time.
My main concerns right now - I'm using the headset since monday in daily
phone communication, and as a freelancer I'm a lot "on the phone" - are
the automatic connection when the interface is opened (not nice to press
the connection button each time someone calls you), and the possibility
of using different audio codecs (MU_LAW, A_LAW, RAW_S8 and RAW_S16).
This is a problem because I' not sure which part of the chain should
*set* the correct audio mode. I think the mode-set must be done *before*
the sco channel is opened, so it would be best it the user-space daemon
does this change. Is it possible to change the voice setting through the
hci interface functions? Which function? Right now it has to be done
manually by hciconfig hci0 voice 0x0140...
BTW: is there any written interface documentation available for the
bluez stack?
Next I'm going to browse the mail archives for older posts on this topic.
thanks,
~ Lars
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFAm6b4QWC6DTWkDAoRAgtOAJ9c0FAps6GkdEzph/YLNJFc6HmzMgCgrwf0
0YsfKNqWk8W0kKPQ3w4X8g0=
=PHKG
-----END PGP SIGNATURE-----
-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver
higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On 0, James Courtier-Dutton <[email protected]> wrote:
> Nicholas A. Preyss wrote:
> >In my opinion, the whole connection handling should be done in
> >user-space. In kernel-space only a generic "sco channel" - "alsa device"
> >binding interface should stay.
>
> I think it might be worth trying to find out if one can get alsa-lib to
> use a user-space device driver. Then everything will stay in user space
> until it reaches the bluez code.
This means alot of rather useless kernelspace-userspace-kernelspace
copying. Looking at Marcels hstest program, there is a quiet large lag,
i am not sure, how much you could reduce this with an optimized direct
alsa interface.
nicholas
-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver
higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Nicholas A. Preyss wrote:
>
>
> In my opinion, the whole connection handling should be done in
> user-space. In kernel-space only a generic "sco channel" - "alsa device"
> binding interface should stay.
>
> nicholas
>
>
I think it might be worth trying to find out if one can get alsa-lib to
use a user-space device driver. Then everything will stay in user space
until it reaches the bluez code.
Cheers
James
-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver
higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On 0, Lars Grunewaldt <[email protected]> wrote:
> I decided to invest some of my precious time into improving audio
> support for BT headsets; I'm going to take over maintenance of the
> snd-bt-sco project.
This is fine.
> Right now, the way it works is this:
> there's a user space program that handles the rfcomm and sco connection
> (my enhanced version listens on open rfcomm for a connection request by
> the headset, and opens the sco channel on demand), and an alsa audio
> device driver. The device driver polls audio data to and from the
> headset; the connection is managed by the user-space program.
>
> Of course this is possibly not the best way of implementing things, but
> I'm a bit stuck here.
There are several threads in the mailing list archive about how sco-alsa
support should be implemented.
> The nicest way of implementing a better audio support would be having a
> daemon that
> a) listens for an incoming rfcomm connection that is open by the headset
> itself
> b) waits for a connection attempt (say, alsa audio interface opened) and
> initiate such a connection
> c) has the (optional) possibilty of keeping an open rfcomm session.
> Reason for this one is the not-so-short rfcomm handshake time. The
> rfcomm channel does not drain to much power from the headset, so it
> might be a good idea to keep a steady connection at least as an option.
I think the hs profile states that the rfcomm connection should stay up
when the devices support park mode, otherwise rfcomm connection may be
closed too when sco channel is closed. So i think the user-space daemon
should support both modes.
I don't know how park mode is implented in bluez and whether rfcomm
connections survive parking&unparking cleanly.
> I don't have any clues how to implement this; what do you experts mean?
> Should I try to enhance sco support itself, or should this stuff
> (connection handling) be done in user-space? What is the easiest way to
> recognize incoming rfcomm connections (listener on hci devices or
> something?)
In my opinion, the whole connection handling should be done in
user-space. In kernel-space only a generic "sco channel" - "alsa device"
binding interface should stay.
nicholas
-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver
higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel