Le 09/04/2013 17:30, Marcel Holtmann a écrit :
Hi Fred,
#define SCO_SETTINGS 0x03
struct sco_settings {
__u16 settings;
};
That is my current thinking. However we might start using SOL_BLUETOOTH and start using BT_VOICE or similar as a socket option. I do want to be able to retire SOL_SCO and SOL_L2CAP at some point.
I just forgot about this because I don't use it and this API satisfy my needs, but it does not allow to distinguish between host side and adapter side mSBC.
Do you still care about this?
what do you mean by host side and adapter side difference? I am not following.
I was thinking that an adapter could do some adapter side mSBC similar
to the way SCO over PCM works. (ie when connected the adapter
automatically encode and forward packet to/from his PCM port).
If it doesn't make sense, just forget about it.
The socket option would look like this (in bluetooth.h) :
#define BT_VOICE 11
struct bt_voice {
__u16 setting;
};
#define BT_VOICE_TRANSPARENT 0x0003
#define BT_VOICE_CVSD 0x0060
Regards,
Fred
--
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
