public inbox for linux-bluetooth@vger.kernel.org
 help / color / mirror / Atom feed
From: Lars Grunewaldt <lgw@dark-reality.de>
To: bluez-devel@lists.sourceforge.net
Subject: [Bluez-devel] questions about BT audio headset support...
Date: Fri, 07 May 2004 02:12:13 +0200	[thread overview]
Message-ID: <409AD45D.6080102@dark-reality.de> (raw)

-----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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

             reply	other threads:[~2004-05-07  0:12 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-07  0:12 Lars Grunewaldt [this message]
2004-05-07 11:30 ` [Bluez-devel] questions about BT audio headset support Nicholas A. Preyss
2004-05-07 12:38   ` James Courtier-Dutton
2004-05-07 14:19     ` Nicholas A. Preyss
2004-05-07 15:10     ` Lars Grunewaldt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=409AD45D.6080102@dark-reality.de \
    --to=lgw@dark-reality.de \
    --cc=bluez-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox