Revision: v1.0
Revision Date: 2020-12-15
Group Prepared By: Generic Audio Working Group
Abstract:
This specification describes the service that exposes the gain of an audio input.
Revision History
|
Revision Number |
Date |
Comments |
|---|---|---|
|
v1.0 |
2020-12-15 |
Adopted by the Bluetooth SIG Board of Directors. |
Contributors
|
Name |
Company |
|---|---|
|
Michael Rougeux |
Bose Corporation |
|
Siegfried Lehmann |
Apple, Inc. |
|
Tim Reilly |
Bose Corporation |
|
Robin Heydon |
Qualcomm, Inc. |
|
Asbjørn Sæbø |
Nordic Semiconductor ASA |
|
Georg Dickmann |
Sonova AG |
|
Bjarne Klemmensen |
Oticon A/S |
|
HJ Lee |
LG Electronics Inc. |
|
Marcel Holtmann |
Intel Corporation |
|
Masahiko Seki |
Sony Corporation |
|
Søren Møllskov Larsen |
Widex A/S |
|
Daniel Sisolak |
Bose Corporation |
|
Oren Haggai |
Intel Corporation |
|
Frank Yerrace |
Microsoft Corporation |
Use of this specification is your acknowledgement that you agree to and will comply with the following notices and disclaimers. You are advised to seek appropriate legal, engineering, and other professional advice regarding the use, interpretation, and effect of this specification.
Use of Bluetooth specifications by members of Bluetooth SIG is governed by the membership and other related agreements between Bluetooth SIG and its members, including those agreements posted on Bluetooth SIG’s website located at www.bluetooth.com. Any use of this specification by a member that is not in compliance with the applicable membership and other related agreements is prohibited and, among other things, may result in (i) termination of the applicable agreements and (ii) liability for infringement of the intellectual property rights of Bluetooth SIG and its members. This specification may provide options, because, for example, some products do not implement every portion of the specification. Each option identified in the specification is intended to be within the bounds of the Scope as defined in the Bluetooth Patent/Copyright License Agreement (“PCLA”). Also, the identification of options for implementing a portion of the specification is intended to provide design flexibility without establishing, for purposes of the PCLA, that any of these options is a “technically reasonable non-infringing alternative.”
Use of this specification by anyone who is not a member of Bluetooth SIG is prohibited and is an infringement of the intellectual property rights of Bluetooth SIG and its members. The furnishing of this specification does not grant any license to any intellectual property of Bluetooth SIG or its members. THIS SPECIFICATION IS PROVIDED “AS IS” AND BLUETOOTH SIG, ITS MEMBERS AND THEIR AFFILIATES MAKE NO REPRESENTATIONS OR WARRANTIES AND DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING ANY WARRANTIES OF MERCHANTABILITY, TITLE, NON-INFRINGEMENT, FITNESS FOR ANY PARTICULAR PURPOSE, OR THAT THE CONTENT OF THIS SPECIFICATION IS FREE OF ERRORS. For the avoidance of doubt, Bluetooth SIG has not made any search or investigation as to third parties that may claim rights in or to any specifications or any intellectual property that may be required to implement any specifications and it disclaims any obligation or duty to do so.
TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, BLUETOOTH SIG, ITS MEMBERS AND THEIR AFFILIATES DISCLAIM ALL LIABILITY ARISING OUT OF OR RELATING TO USE OF THIS SPECIFICATION AND ANY INFORMATION CONTAINED IN THIS SPECIFICATION, INCLUDING LOST REVENUE, PROFITS, DATA OR PROGRAMS, OR BUSINESS INTERRUPTION, OR FOR SPECIAL, INDIRECT, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, AND EVEN IF BLUETOOTH SIG, ITS MEMBERS OR THEIR AFFILIATES HAVE BEEN ADVISED OF THE POSSIBILITY OF THE DAMAGES.
Products equipped with Bluetooth wireless technology ("Bluetooth Products") and their combination, operation, use, implementation, and distribution may be subject to regulatory controls under the laws and regulations of numerous countries that regulate products that use wireless non-licensed spectrum. Examples include airline regulations, telecommunications regulations, technology transfer controls, and health and safety regulations. You are solely responsible for complying with all applicable laws and regulations and for obtaining any and all required authorizations, permits, or licenses in connection with your use of this specification and development, manufacture, and distribution of Bluetooth Products. Nothing in this specification provides any information or assistance in connection with complying with applicable laws or regulations or obtaining required authorizations, permits, or licenses.
Bluetooth SIG is not required to adopt any specification or portion thereof. If this specification is not the final version adopted by Bluetooth SIG’s Board of Directors, it may not be adopted. Any specification adopted by Bluetooth SIG’s Board of Directors may be withdrawn, replaced, or modified at any time. Bluetooth SIG reserves the right to change or alter final specifications in accordance with its membership and operating agreements.
Copyright © 2018–2020. All copyrights in the Bluetooth Specifications themselves are owned by Apple Inc., Ericsson AB, Intel Corporation, Lenovo (Singapore) Pte. Ltd., Microsoft Corporation, Nokia Corporation, and Toshiba Corporation. The Bluetooth word mark and logos are owned by Bluetooth SIG, Inc. Other third-party brands and names are the property of their respective owners.
1. Introduction
This service enables a device to expose the control and state of an audio input.
1.1. Conformance
If conformance to this specification is claimed, all capabilities indicated as mandatory for this specification shall be supported in the specified manner (process-mandatory). This also applies for all optional and conditional capabilities for which support is indicated.
1.2. Service dependencies
This service is not dependent upon other services.
1.3. Bluetooth Core Specification release compatibility
This specification is compatible with any version of the Bluetooth Core Specification [1] that includes the Generic Attribute Profile (GATT).
1.4. GATT sub-procedure requirements
Requirements in this section represent a minimum set of server requirements. Other GATT sub‑procedures may be used if supported by both the client and server.
Requirements in this section are defined as “Mandatory” (M), “Optional” (O), “Excluded” (X), and “Conditional” (C.n). Conditional statements (C.n) are listed directly below the table in which they appear.
Table 1.1 summarizes additional GATT sub-procedure requirements beyond those required by all GATT servers over Unenhanced Attribute Protocol (ATT) bearers.
|
GATT Sub-Procedure |
Requirements |
|---|---|
|
Write Characteristic Values |
M |
|
Notifications |
M |
|
Read Characteristic Descriptors |
M |
|
Write Characteristic Descriptors |
M |
1.5. Transport dependencies
This service uses GATT and therefore has no additional transport dependencies.
Notifications with GATT are considered unreliable when used with an Unenhanced ATT bearer.
An Enhanced ATT bearer can be used for reliability of Notifications and can be specified by a higher-layer profile.
1.6. Application error codes
This service defines the ATT Application error codes shown in Table 1.2.
|
Name |
Error Code |
Description |
|---|---|---|
|
Invalid Change Counter |
0x80 |
The Change_Counter operand value does not match the Change_Counter field value of the Audio Input State characteristic. |
|
Opcode Not Supported |
0x81 |
An invalid opcode has been used in a control point procedure. |
|
Mute Disabled |
0x82 |
Mute/unmute commands are disabled. |
|
Value Out of Range |
0x83 |
An operand value used in a control point procedure is outside the permissible range. |
|
Gain Mode Change Not Allowed |
0x84 |
A requested gain mode change is not allowed. |
1.7. Byte transmission order
All characteristics used with this service shall be transmitted with the least significant octet (LSO) first (i.e., little endian). The LSO is identified in the characteristic definitions in the Bluetooth SIG Assigned Numbers [3].
1.8. Language
1.8.1. Language conventions
The Bluetooth SIG has established the following conventions for use of the words shall, must, will, should, may, can, is, and note in the development of specifications:
|
shall |
is required to – used to define requirements. |
|
must |
is used to express: a natural consequence of a previously stated mandatory requirement. OR an indisputable statement of fact (one that is always true regardless of the circumstances). |
|
will |
it is true that – only used in statements of fact. |
|
should |
is recommended that – used to indicate that among several possibilities one is recommended as particularly suitable, but not required. |
|
may |
is permitted to – used to allow options. |
|
can |
is able to – used to relate statements in a causal manner. |
|
is |
is defined as – used to further explain elements that are previously required or allowed. |
|
note |
Used to indicate text that is included for informational purposes only and is not required in order to implement the specification. Each note is clearly designated as a “Note” and set off in a separate paragraph. |
For clarity of the definition of those terms, see Core Specification Volume 1, Part E, Section 1.
1.8.2. Reserved for Future Use
Where a field in a packet, Protocol Data Unit (PDU), or other data structure is described as "Reserved for Future Use" (irrespective of whether in uppercase or lowercase), the device creating the structure shall set its value to zero unless otherwise specified. Any device receiving or interpreting the structure shall ignore that field; in particular, it shall not reject the structure because of the value of the field.
Where a field, parameter, or other variable object can take a range of values, and some values are described as "Reserved for Future Use," a device sending the object shall not set the object to those values. A device receiving an object with such a value should reject it, and any data structure containing it, as being erroneous; however, this does not apply in a context where the object is described as being ignored or it is specified to ignore unrecognized values.
When a field value is a bit field, unassigned bits can be marked as Reserved for Future Use and shall be set to 0. Implementations that receive a message that contains a Reserved for Future Use bit that is set to 1 shall process the message as if that bit was set to 0, except where specified otherwise.
The acronym RFU is equivalent to Reserved for Future Use.
1.8.3. Prohibited
When a field value is an enumeration, unassigned values can be marked as “Prohibited.” These values shall never be used by an implementation, and any message received that includes a Prohibited value shall be ignored and shall not be processed and shall not be responded to.
Where a field, parameter, or other variable object can take a range of values, and some values are described as “Prohibited,” devices shall not set the object to any of those Prohibited values. A device receiving an object with such a value should reject it, and any data structure containing it, as being erroneous.
“Prohibited” is never abbreviated.
1.8.4. Terminology
Table 1.3 defines terms that are needed to understand features used in this service.
|
Term |
Definition |
|---|---|
|
Unenhanced ATT bearer |
An ATT bearer not using the Enhanced Credit Based Flow Control Logical Link Control and Adaptation Protocol (L2CAP) channel mode introduced in Volume 3, Part A, Section 10.2 in the Bluetooth Core Specification [2]. |
|
Enhanced ATT bearer |
An ATT bearer using the Enhanced Credit Based Flow Control L2CAP channel mode introduced in Volume 3, Part A, Section 10.2 in [2]. |
2. Service
2.1. Declaration
There may be one or more instances of the Audio Input Control Service on a device.
The Audio Input Control Service is instantiated to expose the settings of an audio input such as a Bluetooth audio stream, microphone, etc. Multiple audio inputs may be combined as part of the server’s audio mixing functionality.
The Attribute Type service declaration shall be set to the «Secondary Service» universally unique identifier (UUID), and the Attribute Value service declaration shall be set to «Audio Input Control Service» as defined in the Bluetooth SIG Assigned Numbers [3]. The Audio Input Control Service shall only be instantiated as an included service.
2.2. Overview
This section provides an overview of the behavior of the characteristics that affect the audio input’s gain and their usage.
2.2.1. Audio Input State
The Audio Input State characteristic value consists of four fields: the Gain_Setting field, Mute field, Gain_Mode field, and Change_Counter field.
2.2.1.1. Gain_Setting field
The Gain_Setting field controls the amplitude of an individual audio input that the server controls, such as a Bluetooth audio stream or microphone.
The Gain_Setting field is a signed value for which a single increment or decrement should result in a corresponding increase or decrease of the input amplitude by the value of the Gain_Setting_Units field of the Gain Setting Properties characteristic value. A Gain_Setting value of 0 should result in no change to the input’s original amplitude.
The Gain_Setting field’s resolution and range, in decibels (dB), are described by the Gain Setting Properties characteristic value. The Gain_Setting value shall be less than or equal to the Gain_Setting_Maximum field and greater than or equal to the Gain_Setting_Minimum field of the Gain Setting Properties characteristic value.
If the Gain_Mode field value is Automatic or Automatic Only, then the Gain_Setting field does not affect the audio input and the server should ignore the Gain_Setting field’s value.
2.2.1.2. Mute field
The Mute field describes the mute state of the audio input. The Mute field values are described in Table 2.1.
|
Mute Field |
Value |
|---|---|
|
Not Muted |
0 |
|
Muted |
1 |
|
Disabled |
2 |
The Mute field value represents the server’s audio state where a value of Not Muted represents unmuted audio, a value of Muted represents muted audio, and a value of Disabled represents that mute commands are disabled, for example via a local privacy switch or other means.
The Mute field value shall not affect the Gain_Setting field value; for example, muting a server shall not change the Gain_Setting field value to the Gain_Setting_Minimum field value.
2.2.1.3. Gain_Mode field
The Gain_Mode field describes whether the server automatically sets the audio input’s gain. This field allows a server to expose control over the gain mode of an audio input. An example of selectable gain mode control is a microphone that can automatically adjust its gain through automatic gain control or allows the gain to be set manually.
The Gain_Mode field values are described in Table 2.2.
|
Gain_Mode Field |
Value |
|---|---|
|
Manual Only |
0 |
|
Automatic Only |
1 |
|
Manual |
2 |
|
Automatic |
3 |
The Gain_Mode field value represents the server’s gain adjustment functionality.
A value of Manual or Manual Only indicates that gain adjustments are made manually through changes to the Gain_Setting field. A value of Automatic or Automatic Only represents automatic gain adjustment where the Gain_Setting field is ignored.
When the value of the Gain_Mode field is either Automatic Only or Manual Only, the server does not support changes to the Gain_Mode field. When the value of the Gain_Mode field is either Automatic or Manual, the server supports switching between the Automatic and Manual values of the Gain_Mode field.
2.2.1.4. Change_Counter field
The server shall increment the Change_Counter field value by one upon every change to the Gain_Setting, Mute, and Gain_Mode field values. The Change_Counter field value is used in all Audio Input Control Point commands.
The server shall initialize the Change_Counter field to an arbitrary value. The value shall be in the range of 0 to 255, and an increment larger than 255 shall roll over to 0.
3. Service characteristics
This section defines the characteristic and descriptor requirements.
Requirements in this section are defined as “Mandatory” (M), “Optional” (O), “Excluded” (X), and “Conditional” (C.n). Conditional statements (C.n) are listed directly below the table in which they appear.
|
Characteristic Name |
Requirement |
Mandatory Properties |
Optional Properties |
Security Permissions |
|---|---|---|---|---|
|
Audio Input State |
M |
Read, Notify |
None |
Encryption Required |
|
Gain Setting Properties |
M |
Read |
None |
Encryption Required |
|
Audio Input Type |
M |
Read |
None |
Encryption Required |
|
Audio Input Status |
M |
Read, Notify |
None |
Encryption Required |
|
Audio Input Control Point |
M |
Write |
None |
Encryption Required |
|
Audio Input Description |
M |
Read, Notify [C.1] |
Write Without Response, Notify |
Encryption Required |
C.1: Mandatory to support Notify if Write Without Response is supported, otherwise Optional.
Properties not listed as Mandatory or Optional in Table 3.1 are Excluded.
3.1. Audio Input State
The Audio Input State characteristic shall be used to reflect the state of the audio gain and mute of the input to which this service applies. The value of the Audio Input State characteristic shall use the format described in Table 3.2.
|
Field Name |
Size (Octets) |
Format |
|---|---|---|
|
Gain_Setting |
1 |
int8 |
|
Mute |
1 |
uint8 |
|
Gain_Mode |
1 |
uint8 |
|
Change_Counter |
1 |
uint8 |
3.1.1. Gain_Setting field
The Gain_Setting field shall be set to a value that reflects the current gain of the audio input signal to which this service applies. A single increment or decrement of the Gain_Setting field value is equal to the Gain_Setting_Units field value, as described in Section 2.2.1.1.
The Gain_Setting field is applied as described in Section 2.2.1.1.
3.1.2. Mute field
The Mute field shall be set to a value that reflects the current mute state of the audio to which this service applies.
The Mute field is applied as described in Section 2.2.1.2.
3.1.3. Gain_Mode field
The Gain_Mode field shall be set to a value that reflects whether gain modes are manual or automatic. If the Gain_Mode field value is Manual Only, the server allows only manual gain. If the Gain_Mode field is Automatic Only, the server allows only automatic gain. For all other Gain_Mode field values, the server allows switchable automatic/manual gain.
The Gain_Mode field is applied as described in Section 2.2.1.3.
3.1.4. Change_Counter field
The server shall initialize the Change_Counter field to an arbitrary value. The Change_Counter field value shall be incremented by 1 when the Gain_Setting, Mute, or Gain_Mode field value changes and shall not be changed otherwise. When the Change_Counter field value reaches 255, its next increment shall be 0.
3.1.5. Audio Input State behavior
The Audio Input State characteristic value may be read by the client. When the Audio Input State value changes, the server shall notify clients that have enabled the Client Characteristic Configuration Descriptor for notifications of the new value. The Audio Input State characteristic value shall be the same for all clients.
3.2. Gain Setting Properties
The Gain Setting Properties characteristic shall be set to a value that reflects the limits and units of the Gain_Setting field value. The value of the Gain Setting Properties characteristic shall use the format described in Table 3.3.
|
Field Name |
Size (Octets) |
Format |
|---|---|---|
|
Gain_Setting_Units |
1 |
uint8 |
|
Gain_Setting_Minimum |
1 |
int8 |
|
Gain_Setting_Maximum |
1 |
int8 |
3.2.1. Gain_Setting_Units field
The Gain_Setting_Units characteristic shall be set to a value that reflects the size of a single increment or decrement of the Gain Setting value in 0.1 decibel units.
The Gain_Setting_Units is applied as described in Section 2.2.1.1.
3.2.2. Gain_Setting_Minimum field
The Gain_Setting_Minimum field shall be set to a value that reflects the minimum allowable value of the Gain_Setting field value of this service, including the value of the operand used in Section 3.5.2.1.
The Gain_Setting_Minimum field value shall be less than or equal to the Gain_Setting_Maximum field value.
3.2.3. Gain_Setting_Maximum field
The Gain_Setting_Maximum field shall be set to a value that reflects the maximum allowable value of the Gain_Setting field value of this service, including the value of the operand used in Section 3.5.2.1.
The Gain_Setting_Maximum field value shall be greater than or equal to the Gain_Setting_Minimum field value.
3.2.4. Gain Setting Properties behavior
The Gain Setting Properties characteristic value may be read by the client. The server shall not change this value while connected to a client.
3.3. Audio Input Type
The Audio Input Type characteristic shall be set to a value that reflects the source of audio for the audio input described by this Audio Input Control Service. Examples of Audio Input Type values are Local, Isochronous Stream, Analog Connector, and Digital Connector. The Characteristic User Description may optionally further describe the Audio Input Type with values such as Microphone, HDMI, etc. The Audio Input Type characteristic value is defined in the Bluetooth SIG Assigned Numbers [3].
3.3.1. Audio Input Type behavior
The Audio Input Type characteristic value may be read by the client. The server shall not change this value while connected to a client.
3.4. Audio Input Status
The Audio Input Status characteristic shall be set to a value that reflects the current state of the audio input. The Audio Input Status is a one-octet value that shall have one of the non-RFU values defined in Table 3.4.
|
Name |
Value |
|---|---|
|
Inactive |
0x00 |
|
Active |
0x01 |
|
RFU |
0x02–0xFF |
3.4.1. Audio Input Status behavior
The Audio Input Status characteristic value may be read by the client. When the Audio Input Status value changes, the server shall notify clients that have enabled the Client Characteristic Configuration Descriptor for notifications of the new value.
3.5. Audio Input Control Point
The Audio Input Control Point characteristic is used to request a specific procedure to be executed by the server when a value is written to it.
3.5.1. Audio Input Control Point procedure requirements
Table 3.5 lists the requirements for the Audio Input Control Point procedures for the request opcodes and operands in the context of this Audio Input Control Service.
|
Opcode Value |
Opcode |
Procedure Section |
Opcode Requirement |
Operand |
|---|---|---|---|---|
|
0x01 |
Set Gain Setting |
M |
Change_Counter, Gain_Setting |
|
|
0x02 |
Unmute |
M |
Change_Counter |
|
|
0x03 |
Mute |
M |
Change_Counter |
|
|
0x04 |
Set Manual Gain Mode |
M |
Change_Counter |
|
|
0x05 |
Set Automatic Gain Mode |
M |
Change_Counter |
3.5.2. Audio Input Control Point behavior
The Audio Input Control Point characteristic value may be written by the client.
If a client writes a Change_Counter operand that does not equal the Change_Counter field of the Audio Input State characteristic value, then the server shall return an ATT Error Response with the error code Invalid Change Counter defined in Table 1.2.
If a client writes an opcode that is not supported or not defined in Table 3.5, then the server shall return an ATT Error Response with the error code Opcode Not Supported defined in Table 1.2.
3.5.2.1. Set Gain Setting procedure
If the Set Gain Setting opcode is written to the Audio Input Control Point and the Change_Counter operand matches the Change_Counter field of the Audio Input State characteristic value, then the server shall set the Gain_Setting field value to the Gain_Setting operand value if the Gain_Mode field is Manual or Manual Only. If the Set Gain Setting procedure causes the Gain_Setting field value to change, the server shall notify clients of the new Audio Input State value, as described in Section 3.1.5.
If the Gain_Setting operand value is less than the Gain_Setting_Minimum field value or greater than the Gain_Setting_Maximum field value, then the server shall return an ATT Error Response with the error code Value Out of Range defined in Table 1.2.
The Set Gain Setting procedure shall not affect the Mute field value.
The Audio Input Control Point characteristic value used for the Set Gain Setting Procedure shall be formatted as listed in Table 3.6.
|
Parameter |
Size (Octets) |
Value |
|---|---|---|
|
Opcode |
1 |
0x01 = Set Gain Setting Opcode |
|
Change_Counter |
1 |
0x00–0xFF |
|
Gain_Setting |
1 |
-128 to 127 |
3.5.2.2. Unmute procedure
If the Unmute opcode is written to the Audio Input Control Point, the Change_Counter operand matches the Change_Counter field of the Audio Input State characteristic value, and the Mute field value is not Disabled, then the server shall set the Mute field value to Not Muted.
If the Mute field value is Disabled, the server shall return an ATT Error Response with the error code Mute Disabled defined in Table 1.2. Only a local change on the server may transition the value from Disabled to another value.
If the Unmute procedure causes the Mute field value to change, the server shall increment the Change_Counter and notify clients of the new Audio Input State characteristic value, as described in Section 3.1.5.
The Audio Input Control Point characteristic value used for the Unmute Procedure shall be formatted as listed in Table 3.7.
|
Parameter |
Size (Octets) |
Value |
|---|---|---|
|
Opcode |
1 |
0x02 = Unmute Opcode |
|
Change_Counter |
1 |
0x00-0xFF |
3.5.2.3. Mute procedure
If the Mute opcode is written to the Audio Input Control Point, the Change_Counter operand matches the Change_Counter field of the Audio Input State characteristic value, and the Mute field value is not Disabled, the server shall set the Mute field value to Muted.
If the Mute field value is Disabled, the server shall return an ATT Error Response with the error code Mute Disabled defined in Table 1.2. Only a local change on the server may transition the value from Disabled to another value.
If the Mute procedure causes the Mute field value to change, the server shall increment the Change_Counter field value and notify clients of the new Audio Input State characteristic value, as described in Section 3.1.5.
The Audio Input Control Point characteristic value used for the Mute Procedure shall be formatted as listed in Table 3.8.
|
Parameter |
Size (Octets) |
Value |
|---|---|---|
|
Opcode |
1 |
0x03 = Mute Opcode |
|
Change_Counter |
1 |
0x00-0xFF |
3.5.2.4. Set Manual Gain Mode procedure
If the Set Manual Gain Mode opcode is written to the Audio Input Control Point, and the Change_Counter operand matches the Change_Counter field of the Audio Input State characteristic value, the server shall set the Gain_Mode field value to Manual if the Gain_Mode field value is Automatic.
If the Gain_Mode field value is Automatic Only or Manual Only, the server shall return an ATT Error Response to with the error code Gain Mode Change Not Allowed defined in Table 1.2.
If the Set Manual Gain Mode procedure results in a change to the Gain_Mode field value, the server shall increment the Change_Counter field value and notify clients of the new Audio Input State characteristic value, as described in Section 3.1.5.
The Audio Input Control Point characteristic value used for the Set Manual Gain Mode Procedure shall be formatted as listed in Table 3.9.
|
Parameter |
Size (Octets) |
Value |
|---|---|---|
|
Opcode |
1 |
0x04 = Set Manual Gain Mode Opcode |
|
Change_Counter |
1 |
0x00-0xFF |
3.5.2.5. Set Automatic Gain Mode procedure
If the Set Automatic Gain Mode opcode is written to the Audio Input Control Point, and the Change_Counter operand matches the Change_Counter field of the Audio Input State characteristic value, the server shall set the Gain_Mode field value to Automatic if the Gain_Mode field value is Manual.
If the Gain_Mode field value is Automatic Only or Manual Only, the server shall return an ATT Error Response with the error code Gain Mode Change Not Allowed defined in Table 1.2.
If the Set Automatic Gain Mode procedure results in a change to the Gain_Mode field value, the server shall increment the Change_Counter field value and notify clients of the new Audio Input State characteristic value, as described in Section 3.1.5.
The Audio Input Control Point characteristic value used for the Set Automatic Gain Mode Procedure shall be formatted as listed in Table 3.10.
|
Parameter |
Size (Octets) |
Value |
|---|---|---|
|
Opcode |
1 |
0x04 = Set Automatic Gain Mode Opcode |
|
Change_Counter |
1 |
0x00-0xFF |
3.6. Audio Input Description
The Audio Input Description characteristic shall be set to a description of the audio input that the Audio Input Control Service instance describes. For example, if a device instantiated a service for both “Bluetooth” and “Line In” audio inputs, then the Audio Input Description value would be set to “Bluetooth” on one service and “Line In” on the other service. If multiple Bluetooth audio inputs are represented, the server may set the Audio Input Description to the remote source’s name, a string representing the content type, the content control server name, etc. The characteristic value is a UTF-8 string of zero or more characters.
3.6.1. Audio Input Description behavior
The Audio Input Description characteristic value may be read and optionally written by the client. When the Audio Input Description value changes, the server shall notify clients that have enabled the Client Characteristic Configuration Descriptor for notifications of the new value if the server supports notifications of this characteristic.
4. SDP interoperability
If the Audio Input Control Service is exposed over Basic Rate/Enhanced Data Rate (BR/EDR), then the service shall have the Service Discovery Protocol (SDP) record defined in Table 4.1.
Requirements in this section are defined as “Mandatory” (M), “Optional” (O), “Excluded” (X), and “Conditional” (C.n). Conditional statements (C.n) are listed directly below the table in which they appear.
|
Item |
Definition |
Type |
Value |
Status |
|---|---|---|---|---|
|
Service Class ID List |
– |
– |
– |
M |
|
Service Class #0 |
– |
UUID |
«Audio Input Control Service» |
M |
|
Protocol Descriptor List |
– |
Data Element Sequence |
– |
M |
|
Protocol #0 |
– |
UUID |
«L2CAP» |
M |
|
Parameter #0 for Protocol #0 |
Protocol/Service Multiplexer (PSM) |
uint16 |
PSM = ATT |
M |
|
Protocol #1 |
– |
UUID |
«ATT» |
M |
|
Additional Protocol Descriptor List |
– |
Data Element Sequence |
– |
C.1 |
|
Protocol Descriptor List |
– |
Data Element Sequence |
– |
C.1 |
|
Protocol #0 |
– |
UUID |
«L2CAP» |
C.1 |
|
Parameter #0 for Protocol #0 |
PSM |
uint16 |
PSM = EATT |
C.1 |
|
Protocol #1 |
– |
UUID |
«ATT» |
C.1 |
|
BrowseGroupList |
– |
– |
PublicBrowseRoot Other browse UUIDs may also be included in the list. |
M |
C.1: Mandatory if Enhanced Attribute Protocol (EATT), introduced in Volume 3, Part F, Section 3.2.11 in [2], is supported, otherwise Excluded.
5. Acronyms and abbreviations
|
Acronym/Abbreviation |
Meaning |
|---|---|
|
ATT |
Attribute Protocol |
|
BR/EDR |
Basic Rate/Enhanced Data Rate |
|
EATT |
Enhanced Attribute Protocol |
|
GATT |
Generic Attribute Profile |
|
L2CAP |
Logical Link Control and Adaptation Protocol |
|
LSO |
least significant octet |
|
PDU |
Protocol Data Unit |
|
PSM |
Protocol/Service Multiplexer |
|
RFU |
Reserved for Future Use |
|
SDP |
Service Discovery Protocol |
|
UUID |
universally unique identifier |
6. References
[1] Bluetooth Core Specification, Version 4.0 or later
[2] Bluetooth Core Specification, Version 5.2
[3] Bluetooth SIG Assigned Numbers, https://www.bluetooth.com/specifications/assigned-numbers