Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
USB sends one message each millisecond, or eight messages in each 8 ms isochronous (ISOCH) window. For flow control purposes, the size of the Audio Render message is modulated by the flow field in the Audio Capture message. This is the mechanism GIP devices use to eliminate pops and clicks in audio.
The size of the audio capture message SHOULD never vary. The host compensates for overflow/underflow conditions in the capture stream.
Example 1: A controller with 48 kHz render / 24 kHz capture stereo headset attaches via USB. Initial flow rates are as follows:
192 bytes/packet downstream (render)
= 48 samples/ms (kHz) * 16 bits/sample * 1 byte/8 bits * 2 channels * 1 ms/packet48 bytes/packet upstream (capture)
= 24 samples/ms (kHz) * 16 bits/sample * 1 byte/8 bits * 1 channel * 1 ms/packet
The flow rate field of capture messages SHOULD initially contain the value 192. This field modulates by +/- one sample per channel per 1 ms, depending on audio buffering conditions in the device, so over time this value can fluctuate between 188, 192, or 196.
Example 2: A controller with 24 kHz render / 24 kHz capture mono headset attaches via USB. Initial flow rates are as follows:
48 bytes/packet upstream and downstream
= 24 samples/ms (kHz) * 16 bits/sample * 1 byte/8 bits * 1 channel * 1 ms/packet
The flow rate field of capture messages SHOULD initially contain the value 48. This field modulates by +/- one sample per channel per 1 ms, depending on audio buffering conditions in the device. So over time this value SHOULD be 46, 48, or 50.
If a device supports only render, it can still send Audio Capture messages with no payload other than the flow rate to implement rate adaptation.
If a device allows for rerouting captured audio elsewhere (that is, paired Bluetooth host), the device MUST still transmit Audio Capture messages to the GIP host but instead with silence (zeroes).
Note: Communication between primary and secondary devices is not defined by this specification. The primary device might buffer on behalf of the secondary and therefore it is unlikely that messages from the secondary could be simply implemented as pass-through from the secondary.
If you require assistance with this documentation, contact gip@microsoft.com.