Re: [rfc]btusb with SCO support

[Marcel Holtmann <marcel@holtmann.org>]

Hi Oliver,

> > yeah, I was afraid of that switching the alternate settings is not as  
> > easy as the spec. might think. Personally I think it is a broken  
> > specification anyway. So the best assumption is that we have one SCO  
> > connection and that is either 8-bit or 16-bit. So we do the switching  
> > when we get the notify() callback for a changed voice setting.
> 
> That's problematic because in the notify() callback you cannot sleep,
> can you? In addition, a device is legally allowed to take a lot of time
> to switch altsettings.

that was not my point. My point was to switch between first or second
alternate setting when you get the notify() callback for a changed voice
setting. Check with the "hciconfig hci0 voice 0x0040" command.

We have to do it in a work queue and that is fine, but then when we get
a connection add notify(), then we only have to start the SCO URBs. This
leaves the only broken case where we have to switch the alternate
setting, because the second SCO channel got established.

Question is if selecting the 2nd alternate setting and not submitting
the URBs for it is a good idea or if that will still consume bandwidth
and power. And thus it would be better to use the first alternate
setting that is meant for the case with no SCO connections.

Regards

Marcel