Hi Fred, >> So I would actually propose to add a voice settings uint16 value as SCO >> socket field. Using the full voice settings make sense since then we can >> also retrieve the fact if we are doing 8-bit or 16-bit PCM. One detail >> we kinda ignored since we always defaulted to 16-bit, but would be worth >> while fixing while at it. > > I'm unconvinced about this. This mean the application wil be able to mess into > what voice settings will be supported. And if csa2 has to be supported > in the future, > a new socket option will be required. > Is 8-bit sco support really worth it ? maybe it is not worth supporting 8-bit SCO, but it is a feature that we should not ignore. And in case you want to do multiple SCO connections (some people want to actually), one way of getting less bandwidth usage is to switch to 8-bit PCM. So my current thinking is that we should support it. Right now I am for working in the context of what we actually have. The CSA2 is not deployed at this moment and it is rather complex. So my thinking is to do voice setting right now and sort out CSA2 at some point later. Unless someone can come up with a good way of integrating CSA2 right now and allow a smooth backward compatibility to non CSA2 devices. That all said, we can always have a socket option later on that enables CSA2 features. 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
