Hi Pali, >>>>>>>>>>>>> to be honest, I would rather see WBS implementation finally >>>>>>>>>>>>> reach PA before we start digging into this. >>>>>>>>>>>> >>>>>>>>>>>> First I want to finish improving A2DP codec support in pulseaudio. Later >>>>>>>>>>>> I can look at HSP/HFP profiles. Ideally it should have modular/plugin >>>>>>>>>>>> extensible design. So the aim is that adding new codec would be very >>>>>>>>>>>> simple, without need to hack something related to mSBC/WBC, AuriStream >>>>>>>>>>>> or any other codec. >>>>>>>>>>> >>>>>>>>>>> Well HSP don't have support for codec negotiation, but yes a modular >>>>>>>>>>> design is probably recommended. >>>>>>>>>>> >>>>>>>>>>>> But for AuriStream I need to set custom SCO parameters as described >>>>>>>>>>>> below and currently kernel does not support it. This is why I'm asking >>>>>>>>>>>> how kernel can export for userspace configuration of SCO parameters... >>>>>>>>>>> >>>>>>>>>>> We can always come up with socket options but we got to see the value >>>>>>>>>>> it would bring since AuriStream don't look that popular among >>>>>>>>>>> headsets, at least Ive never seem any device advertising it like >>>>>>>>>>> apt-X, etc. >>>>>>>>>> >>>>>>>>>> Pali clearly has such device and he is willing to work on it. Surely >>>>>>>>>> that means it is popular enough to be supported...? >>>>>>>>> >>>>>>>>> Just put AT+CSRSF=0,0,0,0,0,7 to google search and you would see that >>>>>>>>> not only I have such device... >>>>>>>>> >>>>>>>>> So I would really would like to see that kernel finally stops blocking >>>>>>>>> usage of this AuriStream codec. >>>>>>>> >>>>>>>> we need to figure out on how we do the kernel API to allow you this specific setting. >>>>>>> >>>>>>> Hi Marcel! Kernel API for userspace should be simple. Just add two >>>>>>> ioctls for retrieving and setting structure with custom parameters: >>>>>>> >>>>>>> syncPktTypes = 0x003F >>>>>>> bandwidth = 4000 >>>>>>> max_latency = 16 >>>>>>> voice_settings = 0x63 >>>>>>> retx_effort = 2 >>>>>>> >>>>>>> Or add more ioctls, one ioctl per parameter. There is already only ioctl >>>>>>> for voice settings and moreover it is whitelisted only for two values. >>>>>> >>>>>> it is not that simple actually. Most profiles define a certain set of parameters and then they try to configure better settings and only fallback to a specification defined default as last resort. >>>>> >>>>> Ok. I see that there is another "example" configuration for AuriStream >>>>> with just different syncPktTypes = 0x02BF and bandwidth = 3850. >>>>> >>>>> So it really is not simple as it can be seen. >>>> >>>> currently the stepping for mSBC and CVSD are hard-coded in esco_param_cvsd and esco_param_msbc arrays in hci_conn.c and then selected by the ->setting parameter. >>>> >>>> So either we provide an new socket option (for example BT_VOICE_EXT) or we extend BT_VOICE to allow providing the needed information. However this needs to be flexible array size since we should then be able to encode multiple stepping that are tried in order. >>>> >>>> My preference is that we extend BT_VOICE and not introduce a new socket option. So feel free to propose how we can load the full tables into the SCO socket. I mean we are not really far off actually. The only difference is that currently the tables are in the hci_conn.c file and selected by the provided voice->setting. However nothing really stops us from providing the full table via user space. >>> >>> Ok. I will look at it and I will try to propose how to extend current >>> BT_VOICE ioctl API for supporting all those new parameters. >>> >>>>>>>> We have kept is really simple since there was only CVSD and mSBC as of now. >>>>>>> >>>>>>> Seems that custom codecs are already widely used, so it would be great >>>>>>> it Linux kernel allows to use also other codecs in future without need >>>>>>> to explicitly whitelist them. >>>>>> >>>>>> This is an overstatement. I see only one custom codec being used. Unless you have heard from others. However as stated above, I think we need to provide an array of settings that are similar defined to what the HFP spec does. Then we just load the whole set into the kernel. >>>>> >>>>> CVSD and mSBC are in use. IIRC specification also mandates ulaw a alaw >>>>> codecs but I have not seen it used. Has somebody tried to implement it? >>>>> I think just replacing voice_settings should be enough as encoding / >>>>> decoding should be done in bluetooth firmware / hardware. >>>>> >>>>> And then there is AuriStream which based on google results it supported >>>>> by lot of headsets. >>>>> >>>>> So at least 3 different codecs are widely supported by headset. >>>> >>>> The ulaw and alaw air codecs are in theory possible, but nobody in the history of Bluetooth has used them. So just ignore that part of the specification. For air codecs you have either CVSD or transparent. And then with transparent you get mSBC and AuriStream. >>> >>> More interesting question would be if alaw codec can be used in >>> transparent mode by transmitter and in "normal alaw" mode by receiver. >>> So it is possible to "tell" bluetooth chip "hey, I have already prepared >>> alaw or CVSD packets for you”? >> >> actually alaw is an over the air codec. Using it in transparent mode has no profile support. So while possible, it is not interoperable. > > I'm looking at Voice Setting parameters and it is possible to set Input > Coding Format to alaw and also Air Coding Format to alaw. It is not > Transparent Air mode, so above problem with profile interoperability > does not have to be there. So in theory it should be possible to > configure bluetooth chip to pass-thru alaw data without re-encoding > them. So after new API for "unlocking" other non-whitelisted Voice > Settings is there, this can start to be tested... > > Apparently there is no CVSD Input Coding Format in Voice Setting, so > CVSD codec data cannot be pass-thru to bt chip via existing Setup > Synchronous Connection. But there is Enhanced Setup Synchronous > Connection command which does not use Voice Setting structure which > seems to be more powerfull in codec handling. ignore the alaw and ulaw codecs since they are not used. It is a relic from the early years of Bluetooth. Regards Marcel
