public inbox for linux-bluetooth@vger.kernel.org
 help / color / mirror / Atom feed
From: Marcel Holtmann <marcel@holtmann.org>
To: James Courtier-Dutton <James@superbug.demon.co.uk>
Cc: "Fred Schättgen" <bluez-devel@schaettgen.de>,
	"BlueZ Mailing List" <bluez-devel@lists.sourceforge.net>,
	"Simon Vogl" <vogl@soft.uni-linz.ac.at>
Subject: Re: [Bluez-devel] sco link help needed
Date: Mon, 23 Feb 2004 08:55:38 +0100	[thread overview]
Message-ID: <1077522938.2832.84.camel@pegasus> (raw)
In-Reply-To: <40393D4D.5070908@superbug.demon.co.uk>

Hi James,

> What I am trying to say is that using read/write interfaces for realtime 
> streams like SCO is just the wrong way to do it.
> I have looked at snd-bluez-sco-2003-09-15.tar.gz and from what I can 
> understand from it, the snd-bluez-sco kernel driver is just using simple 
> read/write commands to a file descriptor given to it from the userspace 
> daemon "bluezsco".

I don't see a problem with a read/write interface, because what we get
from the Bluetooth chip is already PCM. I don't wann make it more
complex as needed if the hardware can do most of the stuff for us.

> This approach will get sound to and from the bluetooth headset.
> But SCO has the potential for so much more, so why are we restricting it?
> We must allow for applications like VoIP and DVD playback. These need 
> control over latency and playback timing accuracy. The current "file 
> descriptor read/write" approach does not allow for that.

Where do we restrict this?

> The bluetooth chip should not have to worry about dropping packets, the 
> application should just send the chip packets when the chip wants them.

Yes it have to. You should read the mailing list archive and search for
comments from the CSR guys about SCO. And you can of course take the
Bluetooth specification itself.

> I am only asking for changes to the SCO side of things due to it's real 
> time nature. Using network sockets for RFCOMM and bulk data transfers 
> that are not real time in nature is fine.
> 
> Once we have proper real time SCO support, we can overlay the current 
> SCO file descriptor read/write model on top if you still need it.

Again, I can't follow what you are trying to achieve. The current socket
interface for SCO fits not perfect, because it is audio only data. But
with eSCO we also provide data transmission over SCO.

However I don't wanna continue a socket interface for SCO. What I wan't
is something like:

	1. We need an SCO channel
	2. Connect SCO channel
	3. Attach SCO channel to an ALSA audio device
	4. Find new audio device and use it
	5. Use SCO controls for mixers settings etc.

Regards

Marcel




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

  reply	other threads:[~2004-02-23  7:55 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-19 14:36 [Bluez-devel] sco link help needed Simon Vogl
2004-02-19 15:29 ` Fred Schättgen
2004-02-21 14:37   ` James Courtier-Dutton
2004-02-22 12:27     ` Marcel Holtmann
2004-02-22 20:53       ` James Courtier-Dutton
2004-02-22 21:30         ` Marcel Holtmann
2004-02-22 22:04           ` James Courtier-Dutton
2004-02-22 22:09             ` Marcel Holtmann
2004-02-22 23:37               ` James Courtier-Dutton
2004-02-23  7:55                 ` Marcel Holtmann [this message]
2004-02-25 12:59                   ` Mauro Tortonesi
2004-02-25 13:25                     ` Marcel Holtmann
2004-02-25 14:04                       ` Mauro Tortonesi
2004-02-25 14:23                         ` Marcel Holtmann
2004-02-25 15:35                           ` Mauro Tortonesi
2004-02-25 15:37                             ` Marcel Holtmann
2004-02-25 15:46                               ` Mauro Tortonesi
     [not found]                           ` <1077728432.6021.522.camel@localhost>
2004-02-25 17:16                             ` Marcel Holtmann
2004-02-25 17:27                               ` Nils Faerber
2004-02-25 14:30                         ` James Courtier-Dutton
2004-02-25 14:59                           ` Dr. Simon Vogl
2004-02-25 15:09                             ` Marcel Holtmann
2004-02-25 14:22                     ` James Courtier-Dutton
2004-02-23 16:35               ` libs2 and utils2 Aaron Klish
2004-02-23 17:19                 ` [Bluez-devel] " Marcel Holtmann
2004-02-22 21:54         ` [Bluez-devel] sco link help needed Fred Schättgen
2004-02-22 22:00           ` Marcel Holtmann
2004-02-22 22:35             ` Fred Schättgen
2004-02-22 12:44     ` Dr. Simon Vogl

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=1077522938.2832.84.camel@pegasus \
    --to=marcel@holtmann.org \
    --cc=James@superbug.demon.co.uk \
    --cc=bluez-devel@lists.sourceforge.net \
    --cc=bluez-devel@schaettgen.de \
    --cc=vogl@soft.uni-linz.ac.at \
    /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