Re: [snd-bt-sco] Re: [Bluez-devel] snd-bt-sco development teamup | ALSA connection

[Marcel Holtmann <marcel@holtmann.org>]

Hi Jonathan,

> > If you mean with that when someone opens the DSP device we should create
> > the connection, then this will fail. The RFCOMM channel must be created
> > first and this is part of the connection handling from userspace. The
> > kernel can't do anything here.
> 
> A user space daemon can, however, keep a file descriptor open on the ALSA 
> device's hwdep interface. The kernel driver could notify the daemon when 
> an app opens the device, at which point the daemon can take a policy 
> decision about attempting to connect to some default headset device (which 
> eventually results in binding the SCO socket to the device).
> 
> > The general workflow should be something like this:
> >
> > 	- create RFCOMM channel and start AT handling
> > 	- create SCO socket if needed
> > 	- issue ioctl to make SCO socket an ALSA device
> 
> I think that the creation of ALSA devices and binding of SCO socket to an 
> ALSA device should be separate operations. That way, an ALSA device can 
> exist with no attached headset. Using the technique described above, that
> device can be demand-connected to a particular SCO socket.

if this works we may can implement something like "rfcomm bind ...". The
creation of the ALSA device can be handled through a SCO raw socket like
we did it for RFCOMM.

Regards

Marcel




-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel