Re: [GnomeMeeting-devel-list] Advanced support for bluetooth headsets

[Colin Guthrie <gnomemeeting colin guthr ie>]

simon wrote:
> My thoughts after looking at the example scripts is that this would be a
> seperate application which sits between btsco and ekiga. Using DBus to
> pass information to/from ekiga.
>
> There is the question about whether it needs to be able change the audio
> device that ekiga uses depending on what picks up the call - or whether
> a BT user would always use the BT like to take/place calls.

As I just posted in another thread about BT adapters a few minutes ago, 
wouldn't it be more sensible for the underlying system to take care of 
audio device selection?

e.g. modprobe the snd-bt-sco and run the btsco application. It listens 
for your device to come in range/be turned on etc.

When it cannot detect your device it passes through audio (in both 
directions) to another sound device on your system, but maintains the 
headset device as being always available as a device.

So, after running ekiga, I select my audio device as "BT Headset" (or 
whatever it shows up as in Alsa!). When my phone rings ekiga just sends 
the ringing to the "BT Headset" device. If the headset is not 
on/in-range, then the underlying btsco program just passes the "ringing" 
to the system audio device.

I can accept the call via mouse click at any point and the call 
(mic/output) will be passed through the btsco app to the system device 
and I can say to the caller "hold on a sec when I put in my headset".

The turning on of the headset will automatically detected by btsco and 
instead of channeling the audio to/from my system device, it will now go 
to/from the headset.

The button actions can still be handled nicely by btsco and channeled 
via DBUS as suggested above. If the call is ringing then when the 
headset is activated (flipped open in some models) this would take two 
actions, one the audio device would flip in btsco so the ringing would 
stop on my speakers and start coming out my headset - two the opening of 
the flip would cause a DBUS signal to be emitted that ekiga could listen 
to and accept the call.

This scenario would require minimal changes to ekiga/pwlib to 
specifically support this situation and make btsco "just work"(tm) with 
lots of other applications too!!

I am perhaps missing something here but this seems to me to be a far 
more sensible solution.

Col.