Re: [Bluez-devel] SCO. Some ideas.

[James Courtier-Dutton <James@superbug.demon.co.uk>]

Marcel Holtmann wrote:
> Hi James,
> 
> 
>>As SCO over bluetooth is only really suitable for audio sound data, I 
>>see no real problem with alsa being the only interface in linux to send 
>>data over a bluetooth SCO connection. (only the actually sco data, not 
>>the bluetooth profile control)
>>Does anyone see a problem with that?
> 
> 
> there are two interfaces with Bluetooth 1.2. SCO/eSCO audio and eSCO
> data. This means we need an ALSA interface and a socket interface.

Ok, I have not looked into eSCO yet.

> 
> 
>>If people think we should also make it easy to add an OSS driver, and 
>>also a network socket driver, we could maybe work out some devision 
>>between the SCO specifics and the ALSA specifics. But for a first 
>>attempt, we should keep the SCO and ALSA driver tightly matched.
> 
> 
> We need the socket driver, but we don't need an OSS driver. But I see no
> problem with this, because the RFCOMM layer also includes socket and TTY
> support at the same time.
> 
> 
>>Therefore maybe making the bluetooth sco and alsa-sco module being the 
>>same module, with an ioctl interface so that a user space application 
>>can handle the creation of bluetooth profile SCO pairing.
> 
> 
> Yes. Only one kernel module called sco.
Agreed.
> 
> 
>>For example, if using a Headset profile, the alsa PCM and alsa MIXER 
>>device would only appear if the userspace application had already set up 
>>the RFCOMM connections. The userspace application would also have to 
>>have set up the bluetooth specific details for the SCO connection, so 
>>that when alsa opens the PCM, it has enough information to open a SCO 
>>connection.
> 
> 
> ALSA don't open the SCO connection. This is part of the application that
> implements the profile. In the case of the headset profile, you must
> first have the RFCOMM connection and then the SCO link. No SCO link
> without an ACL link.
ALSA app calls snd_pcm_open(), but we will make this call fail if the 
application that implements the profile is not yet ready for SCO audio data.

> 
> 
>>I have looked at this for the alsa->sco->bluetooth->hci_usb  drivers.
>>The alsa driver has to be able to do the following: -
>>1) open - this should check that all bluetooth connections are up that 
>>need to be up in order for SCO data to pass. It could do this via 
>>interaction with the userspace bluetooth profile.
> 
> 
> If there is no SCO link -> failure.
Agreed.
> 
> 
>>2) close - close everything neatly.
> 
> 
> Of course, but the SCO link should be closed by the application.

I think I need to understand a bit more about what it actually set when 
one opens a SCO connection. I thought all that happens is that a 
connection number is decided on. If setting up a SCO connection also 
fixes the voice setting, then I would like to allow alsa to have some 
influence over this if possible.

> 
> 
>>3) hw_params - allocate buffers etc. for the pcm audio as well as the 
>>hw_params config. Can be called multiple times, so re-alloc of buffers 
>>should be allowed for. hw_params are things like sample rate, number of 
>>channels, PCM format. Obviously there are limits on what these values 
>>can take when using bluetooth. 16bit PCM, 8bit PCM, 8bit A-law, 8bit 
>>u-Law. Start by also limiting it to 1 PCM channel. I.E. Mono and not stereo.
> 
> 
> The possible values depends on the voice setting.
This is something I need to be able to understand better.
What should actually be adjusting the voice setting? To me it seems 
sensible that we should try to get the voice setting to match the alsa 
PCM samples if we can.
Of course, another approach is getting the application to set the voice 
setting, and then open the SCO link, and then force alsa to use whatever 
voice setting the SCO link was set to. We would get the application to 
inform alsa about this voice setting via an ioctl.

> 
> 
>>4) pcm_prepare - actually set the hw_params. e.g. do the equivalent of 
>>hciconfig hci0 voice XX, where XX depends on the hw_params.
>>Also selecting usb alt profiles.
>>The only difference between hw_params and pcm_prepare is that 
>>pcm_prepare is called for xrun recovery.
> 
> 
> I am not sure if we should allow the ALSA driver to change the voice
> settings. As I know it is not possible to change the voice setting of an
> already existing SCO link.
> 
> 
>>5) trigger - actually start/stop usb_urbs (e.g. call 
>>usb_submit_urb/usb_unlink_urb now.)
> 
> 
> Not part of the ALSA driver. This is a problem of the HCI USB driver.
The alsa-driver receives a trigger() api call from an alsa based 
application. It would be nice to pass this trigger() function on down 
the stack to whichever bluetooth hci driver we are using (hci_usb or 
whatever else), and that hci driver handle it appropriately.
I just gave the usb_submit_urb() as an example of what the hci_usb.c 
driver would do when it received the trigger() call.
For example. The SCO link is open, but no actual sound samples start 
being sent or received from the CPU until the trigger() call.

> 
> 
>>6) pointer - get hw_usb_frame_pointer and modify the result to simulate 
>>an audio ring buffer of the size configured in the hw_params.
>>When retrieving the pointer, one should also retrieve the valid range 
>>that the pointer can have, so one can adjust for pointer wrap around.
>>For usb, this would be the usb_get_current_frame_number() for the 
>>pointer, and dev->bus->iso_sched_frames for the range of values it can take.
> 
> 
> The SCO interface is not driver specific. So no interaction we the HCI
> USB driver.
I was using the HCI USB driver as an example only.
The alsa-driver receives a pointer() from the alsa based application. we 
need to pass a call to the HCI driver (hardware independently) which 
would return the frame pointer. I don't think the concept of a 
frame_pointer is USB specific. Any Bluetooth hardware driver will use a 
frame_pointer.

> 
> 
>>7) period_time_elapsed - hci_usb should call this on each urb_complete 
>>call. For our use, it seems sensible to make 1 urb == 1 alsa period.
>>
>>If we can let the alsa bluetooth audio driver have access to the 
>>hardware pointers (in this case the usb current frame pointers), we will 
>>get a much more accurate idea of exactly which audio sample is currently 
>>being played.
>>
>>Also, letting alsa control period and buffer sizes, and getting that to 
>>directly determine usb urb sizes, we would give complete control of 
>>buffer sizes to the application, which is vital for low latency 
>>applications like Voice over IP.
> 
> 
> No. ALSA <-> SCO is driver and hardware independent.
Again, I was only using USB as an example, the period_time_elapsed can 
be called by any bluetooth hardware. E.g. In the interrupt handling routine.

> 
> 
>>Summary: -
>>we need to provide up to the sco level, control of low level usb 
>>interface isoc parameters. E.g. prepare, trigger, pointer, 
>>period_time_elapsed, hw_params.
>>
>>If people are happy with this proposal, I will start writing the alsa 
>>driver, and also start adding to the bluetooth -> hci_usb driver api to 
>>allow for it. The api will only change for SCO data handling, as Bulk 
>>and Int handling don't need such fine controls.
> 
> 
> Let me repeat it. The upper interface to SCO is driver and hardware
> independent.
> 
> We need to extend the HCI USB driver to support start/stop of ISOC URB's
> on demand and to select the right alternate settings. And this means to
> split the hash for number of ACL/SCO connections and send a notification
> to the driver if a new connection is created/released of if the voice
> settings are changed. We already talked about this stuff. I had already
> a patch for it, but the hash split was missing.
OK, I have not seen that patch yet.

> 
> The ALSA <-> SCO driver should be written with the current API provided
> by the HCI layer. Check how the current SCO driver gets and sends its
> data packets. Start with this driver and don't worry so much about the
> USB specific part. Use voice setting 0x0060 as the only supported value
> at the moment.

Maybe I should look at the patch first, but ..
I cannot see anywhere in the current HCI layer api where I can find out 
which HCI SCO packet is currently(in realtime) being output. All I know 
is that if I send an HCI SCO packet down the stack, it will get queued, 
and at some point be output. That is not good enough.

> 
> Regards
> 
> Marcel
> 
> 
> 
> 


Cheers
James