Second look: add support for HFP and mSBC

[kuikka]

Let's try this again. I fixed all the points you commented about in the previous pull request.

I was also able to test the mSBC support on Marvell 8897 and it does work. There is slight underflow so the flow control may require some more tweaking.

[arkq]

Looks, good. I haven't tested it by myself yet, though.

I'd like to pull some commits already, e.g. transparent mode for socket, SCO codecs. It will reduce a little bit this PR, so it will be easier to track changes. However, it might be an extra work for you, because this will reorder commit history, and I will make some minor code style fixes. What do you think?

[kuikka]

Feel free to merge what you feel like, or even all of it. Since the mSBC is very self contained it shouldn't be a problem when I keep working on it.

[kuikka]

That being said, I have identified some issues with the way I do the mSBC flow control. I took some assumptions that turn out not to be true on every controller. For example, on the Marvell 8897 the SCO MTU is 120 and the HCI bitrate is 8000 bytes/s, same as the air rate. This means that sending the 59 byte frames with one byte of padding is very convenient. However, on a Broadcom controller I have the SCO MTU is 48 but the HCI SCO bitrate is 16000 which means I cannot rely on the incoming data to easily synchronize. I need more sophisticated buffering and flow control mechanism here.

[arkq]

At the end, I'd like to merge it all, of course. However, in order to maintain the code I have to understand how it works (maybe not thoroughly, but at least the logic behind it). Right now, the mSBC flow is not very clear for me, I must say :) When I finalize my struggle with the "PCM delay" (I've lost count how many approaches I've made... and it's still not right) I'll try to learn how the HFP works, and I'll proceed with merging this PR.

Once again, many tanks for the contribution!

[kuikka]

I understand. I am currently refactoring the whole mSBC flow as the current one doesn't work in every case. I think I may end up using a similar mechanism to what you already have for the sync but the frames vs MTU makes it difficult.

Once I have it nailed down I'll be sure to add some comments on how it works so we don't forget it.

[arkq]

I've pulled following commits (and squashed them, so the rebase won't be clean, sorry for that):

• Add codec and flags fields into SCO transport
• ctl: Ignore SCO transports that don't have a codec selected yet
• Add HFP header file
• Add option to configure SCO socket to transparent mode
• transport: Set SCO socket into transperent mode if mSBC is used
• transport: Set SCO codec type upon creation if known

Also, I've taken the liberty to make some changes (I hope you don't mind). I've removed the enum sco_codec in favour of hfp.h header file, which will be consistent with the a2dp-codecs.h. The codec is stored in the transport.codec field (not in the transport.sco.codec), because it was an unnecessary redundancy (imho).

I've changed a little bit the logic behind the initialisation of the transparent voice mode: t->sco.codec == HFP_CODEC_MSBC -> t->codec != HFP_CODEC_CVSD. I'm not sure if it's right, though. The reason for this was the fact that internally kernel supports CVSD only, so anything else has to be handled in the userspace - hence, transparent mode.

[arkq]

Hi,

I've just pulled another piece of this PR into the master. Basically, everything except mSBC support is now merged :). I've tested HFP AG with Jabra MOVE v2.3.0 and it seems to be working just fine. @kuikka, many thanks for your contribution!