Re: C API:s
Re: C API:s
- Subject: Re: C API:s
- From: Ragnar Sundblad <email@hidden>
- Date: Mon, 20 Jan 2003 07:34:20 +0100
--On den 19 januari 2003 18:59 -0800 Eric Brown <email@hidden> wrote:
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.
In this case, I really don't think it is a general bluetooth
problem - the TDK dongle has two LEDs, on of which is blinking
under certain (to me unknown) circumstances, it seems to be
usage related. The SCO audio is chopped up with exact
synkronization with that LED - LED on = audio on, LED off =
audio off, in ~2Hz. Kind of funny.
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.
That is an interresting theory, but I doubt that it is the (main)
problem here. With my experiments the indication for lossy/bad
communication and/or to far a distance was increased noise that
sounded more or less like just ordinary plain good old beautiful
old fashioned noise - the ultimate indication to the user that
she must improve the radio conditions, move closer for example.
In my personal experience, I haven't found a headset that
worked well enough for my everyday use.
It obviously depends what who wants to do with it. Heck, people
call with GSM systems, watch VCDs and listen to internet
"radio stations". Now try to define "well enough"! :-)
I don't know what the problem with GSM phones and bluetooth
headsets is, all I know is that it seems to only work
satisfactory under certaion conditions, called party equipment
included in the equation. I don't (yet) think we should rule out
SCO and bluetooth as a headset connection just because of that.
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.
Yep, that is important to point out!
(Well, the phones obviously can separate a few words from each
other even over bluetooth, so the audio link is not entirely
useless for that, but I guess it won't work at all with the
apple speech recognition of today since that is made for high
quality audio input.)
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?
I'd love to see more of those too!
My colleague is trying to convince the QuickTime people to add
the rest of the calls needed to make QuickTime do everything
but talking SIP and interact with the user to make a SIP phone.
(I think most of the things lacking can be pretty easily worked
around, but I am not sure). He has a program that kind of works
today, but has more of proof-of-concept status.
(If you saw a guy walking around at WWDC sometimes talking into
his TiBooks' keyboard with his nose almost stuck in the screen
hinges you probably saw him, and you now know that he isn't
(entirely) crazy. A portable headset solution is high on our
whishlists. :-)
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).
I take it you have heard my nagging here then. I'll stop doing
it for at least a week or so. :-)
/ragge
_______________________________________________
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.
| References: | |
| | >Re: C API:s (From: Eric Brown <email@hidden>) |