Re: [Bluez-devel] sco link help needed

["Fred Schättgen" <bluez-devel@schaettgen.de>]

On Sunday 22 February 2004 21:53, James Courtier-Dutton wrote:
> Marcel Holtmann wrote:
> > we don't need a kernel module that implements the headset profile as an
> > audio device. What we need is a generic SCO kernel module with a well
> > defined interface that is between the Bluetooth HCI SCO traffic and the
> > ALSA sound layer. This means that if a SCO connection is created the
> > driver must set up a new sound device, but the mixer stuff is profile
> > stuff and must be done by a userspace application.
...
> Summary: -
> 1) The alsa driver for bluetooth will be a kernel mode implementation of
> the bluetooth headset profile.

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.

> 2) A userspace tool will be used to configure the bluetooth pairing and
> configure the alsa-bluez link.
>
> 3) We will need to be able to implement bluetooth profiles in kernel
> modules as well as user space applications.

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.

greetings
Fred