Re: [snd-bt-sco] bluetooth headset profile with alsa in user space.

[Brad Midgley <bmidgley@xmission.com>]

James,

I've looked at this too. I'm crossposting to see if Marcel wants to comment.

Some people think bluetooth-alsa should have a smaller kernel footprint 
and some people think it's the userspace component that needs to be 
eliminated. The bottom line is that it needs to go in a direction that 
is acceptable to bluez and alsa but doesn't leave so much to be desired 
by the bluez group that they feel like reimplementing/rejecting it.

the less-kernel-space argument

- alsa would not be affected [much]
- bluez would only be affected in that we may want hooks to go into 
libbluetooth
- userspace stuff is easier to debug and develop
- supporting multiple headsets simultaneously should be more straightforward
- kernel developers won't be questioning it
- adding it to a linux distro that has bluez already would be easier

The more-kernel-space argument:

- alsa has said they would consider patches that don't have the 
userspace entanglements
- the bluez project leaders may decide that in-kernel is the way audio 
has to be done
- dbus/hotplug may play nicer with an in-kernel driver

I think now the less-kernel-space is safer. Regardless of our approach, 
apps that want bluetooth-alsa like asterisk will have to be linked with 
a new library so there's not a disadvantage there with another build 
requirement. There's probably just too much uncertainty with the 
in-kernel approach.

Brad

James Courtier-Dutton wrote:
> It is possible to implement an alsa device is user space, without 
> requiring any kernel modules. An example of this the the pcm_jack.c file 
> in:
> ./alsa-lib/src/pcm/ext/pcm_jack.c
> 
> It basically makes jackd look like a sound card to any alsa application.
> 
> This should help, because the bluetooth profile code is in user space as 
> well, so we could make the bluetooth profile look like an alsa sound card.
> 
> Any comments?
> 
> James
> 
>