none
Bluetooth SCO - ContentFormat field RRS feed

  • Question

  • Hi,
    I am trying to open a Bluetooth SCO connection. I succeeded in opening this connection, but now I do not know what type of audio data should I send? The problem is the MSDN doesn't describe meaning of the following BRB_SCO_OPEN_CHANNEL fields:
    - ContentFormat
    - PacketType

    I have set ContentFormat = SCO_VS_SETTING_DEFAULT, and PacketType = SCO_HV1 | SCO_HV3, and it works: the connection is opened. But what does it mean? Which audio codec should I use (desirable present in Windows) in order to encrypt/decrypt channel's data? Can it be PCM? CVSD? Does Windows include CVSD audio codec?
    • Edited by RedSoftk Tuesday, June 4, 2013 4:35 PM
    Tuesday, June 4, 2013 4:32 PM

Answers

  • Please review the Bluetooth hands-free profile specification. That profiles defines how the AG and HF entities communicate (encoding/decoding).

    Normally the encoding is done at the Bluetooth radio (CVSD is the default one), this means that you send PCM data and radio will take care to encode it. It also possible for the encoding logic to be outside the radio, in this case you need to select 'transparent' as encoding for the Bluetooth radio.

    You can find this info in the Bluetooth profile specification. 

    Tuesday, June 4, 2013 9:49 PM
  • - About the packet types, use the  BRB_SCO_GET_SYSTEM_INFO to find out the supported packet types. You can use that info into your open.

    - You should not depend on how the SCO layer fragments the data. the size of these fragments depend on the packet type used by the underline infrastructure.

    - You should pend 3+ request.

    - The amount of data in the request depends on the latency you want, more data you have, higher is the latency. For example low latency: send at least 10msec data in each request. If latency is not an issue, send more data in the request, the more the better (for quality).

    - When you are done with SCO, send a BRB_SCO_FLUSH_CHANNEL to free the last request, just in case there was any residual data in there.  

    - For voice compression, you need to follow the Bluetooth specifications of the profile you are implementing. If you are doing this just for fun and you are writing both side (sender and receiver), well, in this case you can define what you want as long as you are consistent, play around and see what it works.

    • Marked as answer by RedSoftk Thursday, June 20, 2013 5:27 PM
    Sunday, June 9, 2013 6:04 PM

All replies

  • Please review the Bluetooth hands-free profile specification. That profiles defines how the AG and HF entities communicate (encoding/decoding).

    Normally the encoding is done at the Bluetooth radio (CVSD is the default one), this means that you send PCM data and radio will take care to encode it. It also possible for the encoding logic to be outside the radio, in this case you need to select 'transparent' as encoding for the Bluetooth radio.

    You can find this info in the Bluetooth profile specification. 

    Tuesday, June 4, 2013 9:49 PM
  • Thanks for explanation.
    But it still exists some inconsistency in MSDN and the Bluetooth standard: the definition of the PacketType field. The standard defines packet type HV1=0101 bin (10 data bytes transmitted every 2 slots), but bthddi.h contains the following definitions:
    #define SCO_HV1  (0x0001)
    #define SCO_HV2  (0x0002)
    #define SCO_HV3  (0x0004)
    #define SCO_EV3  (0x0008)
    #define SCO_EV4  (0x0010)
    #define SCO_EV5  (0x0020)

    So in order to set HV1 type according to the standard, I need to set PacketType=SCO_HV1|SCO_HV3. Is it correct?



    • Edited by RedSoftk Wednesday, June 5, 2013 7:28 PM
    Wednesday, June 5, 2013 7:25 PM
  • 0101 bin for HV1 doesn't look right.

    To select HV1 you need to specify SCO_HV1 in PacketType. The Microsoft SCO layer translates this info into the right mapping. So SCO_HV1 | SCO_HV3 is NOT correct, just use SCO_HV1.

    • Marked as answer by Doron Holan [MSFT] Thursday, June 6, 2013 6:23 PM
    • Unmarked as answer by RedSoftk Friday, June 7, 2013 11:45 AM
    Thursday, June 6, 2013 3:24 PM
  • When setting PacketType=SCO_HV1 value the result callback receives IoStatus.Status = C000000D (STATUS_INVALID_PARAMETER)!!!
    I have tried also PacketType= SCO_HV2, SCO_HV3, SCO_EV3 (BTW what does it mean - SCO_EVx?) - the connection establishment completes Ok. But the following data sending fails as follows: WdfRequestSend() returns Ok, but the completion callback (passed to WdfRequestSetCompletionRoutine) is not called! As result the application has stuck.
    What is possible problem? Is it some incorrect settings I pass to the connection BRB. Following is my BRB:

    brb->BtAddress            = <some address>

    brb->TransmitBandwidth   = brb->ReceiveBandwidth  = 8000;  // 64Kb/s
    brb->MaxLatency          = 0xFFFF;
    brb->PacketType           = SCO_HV3;
    brb->ContentFormat      = SCO_VS_IN_CODING_LINEAR | SCO_VS_IN_SAMPLE_SIZE_8BIT | SCO_VS_AIR_CODING_FORMAT_CVSD;
    brb->RetransmissionEffort= SCO_RETRANSMISSION_NONE;
    brb->ChannelFlags  = SCO_CF_LINK_SUPPRESS_PIN;
    brb->CallbackFlags  = SCO_CALLBACK_DISCONNECT;    // Get notification about remote disconnect
    brb->Callback               = <my callback>;
    brb->CallbackContext    = connection;
    brb->ReferenceObject    = (PVOID) WdfDeviceWdmGetDeviceObject(DevCtx->Header.Device);



    • Edited by RedSoftk Friday, June 7, 2013 4:19 PM
    Friday, June 7, 2013 11:43 AM
  • Before I didn't ask why you wanted only HV1. If your goal is to setup a SCO connection independently of the underline packets, you should allow all packets types on that connection. It may be possible that the system fails the HV1 b/c (a) it doesn't support it or (b) it takes too much bandwidth, you should allow all SCO packet types. The SCO layer selects the best one to use. SCO_EVx are enhanced packets types used for ESCO (Enhanced SCO).

    About the completion routine, it may be possible that the data in the request is not a multiple of the packet size used by the SCO layer, and in this case SCO is waiting for the next request before releasing the current one. Or try using BRB_SCO_FLUSH_CHANNEL to release the current request. Keep in mind that SCO is a continuous stream of data.

    Friday, June 7, 2013 5:42 PM
  • Egidio, thanks for the answers. I have set PacketType = SCO_PKT_ALL, supposing the SCO layer will select the best one.
    Concerning the incomplete send, it is a real problem. I would like to get some clarifications of this matter. These are my thoughts:
      1) In the case “the data in the request is not a multiple of the packet size used by the SCO layer” – is there any way to know this packet size? So I will pass to the SCO layer the expected data size.
      2) In the case the answer 1) is negative, can you give a hint about approximate size of this SCO packet? Is it 10-30 bytes or 500, or may be 4-5 Kbytes?
    According to the standard, the translated SCO data are placed in PHY slots, and its data and rate depend on the packet type:
    - HV1 High quality Voice(1/3 rate FEC) 10 data bytes transmitted every 2 slots
    - HV2 High quality Voice(2/3 rate FEC) 20 data bytes transmitted every 4 slots
    - HV3 High quality Voice(no error correction)30 data bytes transmitted every 6 slots
    Is it any correlation between slot’s data and the mentioned packed size on SCO layer?
      3) Another my thought is the voice compression on the radio layer (I chose CVSD) may insert additional packet size/data alignments problems. So I also want to try to work in ‘transparent’ mode, as you previously had explained. But I didn’t find how to configure this mode when establishing the connection. Is it possible? I see it is only present getting method using BRB_SCO_GET_CHANNEL_INFO, but it seems no method to set.

    • Edited by RedSoftk Saturday, June 8, 2013 9:21 AM
    Saturday, June 8, 2013 9:15 AM
  • - About the packet types, use the  BRB_SCO_GET_SYSTEM_INFO to find out the supported packet types. You can use that info into your open.

    - You should not depend on how the SCO layer fragments the data. the size of these fragments depend on the packet type used by the underline infrastructure.

    - You should pend 3+ request.

    - The amount of data in the request depends on the latency you want, more data you have, higher is the latency. For example low latency: send at least 10msec data in each request. If latency is not an issue, send more data in the request, the more the better (for quality).

    - When you are done with SCO, send a BRB_SCO_FLUSH_CHANNEL to free the last request, just in case there was any residual data in there.  

    - For voice compression, you need to follow the Bluetooth specifications of the profile you are implementing. If you are doing this just for fun and you are writing both side (sender and receiver), well, in this case you can define what you want as long as you are consistent, play around and see what it works.

    • Marked as answer by RedSoftk Thursday, June 20, 2013 5:27 PM
    Sunday, June 9, 2013 6:04 PM