Re: bluetooth-dev digest, Vol 1 #66 - 5 msgs
Re: bluetooth-dev digest, Vol 1 #66 - 5 msgs
- Subject: Re: bluetooth-dev digest, Vol 1 #66 - 5 msgs
- From: Adam Hall <email@hidden>
- Date: Tue, 21 Jan 2003 20:27:20 -0500
Yes add me to the list please!
On Monday, January 20, 2003, at 01:01 AM,
email@hidden wrote:
Send bluetooth-dev mailing list submissions to
email@hidden
To subscribe or unsubscribe via the World Wide Web, visit
http://www.lists.apple.com/mailman/listinfo/bluetooth-dev
or, via email, send a message with subject or body 'help' to
email@hidden
You can reach the person managing the list at
email@hidden
When replying, please edit your Subject line so it is more specific
than "Re: Contents of bluetooth-dev digest..."
Today's Topics:
1. IOServiceMatching (Robert Grant)
2. Re: C API:s (=?ISO-8859-1?Q?Andr=E9=20Alm?=)
3. Re: IOServiceMatching (Eric Brown)
4. Re: C API:s (Ragnar Sundblad)
5. Re: C API:s (Eric Brown)
--__--__--
Message: 1
Date: Sun, 19 Jan 2003 14:48:33 -0500
Subject: IOServiceMatching
From: Robert Grant <email@hidden>
To: email@hidden
If I wanted to detect the coming and going of Bluetooth devices I
imagine I can
use IOServiceMatching? But what would be the IO class name?
I'm guessing: "IOBluetoothDevice"?
And how about the PlugInInterface?
I've got the December developer tools but I don't seem to have the
Bluetooth Framework. Isn't it included?
Thanks,
Robert.
--__--__--
Message: 2
From: =?ISO-8859-1?Q?Andr=E9=20Alm?= <email@hidden>
To: <email@hidden>
Subject: Re: C API:s
Date: Sun, 19 Jan 2003 21:34:27 +0100
--On den 16 januari 2003 13:53 -0800 Michael Larson <email@hidden>
wrote:
There is currently not an API for SCO connections in the stack, so
you
will run into a rather large and hard wall here. This is something
we
are looking at for a future release. Its priority depends largely on
the demand for SCO links. I assume I should add you to the list of
requests.
Please add me too! I'd also be happy to test any SCO beta stuff
you might have or get. We want to make software phones.
I have seen several requests for using a Bluetooth headset for audio
input and output. Here is one I happened to see the other day. And of
course add me to the list who needs to get a SCO link working.
------------ From macintouch
Date: Thu, 02 Jan 2003 11:17:24 -0400
From: Larry White
Subject: Bluetooth report - wireless headsets
FYI - OSX does not support the headset profile either. My bluetooth
headset which works fine with my Nokia 6310i is not recognized by my
Powerbook. It is too bad because I was looking forward to using it
with
ViaVoice.
------------
/Andri
Hdlsningar
Andri Alm
DNS & System Engineer
Office Data Vdsteres
Tele: +46 - (0)21-17 22 50
Fax: +46 - (0)21-17 22 51
http://www.vasteras.office.se
--__--__--
Message: 3
Date: Sun, 19 Jan 2003 18:18:20 -0800
Subject: Re: IOServiceMatching
Cc: email@hidden
To: Robert Grant <email@hidden>
From: Eric Brown <email@hidden>
On Sunday, January 19, 2003, at 11:48 AM, Robert Grant wrote:
If I wanted to detect the coming and going of Bluetooth devices I
imagine I can
use IOServiceMatching? But what would be the IO class name?
I'm guessing: "IOBluetoothDevice"?
And how about the PlugInInterface?
Instead of using the raw IOKit APIs for device access, we've provided a
more object-oriented wrapper around them with (hopefully) easier to use
functions and ObjC objects to access the various Bluetooth layers.
To find out about any device (i.e. baseband connection) coming and
going, use IOBluetoothRegisterForDeviceConnectNotifications() or
+[IOBluetoothDevice registerForConnectNotifications:selector:].
I've got the December developer tools but I don't seem to have the
Bluetooth Framework. Isn't it included?
All of the user-land Bluetooth APIs are in the IOBluetooth.framework in
/System/Library/Frameworks. Have a look at either IOBluetoothUserLib.h
or objc/IOBluetoothDevice.h.
- Eric
--__--__--
Message: 4
Date: Mon, 20 Jan 2003 03:20:09 +0100
From: Ragnar Sundblad <email@hidden>
To: email@hidden
Subject: Re: C API:s
--On den 19 januari 2003 21:34 +0100 Andri Alm <email@hidden>
wrote:
Please add me too! I'd also be happy to test any SCO beta stuff
you might have or get. We want to make software phones.
I have seen several requests for using a Bluetooth headset for audio
input and output. Here is one I happened to see the other day. And of
course add me to the list who needs to get a SCO link working.
I have heard about others using for example an ipaq with windows ce,
bluetooth, wavelan and SIP phone software make wireless
(bluetooth+wavelan) phone calls with good results.
I could almost see it work for myself today. I tried out the beta
of the TDK windows driver that is supposed to work OK with their
pcmcia card, but not yet so good with the USB dongle I have.
I can confirm the latter, something chops up the audio in both
directions with the same interval as the dongle blinking, some 2Hz.
I suspect the dongle firmware.
Anyway, what was nice was that when audio comes through it sounds
almost about as good as a POTS phone call (with the old first
generation ericsson HBH-10) and the latency (I tried a DVD movie)
was seemingly pretty good (not all that easy to tell when the
audio is chopped up, but I think so).
I have no idea which of the three audio formats, ulaw, alaw or
adpcm, that the headset supports that the driver choosed to use.
I do think that Apple should get support for it asap, and
preferably make the sound manager glue for it too.
People are already using their bluetooth headsets for telephony,
and I doubt that interrest will decline any time soon. It would
be sad if it couldn't be (easily) done on a Mac OS X machine.
If it was just a little programming to do I could try out my
ericsson rok101007-based dongle (with BT 1.1 firmware) on
Mac OS X, I am pretty sure that one works ok with SCO, but
emulating the entire stack, if so only for one single purpose,
seems a little bit heavy for just testing purposes considering
the time I currently have available for this project.
Whom at apple should we talk to to get more SCO support in the
Mac OS X bluetooth stack sooner rather than later?
/ragge
--__--__--
Message: 5
Date: Sun, 19 Jan 2003 18:59:34 -0800
Subject: Re: C API:s
Cc: email@hidden
To: Ragnar Sundblad <email@hidden>
From: Eric Brown <email@hidden>
On Sunday, January 19, 2003, at 06:20 PM, Ragnar Sundblad wrote:
--On den 19 januari 2003 21:34 +0100 Andri Alm <email@hidden>
wrote:
Please add me too! I'd also be happy to test any SCO beta stuff
you might have or get. We want to make software phones.
I have seen several requests for using a Bluetooth headset for audio
input and output. Here is one I happened to see the other day. And
of
course add me to the list who needs to get a SCO link working.
I have heard about others using for example an ipaq with windows ce,
bluetooth, wavelan and SIP phone software make wireless
(bluetooth+wavelan) phone calls with good results.
I could almost see it work for myself today. I tried out the beta
of the TDK windows driver that is supposed to work OK with their
pcmcia card, but not yet so good with the USB dongle I have.
I can confirm the latter, something chops up the audio in both
directions with the same interval as the dongle blinking, some 2Hz.
I suspect the dongle firmware.
Anyway, what was nice was that when audio comes through it sounds
almost about as good as a POTS phone call (with the old first
generation ericsson HBH-10) and the latency (I tried a DVD movie)
was seemingly pretty good (not all that easy to tell when the
audio is chopped up, but I think so).
I have no idea which of the three audio formats, ulaw, alaw or
adpcm, that the headset supports that the driver choosed to use.
I don't think the problem you see with the audio is due to firmware.
That sounds similar to what I've seen with a couple of different pieces
of hardware. The problem I suspect is due to the way that the SCO
connection works. It was designed with no retry mechanism. This
unfortunately leads to various problems such as glitches, stutters and
dropouts in different environments given that the 2.4GHz band is in
such high use. In my personal experience, I haven't found a headset
that worked well enough for my everyday use.
Given that a lot of the requests we've had for headset support is for
speech recognition use, in my opinion, there's no way that the hardware
that I've tested would have good enough sound quality for that use.
Now that IP telephony is starting to become more popular, it seems like
more uses for the technology are opening up. Are there any decent IP
telephony solutions for Mac OS X currently?
Also, I'd love to hear from somebody who has a Bluetooth headset really
works well.
I do think that Apple should get support for it asap, and
preferably make the sound manager glue for it too.
People are already using their bluetooth headsets for telephony,
and I doubt that interrest will decline any time soon. It would
be sad if it couldn't be (easily) done on a Mac OS X machine.
If it was just a little programming to do I could try out my
ericsson rok101007-based dongle (with BT 1.1 firmware) on
Mac OS X, I am pretty sure that one works ok with SCO, but
emulating the entire stack, if so only for one single purpose,
seems a little bit heavy for just testing purposes considering
the time I currently have available for this project.
Whom at apple should we talk to to get more SCO support in the
Mac OS X bluetooth stack sooner rather than later?
The best place for non developer-related feature requests is the
Bluetooth feedback e-mail address: <email@hidden>.
However we do hear the requests being made on this list (even if we
can't always respond or talk about everything going on).
- Eric
--__--__--
_______________________________________________
bluetooth-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/bluetooth-dev
Do not post admin requests to the list. They will be ignored.
End of bluetooth-dev Digest
_______________________________________________
bluetooth-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/bluetooth-dev
Do not post admin requests to the list. They will be ignored.