Re: [Bluez-devel] sco link help needed

[Marcel Holtmann <marcel@holtmann.org>]

Hi Fred,

> I don't understand why the whole headset profile has to be implemented as a 
> part of an alsa driver. Everything can be done completely in user space 
> already, completely independent from alsa. The only reason one might wish to 
> have a special alsa driver is better responsiveness only, or what else did I 
> miss? 
> The rfcomm stuff isn't performance critical at all, so there is need for it to 
> go into an alsa driver.

the headset profile will never be in kernel space, because profiles are
application specific. An ALSA Bluetooth driver should map between a SCO
channel and an audio device, so that you can for example use XMMS or
GnomeMeeting with your Bluetooth headset.

> I really don't like the idea that an alsa driver would decide if a sco 
> connection is going to be accepted or not. This should all be up to the a 
> regular userspace application. The alsa driver should not accept incoming 
> connections itself. 
> Instead their should be a way for the application to create or accept (or not 
> accept) a SCO connection the usual way and - only if it wishes to - tell alsa 
> to take care of that connection by creating a new alsa device for it.
> The only job the driver should do is to connect an existing sco socket to an 
> alsa device and make sure that there are no cracks in the audio stream, 
> nothing more.

You always have a control application on an ACL link before any SCO
channel will be open.

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