_BRB_SCO_TRANSFER - NtDoc
Native API online documentation, based on the System Informer
(formerly Process Hacker) phnt
headers
// bthddi.h
struct _BRB_SCO_TRANSFER {
BRB_HEADER Hdr;
BTH_ADDR BtAddress;
SCO_CHANNEL_HANDLE ChannelHandle;
ULONG TransferFlags;
ULONG BufferSize;
PVOID Buffer;
PMDL BufferMDL;
ULONGLONG DataTag;
};
View the official Windows Driver Kit DDI referenceNo description available.
The _BRB_SCO_TRANSFER structure describes a buffer to read isochronous data from, or write isochronous data to a SCO channel.
HdrA BRB_HEADER structure that contains information about the current BRB.
BtAddressThe Bluetooth address of the remote device.
ChannelHandleThe SCO channel handle that was returned by Bluetooth driver stack in response to an earlier BRB_SCO_OPEN_CHANNEL or BRB_SCO_OPEN_CHANNEL_RESPONSE request.
TransferFlagsFlags that specify the basic behavior of the BRB. Valid flag values are listed in the following table.
| Flag | Description |
|---|---|
| SCO_TRANSFER_DIRECTION_IN | If this bit is set, the BRB reads isochronous data from a remote device through the SCO channel. |
| SCO_TRANSFER_DIRECTION_OUT | If this bit is set, the BRB writes isochronous data to a remote device through the SCO channel. |
BufferSizeThe size, in bytes, of the input buffer described by the Buffer member of this structure.
BufferA pointer to the input buffer. This value should be NULL when the Buffer member is not used.
BufferMDLA pointer to the MDL input buffer. This value should be NULL when the BufferMDL member is not used.
DataTagSCO write
To read isochronous data from or write isochronous data to a SCO connection, profile drivers should build and send a BRB_SCO_TRANSFER request.
Each SCO connection is bidirectional, and can be read from and written to simultaneously.
Read BRBs will remain pending until data arrives or until the profile driver flushes them. It is recommended that higher-level drivers have at least two pending read BRBs open at any time to accept incoming data from the remote device.
The Bluetooth driver stack does not provide any buffering for incoming isochronous data. Therefore a small gap between the completion of one read IRP and the submission of the next can cause data loss.
If both Buffer and BufferMDL contain non-NULL values, then BufferMDL takes precedence.