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 -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
