William "Chops" Westfield <westfw <at> mac.com> writes: 
> 1) Can a program use the bluetooth headset as an audio device without  
> making it the default audio input/output path?  (how DO the various  
> popular operating systems deal with multiple audio devices anyway?)   
> My first thought was to implement some simple MODEM to send/receive  
> data sent on the audio stream.
> 
> 2) What about the assorted buttons on most headsets?  Can their status  
> be detected programatically on the desktop side?  I guess this would  
> imply a need for access to bluetooth devices at a level a bit lower  
> than a simple "audio device." 

Bluetooth devices have 'classes' and usually each device belongs to one class,
but there are some which belong to several. The audio device class is different
from the 'media interface' class. Bluetooth classes are called profiles in
Bluetooth weaselspeak.

On unixish operating systems a bluetooth daemon handles the pairing with a
bluetooth device in range and then either handles by itself or spawns off the
various daemons which each handle one class (or profile) of attached bluetooth
device. When set up right (the bluetooth daemon and the associated bluetooth
sound handler daemon), then the new sound device appears as an ordinary sound
device and it can be selected and opened for output and for input (the input and
the output separately). Running some kind of tone sequence or fsk based control
software over this potential link is not impossible. The buttons are typically
handled by a 'media control handler' which is disjoint from the sound control
daemon.

On windows, the bundled application that comes with the bluetooth device will do
all-in-one handling of the audio and buttons. I have little experience with
windows bluetooth programming but i know that they have no unixish device layer
equivalent and that extensive list walking and enumeration is needed to find the
relevant end points and that the registry is heavily involved in finding the
right bluetooth class/handler for an application. I won't go there.

The problem is that bluetooth devices are very often buggy partial
implementations of the protocols, and that standard drivers often cannot work
with the resulting 'bugs'. The net is full of descriptions of people whose
bluetooth headset / cell phone combination does not work and there are even more
descriptions of bluetooth devices which do not work with their windows pc. I
could add my own little chapter here, related to OBEX FTP and other nightmares
involving a certain popular Canadian cell phone maker and open source unix (not
that the windows version of things worked better). The general rule seems to be
that the things advertised on the box will mostly work with their driver on one
OS. Beyond that, all bets are off.

I have been looking into interfacing with the now well-hidden PC interfaces in
many ways, and bluetooth is likely not one of them. Lately I have been looking
hard at FT232RL chips which are available for under $3 and have interesting
bit-banged modes which allow a lot of interesting applications to be created,
with or without a microprocessor. They are, of course, not wireless.

  Peter


-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist