Перечислитель bluetooth le майкрософт что это
Перейти к содержимому

Перечислитель bluetooth le майкрософт что это

  • автор:

Общие сведения о Bluetooth Low Energy (LE)

Bluetooth LE представляет новый физический уровень, который использует то же пространство частоты, что и базовая скорость Bluetooth. Профили, разработанные на основе этой технологии, упорядочены в универсальный профиль атрибутов (GATT).

Каждый профиль определяет использование одной или нескольких служб для создания варианта использования или сценария. Соответствующие реализации служб создаются на основе характеристик, упорядоченных в соответствии с установленной схемой, определенной на веб-сайте разработчика Bluetooth Special Interest Group.

На следующей схеме показан способ структурирования объектов в типичной службе GATT.

Схема, показывающая структуру объектов в типичной службе Bluetooth LE GATT.

Когда устройство Bluetooth LE связано с компьютером Windows, устройство становится частью системы. Windows предоставляет объекты устройства, представляющие как устройство, так и основные службы, о чем сообщает устройство.

Схема, иллюстрирующая структуру объекта устройства в реализации Windows Bluetooth LE.

Каждое устройство и его основные службы представлены как объекты устройств в Windows, и эти объекты устройств можно запрашивать и управлять ими с помощью таких функций установки устройств , как SetupDiEnumDeviceInfo и SetupDiGetDeviceProperty.

В дополнение к стандартным функциям драйвера профиля Bluetoothфункции Bluetooth LE предоставляют функции для разработки клиентских приложений Bluetooth GATT.

Эти функции позволяют выполнять перечисление служб и их объектов (включая службы, характеристики и их дескрипторы), а также возможности чтения и записи.

Обратная связь

Были ли сведения на этой странице полезными?

Перечислитель Bluetooth LE (Майкрософт)

Доброго времени суток господа)
столкнулся вот с такой вот проблемой, никогда не пользовался блютусом на пк.
Приобрел колоночку JBL FLIP3 и хотелось бы попробовать ее подключить до ноута через блютуз когда нахожусь не в домашних условиях.
Спасибо за внимания и отзывчивость)

Голосование за лучший ответ

Посмотрите в сетевых адаптерах должно показывать ваш блютуз адаптер, и скачайте здесь драйвер. http://www.mediatek.com/en/downloads1/downloads/ Мне помогло.

. СКРИПАЧ. Ученик (123) 8 лет назад

не понятно, чет ничего нет там связано с блютусом.
никогда не было проблем с драйверами. а тут этот ноут выпендривается.

Звук Bluetooth с низким энергопотреблением (LE)

В этой статье представлен обзор bluetooth LE Audio, появившиеся в Windows 11 версии 22H2 (KB5026446).

Введение

Bluetooth LE Audio обеспечивает потоковую передачу одноадресной или широковещательной передачи звука на устройства Bluetooth LE через изохронный транспорт. Начиная с версии 5.3 спецификации ядра Bluetooth, не существует стандартного определенного интерфейса хост-контроллера (HCI) для хост-платформ для отправки и получения изохронных данных на контроллер Bluetooth и из нее. В этом документе определяется звуковой путь поставщика Bluetooth Для Windows (VSAP), позволяющий платформам использовать решения конкретных поставщиков для включения потоковой передачи Bluetooth LE Audio. Программный интерфейс VSAP использует расширения аудиоклассов Windows (ACX) и дополнительные свойства интерфейса, определенные в этом документе.

Терминология и предварительные требования

В дополнение к терминам, определенным в этой таблице, этот документ также ссылается на термины, определенные расширениями класса звука Windows.

Термин Определение
Звук le Сокращение от Bluetooth LE Audio
Классический звук Потоковая передача звука по Bluetooth с использованием профиля громкой связи (HFP) и расширенного профиля распространения звука (A2DP)
Звуковое устройство Одно удаленное устройство Bluetooth LE Audio или набор устройств Bluetooth LE Audio, которые вместе составляют одну конечную точку звука с точки зрения Windows.
BAP Базовый аудиопрофиль определяет, как устройства могут распространять и потреблять звук с помощью связи Bluetooth с низким энергопотреблением (LE).
TMAP Профиль телефонии и аудиофайла мультимедиа определяет конфигурации взаимодействия звуковых служб и профилей нижнего уровня.
ASCS Служба управления аудиопотоком определяет стандартный способ настройки и установки одноадресных аудиопотоков для устройств Bluetooth LE Audio.
PACS Служба возможностей опубликованного звука определяет стандартный способ для устройств Bluetooth LE Audio сообщать о поддерживаемых возможностях аудиокодека.
CIS Транспорт Connected Isochronous Streams используется для отправки и получения одноадресных звуковых данных между устройствами Bluetooth LE.
BIS Транспорт широковещательного изохронного потока используется для передачи аудиоданных без подключения.
ACX Сокращение от расширения класса аудио, которое является моделью драйвера, необходимой для всех звуковых драйверов для поддержки Bluetooth LE Audio в Windows.
Каналы потоковой передачи Один или несколько объектов ACXCIRCUIT , созданных стеком драйвера аудио для конкретного поставщика для пути потоковой передачи.
Профилирование канала Объект ACXCIRCUIT , созданный реализацией профиля Bluetooth LE Audio в Windows. Этот ACXCIRCUIT выступает в качестве головного канала, как определено в спецификации ACX, и не является потоком потоковой передачи.

В этом документе предполагается знание ранее определенных терминов и следующих команд HCI, определенных в спецификации Bluetooth Core 5.3:

  • HCI_Read_Local_Supported_Codecs (версия 2)
  • HCI_Read_Local_Supported_Codec_Capabilities
  • HCI_LE_Set_CIG_Parameters
  • HCI_LE_Create_CIS
  • HCI_Configure_Data_Path
  • HCI_LE_Setup_ISO_Data_Path
  • HCI_LE_Remove_ISO_Data_Path
  • HCI_LE_Remove_CIG

Bluetooth LE Audio VSAP требует, чтобы аудиодрайверы использовали платформу ACX. Внедрение ACX для Bluetooth LE Audio обеспечивает ряд преимуществ, таких как:

  • Поддерживает предпочтительную модель аудиодрайвора для Windows в будущем.
  • Использует встроенную поддержку ACX для аудиовыходов с несколькими стеками, не требуя выделенного DDI между драйверами.
  • Не требует аудиодрайверов IHV для передачи запросов из аудиосистемы в стек Bluetooth. Вместо этого ACX может отправлять запросы непосредственно в стек Bluetooth через канал профиля.

Архитектура

Определения

Следующие компоненты участвуют в различных вариантах архитектуры VSAP.

Платформа Windows ACX

Этот компонент обеспечивает поддержку конечной точки многоуровневый стек аудио. Для Bluetooth LE Audio программными компонентами, составляющими конечную точку звука, являются стек драйвера звука конкретного поставщика и профиль Windows Bluetooth LE Audio.

Стек аудиодрайвов для конкретного поставщика

Этот компонент конкретного поставщика отвечает за отправку и получение данных Bluetooth LE Audio на контроллер Bluetooth и из нее через определенный поставщиком звуковой интерфейс. Он должен состоять как минимум из драйвера потоковой передачи ACX для управления входящими и исходящими звуковыми данными. Если они необходимы для аудиоконечной точки ACX с несколькими каналами, можно включить дополнительные драйверы ACX. В этом документе этот компонент также называется драйвером потоковой передачи ACX IHV.

Профиль Windows Bluetooth LE Audio

Этот компонент содержит реализацию базового аудиопрофиля (BAP), профиля управления громкости и профиля управления микрофоном. Он отвечает за создание головного ACXCIRCUIT для каждого устройства Bluetooth LE Audio или набора устройств, сопряженных с Windows, сообщает форматы звука, сообщаемые удаленным устройством и контроллером Bluetooth, а также управляет состоянием изохронных каналов и групп.

Основной стек Windows Bluetooth

Этот компонент предоставляет интерфейс, позволяющий профилю Windows Bluetooth LE Audio запрашивать поддерживаемые возможности кодека из локального контроллера Bluetooth и управлять состоянием изохронных каналов и групп.

Кодек LC3

Этот подкомпонент отвечает за перевод между сжатым звуком LC3 и звуком PCM. Она должна поддерживать возможности кодирования и декодирования и может быть реализована либо в программном обеспечении в составе стека драйвера звука для конкретного поставщика (VSAP), либо в оборудовании в составе звукового DSP или Bluetooth-контроллера. На схеме упоминается LC3 по имени, так как это стандартный кодек, поддерживаемый Bluetooth SIG. Однако будущие кодеки и кодеки конкретных поставщиков, поддерживаемые Windows, также могут быть включены в архитектуру аналогичным образом.

Варианты архитектуры

Архитектура VSAP Bluetooth LE Audio поддерживает различные варианты потоковой передачи.

  1. Потоковая передача звука с поддержкой bluetooth LE без разгрузки звука
  2. Потоковая передача звука с помощью боковой полосы Bluetooth LE с разгрузкой звука
  3. Потоковая передача аудио по каналу Bluetooth LE для конкретного поставщика

На следующих схемах затеняемые компоненты предоставляются IHV, а не затеняемые компоненты предоставляются операционной системой.

Архитектура bluetooth LE Audio с боковой полосой без разгрузки звука

Архитектура бокового канала использует определенный поставщиком звуковой интерфейс, чтобы позволить стеку аудиодрайвов отправлять и получать звуковые данные на контроллер Bluetooth. Этот путь к данным отделен от пути данных HCI, используемого для других данных Bluetooth, таких как сигнальные сообщения между клиентом одноадресной рассылки и удаленным сервером одноадресной рассылки. На следующей схеме моделируется архитектура боковой полосы, в которой кодек LC3 размещается в контроллере Bluetooth. Кроме того, кодек LC3 можно разместить в стеке драйвера аудио для конкретного поставщика для кодирования и декодирования программного обеспечения. В этом случае звук, отправляемый на контроллер Bluetooth, будет отформатирован как аудиокадры LC3, а не звук PCM.

На следующей схеме показана архитектура боковой полосы Bluetooth LE Audio с кодеком LC3 в контроллере Bluetooth.

Схема архитектуры бокового bluetooth LE Audio с кодеком LC3, расположенным в контроллере Bluetooth.

На следующей схеме показана архитектура bluetooth LE Audio с кодеком LC3 в стеке аудиодрайвов.

Схема боковой архитектуры Bluetooth LE Audio с кодеком LC3, расположенным в стеке аудиодрайвов.

Архитектура аудиосвязи Bluetooth LE с разгрузкой звука

Архитектура боковой полосы с разгрузкой звука включает аппаратный компонент DSP для аудио, предоставляющий решение потоковой передачи Bluetooth LE Audio с преимуществами энергосбережения. На следующих схемах показана возможная архитектура с кодеком LC3 в контроллере Bluetooth и кодеком в аудио DSP.

На следующей схеме показана архитектура bluetooth LE Audio с разгрузкой звука с кодеком LC3 в контроллере Bluetooth.

Схема боковой bluetooth LE Audio с архитектурой разгрузки звука с кодеком LC3 в контроллере Bluetooth.

На следующей схеме показана архитектура боковой полосы Bluetooth LE Audio с разгрузкой звука с кодеком LC3 в звуковом DSP.

Схема боковой полосы Bluetooth LE Audio с архитектурой разгрузки звука, показывающая кодек LC3 в аудио DSP.

Архитектура аудиосвязи Bluetooth LE Audio для конкретного поставщика

Архитектура vsap inband позволяет пользовательскому конвейеру отправлять и получать данные Bluetooth LE Audio из стека драйвера звука конкретного поставщика в HCI контроллера Bluetooth. Эта архитектура включает новый компонент — компонент слияния ISO IHV. Этот компонент отвечает за управление потоком для данных ISO. Он также должен совместно использовать управление потоком команд HCI со стеком Windows Bluetooth Core, если ему нужно отправить какие-либо команды HCI.

На следующей схеме показана архитектура bluetooth LE Audio для конкретного поставщика.

Схема архитектуры bluetooth LE Audio для конкретного поставщика.

Подробный дизайн

Требования к формату звука

Продолжительность звукового кадра

Профили Bluetooth LE Audio позволяют реализовать поддержку потоковой передачи звука с длительностью звуковых кадров 7,5 или 10 миллисекундах. Windows требует, чтобы кодеки, предоставляемые IHV, поддерживали обе продолжительности кадров для обеспечения взаимодействия с периферийными устройствами Bluetooth LE Audio и качественного сосуществования с другими устройствами Bluetooth LE, подключенными к системе.

Определения режима обработки сигналов

Bluetooth LE Audio поддерживает широкий спектр форматов потоковой передачи для поддержки различных пользовательских сценариев. Спецификации BAP и TMAP определяют обязательные поддерживаемые форматы для сертификации. Windows применяет режимы обработки звуковых сигналов , чтобы сопоставить формат, используемый с сценарием, выполняемым системой. Аудиодрайверы, поддерживающие Bluetooth LE Audio, должны указывать на поддержку режимов и форматов обработки сигналов, приведенных в следующей таблице. Кроме того, Bluetooth LE Audio не поддерживает режим обработки необработанных сигналов, поэтому звуковые драйверы не должны объявлять поддерживаемые форматы для этого режима.

Режимы обработки звуковых сигналов отрисовки потока

Bluetooth LE Audio требует, чтобы форматы звука отрисовки были объявлены для следующих режимов обработки сигнала:

  • По умолчанию (AUDIO_SIGNALPROCESSINGMODE_DEFAULT)
    • Этот режим используется для однонаправленных сценариев отрисовки, таких как воспроизведение музыки, уведомления и звук видеоигры.
    • Этот режим используется для двунаправленных сценариев, таких как голосовые звонки.

    В следующих таблицах приведены списки форматов для каждого варианта использования и режима обработки сигналов. Форматы звука упорядочены от наиболее предпочтительных к наименее предпочтительным.

    Системные звуки, воспроизведение музыки и звук видеоигр при подключении к стереоустройству или скоординированному набору устройств

    Режим обработки сигналов: по умолчанию

    Частота выборки Число каналов Битовая глубина Длительность кадра Скорость аудиоданных Идентификатор конфигурации кодека BAP (таблица 3.11 спецификации BAP)
    48 кГц 2 16 7,5 мс 96 кбит/с 48_3
    48 кГц 2 16 7,5 мс 80 кбит/с 48_1
    48 кГц 2 16 10 мс 96 кбит/с 48_4
    48 кГц 2 16 10 мс 80 кбит/с 48_2
    24 кГц 2 16 7,5 мс 48 кбит/с 24_1
    24 кГц 2 16 10 мс 48 кбит/с 24_2
    Системные звуки, воспроизведение музыки и звук в видеоиграх при подключении к одному члену скоординированного набора (один наушный наушников или слуховой аппарат)

    Режим обработки сигналов: по умолчанию

    Частота выборки Число каналов Битовая глубина Длительность кадра Скорость аудиоданных Идентификатор конфигурации кодека BAP (таблица 3.11 спецификации BAP)
    48 кГц 1 16 7,5 мс 96 кбит/с 48_3
    48 кГц 1 16 7,5 мс 80 кбит/с 48_1
    48 кГц 1 16 10 мс 96 кбит/с 48_4
    48 кГц 1 16 10 мс 80 кбит/с 48_2
    24 кГц 1 16 7,5 мс 48 Кбит/с 24_1
    24 кГц 1 16 10 мс 48 Кбит/с 24_2
    16 кГц 1 16 7,5 мс 32 Кбит/с 16_1
    16 кГц 1 16 10 мс 32 Кбит/с 16_2
    Отрисовка голосовых записей, voIP-вызовов или аудио в видеоиграх с помощью голосового чата

    Режим обработки сигнала: обмен данными

    Частота выборки Число каналов Битовая глубина Длительность кадра Скорость аудиоданных Идентификатор конфигурации кодека BAP (таблица 3.11 спецификации BAP)
    32 кГц 1 16 7,5 мс 64 Кбит/с 32_1
    32 кГц 1 16 10 мс 64 Кбит/с 32_2
    24 кГц 1 16 7,5 мс 48 Кбит/с 24_1
    24 кГц 1 16 10 мс 48 Кбит/с 24_2
    16 кГц 1 16 7,5 мс 32 Кбит/с 16_1
    16 кГц 1 16 10 мс 32 Кбит/с 16_2
    Режимы обработки аудиосигнала записи потока

    Bluetooth LE Audio требует объявления форматов аудиозахвата для режима обработки сигнала по умолчанию (AUDIO_SIGNALPROCESSINGMODE_DEFAULT). Список поддерживаемых форматов записи приведен в следующей таблице.

    Форматы звука упорядочены от наиболее предпочтительных к наименее предпочтительным.

    Запись голосовых записей, voIP-вызовов или аудио в видеоиграх с помощью голосового чата

    Режим обработки сигнала: по умолчанию

    Частота выборки Число каналов Битовая глубина Длительность кадра Скорость аудиоданных Идентификатор конфигурации кодека BAP (таблица 3.11 спецификации BAP)
    32 кГц 1 16 7,5 мс 64 Кбит/с 32_1
    32 кГц 1 16 10 мс 64 Кбит/с 32_2
    24 кГц 1 16 7,5 мс 48 Кбит/с 24_1
    24 кГц 1 16 10 мс 48 Кбит/с 24_2
    16 кГц 1 16 7,5 мс 32 Кбит/с 16_1
    16 кГц 1 16 10 мс 32 Кбит/с 16_2
    Определенные конфигурации и топологии потоков
    Конфигурации только для отрисовки
    Базовая конфигурация профиля аудио 1

    Следующая конфигурация звука определена в таблице 4.1 спецификации Bluetooth BAP.

    Схема, иллюстрирующая базовую конфигурацию аудиопрофиля 1.

    Компьютер подключен к одному звуковому устройству, поддерживающем монопотоки. Одно устройство может быть автономным устройством или одним подключенным членом скоординированного набора.

    Примеры вариантов использования Параметры звука Windows Параметры bluetooth-контроллера
    Воспроизведение мультимедиа Отрисовка:
    Режим обработки сигнала: по умолчанию
    Число каналов: 1
    Запись: нет
    Количество CIS: 1
    Число CIG: 1
    Параметры качества обслуживания BAP: высокая надежность
    Голосовой вызов без микрофона на звуковом устройстве Отрисовка:
    Режим обработки сигнала: обмен данными
    Число каналов: 1
    Запись: нет
    Количество CIS: 1
    Число CIG: 1
    Параметры качества обслуживания BAP: низкая задержка
    Воспроизведение видеоигр Отрисовка:
    Режим обработки сигнала: по умолчанию
    Число каналов: 1
    Запись: нет
    Количество CIS: 1
    Число CIG: 1
    Параметры качества обслуживания BAP: низкая задержка
    Базовая конфигурация профиля звука 4

    Следующая конфигурация звука определена в таблице 4.1 спецификации Bluetooth BAP.

    Схема, иллюстрирующая базовую конфигурацию аудиопрофиля 4.

    Компьютер подключен к одному звуковому устройству, поддерживающем стереопотоки. Звуковое устройство способно обрабатывать два аудиоканала на одном cis.

    Примеры вариантов использования Параметры звука Windows Параметры bluetooth-контроллера
    Воспроизведение мультимедиа Отрисовка: режим обработки сигнала: по умолчанию
    Число каналов: 2
    Запись: нет
    Количество CIS: 1
    Число CIG: 1
    Параметры качества обслуживания BAP: распределение аудиоканалов с высокой надежностью: спереди слева и спереди справа
    Воспроизведение видеоигр Режим обработки сигнала: по умолчанию
    Число каналов: 2
    Запись: нет
    Количество CIS: 1
    Число CIG: 1
    Параметры качества обслуживания BAP: низкая задержка
    Выделение аудиоканала: спереди слева и спереди справа
    Базовая конфигурация профиля аудио 6(i)

    Следующая конфигурация звука определена в таблице 4.1 спецификации Bluetooth BAP.

    Схема, иллюстрирующая базовую конфигурацию аудиопрофиля 6 I.

    Компьютер подключен к одному звуковому устройству, поддерживающем стереопотоки. Звуковое устройство может обрабатывать только один звуковой канал на каждом из двух CIS

    Примеры вариантов использования Параметры звука Windows Параметры bluetooth-контроллера
    Воспроизведение мультимедиа Режим обработки сигнала: по умолчанию
    Число каналов: 2
    Запись: нет
    Количество CIS: 2
    Число CIG: 1
    Параметры качества обслуживания BAP: высокая надежность
    Голосовой вызов без микрофона на звуковом устройстве Режим обработки сигнала: обмен данными
    Число каналов: 1
    Запись: нет
    Количество CIS: 2
    Число CIG: 1
    Параметры качества обслуживания BAP: низкая задержка
    Выделение аудиоканала: спереди слева или спереди справа
    Воспроизведение видеоигр Режим обработки сигнала: по умолчанию
    Число каналов: 2
    Запись: нет
    Количество CIS: 2
    Число CIG: 1
    Параметры качества обслуживания BAP: низкая задержка
    Выделение аудиоканала: спереди слева и спереди справа
    Базовая конфигурация аудиопрофиля 6(ii)

    Следующая конфигурация звука определена в таблице 4.1 спецификации Bluetooth BAP.

    Схема, иллюстрирующая базовую конфигурацию аудиопрофиля 6 II.

    Компьютер подключен к согласованному набору звуковых устройств. Набор способен обрабатывать два канала звука, каждый из которых обрабатывает один канал.

    Примеры вариантов использования Параметры звука Windows Параметры bluetooth-контроллера
    Воспроизведение мультимедиа Режим обработки сигнала: по умолчанию
    Число каналов: 2
    Запись: нет
    Количество CIS: 2
    Число CIG: 1
    Параметры качества обслуживания BAP: высокая надежность
    Голосовой вызов без микрофона на обоих устройствах Режим обработки сигнала: обмен данными
    Число каналов: 1
    Запись: нет
    Количество CIS: 2
    Число CIG: 1
    Параметры качества обслуживания BAP: низкая задержка
    Воспроизведение видеоигр Режим обработки сигнала: по умолчанию
    Число каналов: 2
    Запись: нет
    Количество CIS: 2
    Число CIG: 1
    Параметры качества обслуживания BAP: низкая задержка
    Двунаправленные конфигурации

    Двунаправленные конфигурации используются, когда профиль Bluetooth LE Audio обнаруживает, что приложение намерено создать поток захвата и отрисовки на удаленном устройстве или наборе устройств. Так как приложения управляют потоками записи и отрисовки отдельно, аудиодрайверы IHV и bluetooth-контроллеры должны разрешать звуку передаваться по одному направлению двунаправленного CIS после его подготовки с помощью команд HCI Configure Data Path (Настройка пути к данным) и LE Setup ISO Data Path (Путь ISO).

    Базовая конфигурация аудиопрофиля 3

    Следующая конфигурация звука определена в таблице 4.1 спецификации Bluetooth BAP.

    Схема, иллюстрирующая базовую конфигурацию аудиопрофиля 3.

    Компьютер подключен к одному звуковому устройству с двунаправленным монопотоком, установленным в одном CIS.

    Вариант использования Параметры звука Windows Параметры bluetooth-контроллера
    Голосовой звонок Визуализации:
    Режим обработки сигнала: обмен данными
    Число каналов: 1
    Захвата:
    Режим обработки сигнала: по умолчанию
    Число каналов: 1
    Количество CIS: 1
    Число CIG: 1
    Параметры качества обслуживания BAP: низкая задержка
    Воспроизведение видеоигр с помощью голосового чата Визуализации:
    Режим обработки сигнала: обмен данными
    Число каналов: 1
    Захвата:
    Режим обработки сигнала: по умолчанию
    Число каналов: 1
    Количество CIS: 1
    Число CIG: 1
    Параметры качества обслуживания BAP: низкая задержка
    Базовая конфигурация профиля аудио 8(i)

    Следующая конфигурация звука определена в таблице 4.1 спецификации Bluetooth BAP.

    Схема, иллюстрирующая базовую конфигурацию аудиопрофиля 8 I.

    Компьютер подключен к одному звуковому устройству, которое поддерживает стереопотоки отрисовки и потоки монозахвата. Устройство может обрабатывать один канал звука в одном cis для заданного направления.

    Вариант использования Параметры звука Windows Параметры bluetooth-контроллера
    Голосовой звонок Визуализации:
    Режим обработки сигнала: обмен данными
    Число каналов: 1
    Захвата:
    Режим обработки сигнала: по умолчанию
    Число каналов: 1
    Количество CIS: 2
    Число CIG: 1
    Параметры качества обслуживания BAP: низкая задержка
    Воспроизведение видеоигр с помощью голосового чата Визуализации:
    Режим обработки сигнала: обмен данными
    Число каналов: 2
    Захвата:
    Режим обработки сигнала: по умолчанию
    Число каналов: 1
    Количество CIS: 2
    Число CIG: 1
    Параметры качества обслуживания BAP: низкая задержка
    Базовая конфигурация профиля аудио 8(ii)

    Следующая конфигурация звука определена в таблице 4.1 спецификации Bluetooth BAP.

    Схема, иллюстрирующая базовую конфигурацию аудиопрофиля 8 II.

    Компьютер подключен к согласованному набору звуковых устройств. Каждый член набора получает один канал отрисовки звука. Один элемент набора имеет установленный поток захвата. Элемент набора с потоком захвата является первым элементом набора, который подключается к компьютеру, который также поддерживает потоки записи.

    Вариант использования Параметры звука Windows Параметры bluetooth-контроллера
    Голосовой звонок Визуализации:
    Режим обработки сигналов: обмен данными
    Число каналов: 1
    Захвата:
    Режим обработки сигналов: по умолчанию
    Число каналов: 1
    Cis Count: 2
    Число CIG: 1
    Параметры качества обслуживания BAP: низкая задержка
    Воспроизведение видеоигр с помощью голосового чата Визуализации:
    Режим обработки сигналов: обмен данными
    Число каналов: 2
    Захвата:
    Режим обработки сигналов: по умолчанию
    Число каналов: 1
    Cis Count: 2
    Число CIG: 1
    Параметры качества обслуживания BAP: низкая задержка
    Конфигурации только для записи
    Базовая конфигурация аудиопрофиля 2

    Следующая конфигурация звука определена в таблице 4.1 спецификации Bluetooth BAP.

    Схема, иллюстрирующая базовую конфигурацию звукового профиля 2.

    Компьютер подключен к одному звуковому устройству, которое поддерживает потоки монозахвата.

    Вариант использования Параметры звука Windows Параметры контроллера Bluetooth
    Голосовой звонок без динамиков на устройстве Отрисовка: нет
    Захвата:
    Режим обработки сигналов: по умолчанию
    Число каналов: 1
    Количество CIS: 1
    Число CIG: 1
    Параметры качества обслуживания BAP: низкая задержка
    Базовая конфигурация звукового профиля 9(i)

    Следующая конфигурация звука определена в таблице 4.1 спецификации Bluetooth BAP.

    Схема, иллюстрирующая базовую конфигурацию звукового профиля 9 I.

    Компьютер подключен к одному звуковому устройству, которое поддерживает отправку стереозвуковой передачи. Устройство может кодирование одного канала звука в одном CIS.

    Вариант использования Параметры звука Windows Параметры контроллера Bluetooth
    Захват микрофона в нескольких каналах Отрисовка: нет
    Захвата:
    Режим обработки сигналов: по умолчанию
    Число каналов: 1
    Cis Count: 2
    Число CIG: 1
    Параметры качества обслуживания BAP: низкая задержка
    Базовая конфигурация аудиопрофиля 9(ii)

    Компьютер подключен к одному звуковому устройству, которое поддерживает потоки монозахвата.

    Следующая конфигурация звука определена в таблице 4.1 спецификации Bluetooth BAP.

    Схема, показывающая базовую конфигурацию звукового профиля 9(ii) с компьютером, подключенным к одному звуковому устройству.

    Компьютер подключен к набору звуковых устройств. Каждый элемент набора отправляет на компьютер по одному каналу звука.

    Вариант использования Параметры звука Windows Параметры контроллера Bluetooth
    Захват микрофона в нескольких каналах Отрисовка: нет
    Захвата:
    Режим обработки сигналов: по умолчанию
    Число каналов: 1
    Cis Count: 2
    Число CIG: 1
    Параметры качества обслуживания BAP: низкая задержка

    Если удаленное устройство или набор устройств поддерживает двунаправленный звук, то конфигурации для потока только для записи совпадают с двунаправленными конфигурациями. Это позволяет переходить от сценариев только для отслеживания к двунаправленным сценариям без необходимости повторного создания потоков.

    Структуры данных

    Свойства интерфейса Bluetooth LE Audio, определенные корпорацией Майкрософт
    Свойства создания потока

    Следующие свойства совместно используются стеком аудиодрайверов конкретного поставщика и профилем Bluetooth LE Audio через DDIsACXOBJECTBAG для принятия решений о создании и настройке конечной точки потоковой передачи, как показано в сценарии создания потока.

    BluetoothLEAudio_CodecCapabilities

    Это свойство задается звуковым драйвером, чтобы указать поддержку возможностей потоковой передачи звука, поддерживаемых в звуковом драйвере или DSP аудио. Значение свойства задается с помощью DDI AcxObjectBagAddBlob , а формат значения совпадает с форматом записи PAC, как определено в спецификации PACS.

    Профиль Windows Bluetooth LE Audio считывает свойство , чтобы определить возможные конфигурации кодека и композиции потоков для использования.

    Поле Октет
    Число возможностей 0
    Кодек ИД[i] 1–6
    Длина конкретных возможностей кодека[i] 7
    Возможности кодека 8. n
    Длина метаданных (м) n + 1
    Метаданные n+2. М

    Значения полей определены в таблицах 3.2 и 3.4 спецификации PACS.

    Bluetooth_DatapathID

    Это свойство задается аудиодрайвером, чтобы указать идентификатор пути к данным, используемый в качестве параметра для команд HCI_LE_Setup_ISO_Data_Path и HCI_Configure_Data_Path. Значение свойства задается с помощью DDI AcxObjectBagAddUI8 .

    Профиль Bluetooth LE Audio считывает и использует это свойство в качестве параметра в командах HCI_Configure_Data_Path и HCI_LE_Setup_ISO_Data_Path. Этот идентификатор применяется ко всем изохронным потокам, созданным для ACXSTREAM , связанного с контейнером объектов.

    Поле Октет
    Идентификатор пути к данным 0

    Если свойство не задано аудиодрайвером, ос использует значение 1 в качестве параметра для команд HCI.

    Bluetooth_DatapathConfiguration

    Это свойство задается аудиодрайвом для предоставления определенных поставщиком конфигураций контроллеру Bluetooth с помощью команды HCI_Configure_Data_Path. Он не должен быть больше 255 байт, что является самой большой полезной нагрузкой, принимаемой контроллером Bluetooth для команды HCI. Значение свойства задается с помощью acxObjectBagAddBlob DDI. Эта конфигурация применяется ко всем идентификаторам пути к данным, заданным аудиодрайвером.

    BluetoothLEAudio_CodecConfiguration

    Это свойство должно быть задано профилем Bluetooth LE Audio с помощью DDI AcxObjectBagAddBlob после настройки конфигурации кодека с помощью звукового устройства. Структура значения:

    Поле Октет
    Число конфигураций 0
    Формат кодирования[i] 3
    Идентификатор компании[i] 1–2
    Идентификатор кодека для конкретного поставщика[i] 3–4
    Длина конкретной конфигурации кодека[i] 5
    Конкретная конфигурация кодека[i] 6. n

    Стек звукового драйвера конкретного поставщика должен считывать это свойство, если кодек LC3 находится в драйвере потоковой передачи ACX или звуковом DSP.

    Интерфейсы

    Идентификаторы привязки шаблонов конечной точки аудио

    Используется фабрикой цепи ACX звукового драйвера, чтобы узнать, когда создается цепь ACX для сопряженного устройства Bluetooth.

    Для создания каналов Bluetooth LE Audio используются следующие идентификаторы компонентов:

    // DEFINE_GUID(GUID_BLUETOOTH_LEAUDIO_RENDER_COMPONENT_ID, 0x5c52fdb5, 0x722a, 0x4ab7, 0xa3, 0x42, 0x70, 0x16, 0x3b, 0x7e, 0x9b, 0x5c); // DEFINE_GUID(GUID_BLUETOOTH_LEAUDIO_CAPTURE_COMPONENT_ID, 0x1dff2ee3, 0xae89, 0x441c, 0xbd, 0xe3, 0x24, 0xf8, 0x85, 0xc5, 0x5d, 0xf8); 
    Интерфейс поддержки Bluetooth LE Audio

    Используется стеком аудиодрайватера, чтобы указать, что он доступен для потоковой передачи Bluetooth LE Audio. Windows Bluetooth Audio service level watch для этого интерфейса и дождитесь его публикации, прежде чем включить поддержку Bluetooth LE Audio.

    Для публикации интерфейса поддержки Bluetooth LE Audio используются следующие идентификаторы интерфейсов:

    // DEFINE_GUID(GUID_BLUETOOTH_LEAUDIO_SUPPORT_INTERFACE, 0xba02fa1b, 0x0fd0, 0x4a0f, 0xa7, 0x48, 0x4f, 0xae, 0x2e, 0x2d, 0x2f, 0x67); 

    Последовательности

    Инициализация звукового драйвера

    Когда драйвер потоковой передачи IHV ACX загружается и определяет, что он поддерживает потоковую передачу Bluetooth LE Audio, он должен показать поддержку этой технологии, создав объект ACXFACTORYCIRCUIT и зарегистрировав для привязок шаблонов Bluetooth в ACX с помощью идентификаторов, определенных в идентификаторах привязки шаблонов конечных точек аудио.

    Блок-схема, иллюстрирующая последовательность инициализации драйвера Bluetooth LE Audio.

    Создание конечной точки
    1. Если устройство LE Audio связано с системой, профиль Bluetooth LE Audio:
      1. Считывает опубликованные звуковые возможности удаленного устройства.
      2. Обнаруживает поддерживаемые возможности контроллера, отправляя команды HCI_Read_Local_Support_Codecs [версия 2] и HCI_Read_Local_Supported_Codec_Capabilities.
      3. Создает ACXCIRCUIT с поддерживаемыми форматами, установленными на основе возможностей кодека, поддерживаемых контроллером Bluetooth и удаленным звуковым устройством. Если контроллер не поддерживает какие-либо кодеки, так как поддержка кодеков поддерживается в звуковом DSP или звуковом драйвере, то для поддерживаемых форматов устанавливаются форматы, поддерживаемые удаленным звуковым устройством.
      1. Создает объекты ACXCIRCUIT, ACXPIN, ACXOBJECTBAG и ACXSTREAMBRIDGE .
      2. Если кодек LC3 или конкретного поставщика размещен в аудиодрайвере или DSP, драйвер потоковой передачи IHV ACX задает свойство BluetoothLEAudio_CodecCapabilities в ACXOBJECTBAG.
      3. Драйвер потоковой передачи ACX IHV может задать Bluetooth_DatapathID или Bluetooth_DatapathConfiguration в ACXOBJECTBAG , если он известен в настоящее время.
      1. Извлекает булавку моста цепи профиля с помощью AcxTarget. API для получения форматов, поддерживаемых каналом профилей.
      2. Выполняет итерацию по списку объектов ACXDATAFORMAT, заданных каналом профиля. Если аудиокодек Bluetooth размещается в аудиодрайвеоре или DSP аудио, то звуковой драйвер IHV обновляет свои acXDATAFORMATформаты, поддерживаемые кодеком и каналом профиля. В противном случае все форматы копируются в закрепление узла драйвера потоковой передачи IHV ACX.
      3. Задает обновленный список форматов в закреплении моста, если для потоковой передачи разгрузки создается звуковой обработчик.

      Блок-схема, изображающая процесс создания конечной точки Bluetooth LE Audio.

      Создание потока
      1. Когда приложение запрашивает создание аудиопотока, ACX вызывает зарегистрированные обратные вызовы EvtCircuitCreateStream для каждого канала, начиная с драйвера потоковой передачи IHV ACX.
      2. При вызове обратного вызова EvtCircuitCreateStream драйвер потоковой передачи IHV ACX:
        1. Задает или обновляет свойства Bluetooth_DatapathId и Bluetooth_DataPathConfiguration в ACXOBJECTBAG , присоединенном к ACXSTREAMBRIDGE.
        2. Создает ACXSTREAM с обратными вызовами, заданными для перехода состояния потока и обработки потока RT.
        3. Создает элемент обработчика звука в потоке, если звуковой конвейер поддерживает потоковую передачу разгрузки.
        4. Добавляет ACXSTREAM в свой потоковый мост. При этом вызывается обратный вызов EvtCircuitCreateStream профиля Bluetooth LE Audio.
        1. Сохраняет свойства локально из ACXOBJECTBAG , заданного драйвером потоковой передачи ACX IHV для будущих обратных вызовов перехода потока.
        2. Если конечная точка звука предназначена для одноадресной потоковой передачи профиля Bluetooth LE Audio:
          1. Выполняет операцию кодека конфигурации, как определено в спецификации BAP. Параметры для операции являются производными от ACXDATAFORMAT, указанного в обратном вызове EvtAcxCircuitCreateStream , и других параметров потока в ACXOBJECTBAG или возможностей кодека, поддерживаемых контроллером Bluetooth.
          2. Задает свойство BluetoothLEAudio_CodecConfigurationв ACXOBJECTBAG со значением, используемым для настройки удаленных звуковых устройств.
          1. Создает ACXSTREAM с обратными вызовами, заданными для переходов состояния потока.

          Блок-схема, показывающая процесс создания аудиопотока Bluetooth LE.

          Переходы состояния потоковой передачи

          ACX определяет порядок передачи потокового состояния на основе звукового потока и перехода состояния в более активное или менее активное состояние.

          • Для потоков отрисовки, переходя из менее активного состояния в более активное, канал профиля сначала получает событие, а затем канал потоковой передачи.
          • Для потоков отрисовки, переходя из более активного состояния в менее активное, потоковый канал сначала получает событие, а затем канал профиля.
          • Для потоков записи, переходя из менее активного состояния в более активное, потоковый канал сначала получает событие, а затем канал профиля.
          • Для потоков записи, переходя из более активного состояния в менее активное, профилирование канала с первым получает событие, а затем канал потоковой передачи.
          Подготовка потока

          При вызове обратного вызова EvtAcxStreamPrepareHardware профиль Bluetooth LE Audio:

          1. Выделяет ресурсы для одноадресного потока следующими средствами:
            1. Настройка CIG с помощью команды HCI_LE_Set_CIG_Parameters.
            2. Отправка операции качества обслуживания конфигурации ASCS для синхронизации параметров с удаленным устройством.

            Блок-схема, иллюстрирующая подготовку аудиопотока Bluetooth LE для канала профиля.

            При вызове обратного вызова EvtAcxStreamPrepareHardware драйвер потоковой передачи IHV ACX выделяет необходимые ресурсы потоковой передачи и инициализирует звуковой конвейер, чтобы он был в приобретенном состоянии.

            Блок-схема, изображающая подготовку потока Bluetooth LE Audio для канала потоковой передачи.

            Запуск потока

            При вызове обратного вызова EvtAcxStreamRun профиль Bluetooth LE Audio:

            1. Применяет все параметры конфигурации пути к данным, заданные драйвером потоковой передачи ACX в процедуре создания потока с помощью команды HCI_Configure_Data_Path.
            2. Начинает процедуру запуска потока следующим образом:
              1. Выполнение процедуры включения одноадресного потока BAP для одноадресного потока:
                1. Отправка операции Enable в удаленные конечные точки.
                2. Создание CISes, если они еще не созданы с помощью команды HCI_LE_Create_CIS.
                1. Устанавливает пути к данным ISO с помощью команды HCI_LE_Setup_ISO_Data_Path
                  1. Если драйвер потоковой передачи IHV ACX задает свойство BluetoothLEAudio_CodecCapabilities , то значение поля Codec_ID в HCI_LE_Setup_ISO_Data_Path должно быть равно прозрачному (0x3), как указано в разделе Назначенные номера Bluetooth. В противном случае значение должно совпадать с идентификатором кодека, используемым в операции кодека конфигурации в процедуре создания потока.

                  Блок-схема, показывающая процесс запуска аудиопотока Bluetooth LE для канала профиля.

                  При вызове обратного вызова EvtAcxStreamRun драйвер потоковой передачи IHV ACX начинает обработку входящих звуковых данных из аудиосистемы Windows (отрисовка) или контроллера Bluetooth (запись).

                  Блок-схема, иллюстрирующая процесс запуска аудиопотока Bluetooth LE для канала потоковой передачи.

                  Приостановка потока

                  При вызове обратного вызова EvtAcxStreamPause профиль Bluetooth LE Audio:

                  1. Выполняет процедуру отключения одноадресного потока BAP.
                  2. Удаляет путь к данным ISO с помощью команды HCI_LE_Remove_ISO_Data_Path.
                  3. Выполняет процедуру готовности приемника ASCS к остановке, если аудиопоток является потоком одноадресной записи.

                  Блок-схема, изображающая процесс приостановки аудиопотока Bluetooth LE для канала профиля.

                  При вызове обратного вызова EvtAcxStreamPause драйвер потоковой передачи IHV ACX приостанавливает конвейер обработки звука.

                  Блок-схема, показывающая процесс приостановки аудиопотока Bluetooth LE для канала потоковой передачи.

                  Поток выпуска

                  При вызове обратного вызова EvtAcxStreamReleaseHardware профиль Звука Bluetooth LE выполняет процедуру выпуска одноадресного потока BAP следующим образом:

                  1. Отправка операции выпуска ASCS на удаленное устройство Bluetooth LE Audio
                  2. Отключение CIS, если он не используется другим активным потоком.
                  3. Удаление CIG, если все CISes отключены.

                  Блок-схема, иллюстрирующая процесс выпуска аудиопотока Bluetooth LE для канала профиля.

                  При вызове обратного вызова EvtAcxStreamReleaseHardware драйвер потоковой передачи IHV ACX освобождает ресурсы звукового конвейера.

                  Блок-схема, показывающая процесс выпуска аудиопотока Bluetooth LE для канала потоковой передачи.

                  Отключение конечной точки

                  Профиль Windows Bluetooth LE Audio обновляет состояние подключения конечной точки, если удаленное одноадресное устройство не имеет подключения LE-ACL к компьютеру или сообщает через доступные звуковые контексты PACS, что оно недоступно для потоковой передачи. При отключении конечной точки служба звука Windows делает недействительными все активные потоки в конечную точку. Это приводит к приостановке потоковой передачи и последовательности выпуска.

                  Удаление конечной точки

                  Конечная точка Bluetooth LE Audio удаляется из системы при уничтожении канала профиля или канала потоковой передачи. Канал профиля может быть удален при удалении связывания удаленного одноадресного устройства из Windows или отключении радиомодуля Bluetooth.

                  1. Когда профиль Windows Bluetooth LE Audio удаляет свой канал, ACX отключает интерфейсы конечных точек, чтобы сообщить звуковой службе Windows о том, что конечную точку необходимо удалить.
                  2. Если интерфейсы отключены, служба звука Windows делает недействительными все активные потоки к конечной точке Bluetooth LE Audio. Эта операция приводит к приостановке потока и освобождению обратных вызовов в канале потоковой передачи.
                  3. Чтобы завершить удаление конечной точки, ACX делает недействительным канал драйвера потоковой передачи IHV ACX, в результате чего WDF вызывает обратный вызов очистки канала.
                  4. При вызове обратного вызова очистки драйвер потоковой передачи IHV ACX освобождает свой канал.

                  Блок-схема, показывающая процесс удаления конечной точки Bluetooth LE Audio.

                  Громкость и отключение звука

                  Канал потоковой передачи IHV ACX должен включать элементы громкости и отключения звука, только если драйверу потоковой передачи требуется звуковой модуль. При использовании звукового обработчика необходимо задать следующие флаги конфигурации:

                  ACX_AUDIOENGINE_CONFIG audioEngineCfg; ACX_AUDIOENGINE_CONFIG_INIT(&audioEngineCfg); … audioEngineCfg.Flags |= AcxAudioEngineConfigVolumeSecondary; // Use this control only if endpoint doesn't have one. audioEngineCfg.MuteElement = muteElement; audioEngineCfg.Flags |= AcxAudioEngineConfigMuteSecondary; // Use this control only if endpoint doesn't have one. audioEngineCfg.PeakMeterElement = peakmeterElement; audioEngineCfg.Flags |= AcxAudioEngineConfigPeakMeterSecondary; // Use this control only if endpoint doesn't have one. 

                  Это необходимо, чтобы конечные точки Bluetooth LE Audio могли использовать определенные bluetooth SIG профили управления громкостью и микрофоном для изменения громкости и отключения звука для конечных точек одноадресной передачи звука.

                  Если удаленное устройство Bluetooth LE Audio не поддерживает службы управления громкостью или микрофоном или конечная точка создана для широковещательной передачи звука, элементы громкости и отключения звука в звуковом движке должны служить резервным вариантом для обработки запросов на изменение из звуковой системы. Аудиосистема Windows обрабатывает изменения громкости и отключение звука. Если звуковой модуль отсутствует и удаленное устройство не поддерживает громкость, либо службы микрофона или конечная точка аудио предназначена для широковещательного звука.

                  Сосуществование bluetooth LE и классического звука

                  Windows должна гарантировать, что для сопряженного звукового устройства Bluetooth, поддерживающего обе технологии, активен только классический звук или звук LE. Если звук le активен, то DDIs боковой полосы для A2DP и HFP для удаленного устройства отключаются, а канал профиля создается для конечной точки звука LE. Если классический звук активен, DDIs боковой полосы для A2DP и HFP для удаленного устройства включены, а канал профиля не создается для конечной точки звука LE.

                  Исключение брандмауэра Windows для прокси-сервера пробуждения

                  Bluetooth LE Audio не имеет требований к управлению питанием или потоков за пределами того, что уже определено WDF.

                  Связанные темы

                  • Расширения аудиоклассов ACX
                  • Спецификация базового аудиопрофиля Bluetooth
                  • Спецификация Bluetooth Core 5.3
                  • Спецификация службы опубликованных возможностей звука Bluetooth
                  • Спецификация службы управления аудиопотоком Bluetooth
                  • Назначенные номера Bluetooth
                  • Рекомендации по обходу Bluetooth HFP для аудиодрайверов
                  • Обход потоковой передачи аудио через Bluetooth HFP

                  Bluetooth LE не так уж и страшен, или Как улучшить пользовательский опыт без особых усилий

                  Недавно мы в команде придумали и реализовали функцию передачи денег по воздуху с помощью технологии Bluetooth LE. Я хочу рассказать вам, как мы это сделали и что Apple предоставляет нам из инструментов. Многие разработчики думают что Bluetooth — это сложно, ведь это достаточно низкоуровневый протокол, и по нему не так много специалистов. Но всё не так страшно, и на самом деле использовать эту функцию очень просто! А те функции, которые можно реализовать с помощью Bluetooth LE, безусловно, интересны и впоследствии позволят выделить ваше приложение среди конкурентов.

                  Давайте сначала разберёмся, что это вообще за технология и в чём её отличие от классического Bluetooth.

                  Что такое Bluetooth LE?


                  Почему разработчики Bluetooth назвали эту технологию именно Low Energy? Ведь с каждой новой версией Bluetooth энергопотребление и без того многократно снижалось. Ответ кроется в этой батарейке.

                  Её диаметр всего 2 см, а ёмкость около 220 мА*ч. Когда инженеры разрабатывали Bluetooth LE, они стремились к тому, чтобы устройство с такой батарейкой работало несколько лет. И у них это получилось! Bluetooth LE-устройства c таким элементом питания могут работать от года. Кто из вас еще по-старинке выключает Bluetooth на телефоне для экономии энергии, как это делали в 2000-м? Зря вы это делаете — экономия будет меньше 10 секунд работы телефона в день. А функциональность вы отключаете очень большую, такую как Handoff, AirDrop и другие.

                  Чего же инженеры добились, разработав Bluetooth LE? Они усовершенствовали классический протокол? Сделали его более энергоэфективным? Просто оптимизировали все процессы? Нет. Они полностью переделали архитектуру стека Bluetooth и добились того, что теперь, чтобы быть видимым для всех других устройств, необходимо меньше времени находиться в эфире и занимать канал. В свою очередь это позволило хорошо сэкономить на энергопотреблении. А с новой архитектурой теперь можно стандартизировать любое новое устройство, благодаря чему разработчики со всего мира могут коммуницировать с устройством, а значит, и с легкостью писать новые приложения для управления им. Кроме того, в архитектуру заложен принцип self-discovery: при подключении к устройству не нужно вводить никакие пин-коды, и если ваше приложение умеет общаться с этим устройством, подключение занимает считанные миллисекунды.

                  • Меньше времени в эфире.
                  • Меньше расход энергии.
                  • Новая архитектура.
                  • Уменьшено время подключения.

                  Частота осталась та же: 2,4 ГГц, не сертифицируемая и свободная для использования во многих странах. А вот задержка подключения стала меньше: 15-30 мс вместо 100 мс у классического Bluetooth. Расстояние работы осталось таким же — 100 м. Интервал передачи не сильно, но изменился — вместо 0,625 мс стало 3 мс.

                  Но не могло же из-за этого энергопотребление уменьшиться в десятки раз. Конечно же, что-то должно было пострадать. И это скорость: вместо 24 Мбит/с стало 0,27 Мбит/с. Вы, наверное, скажете, что это смешная скорость для 2018 года.

                  Где используется Bluetooth LE?


                  Технология эта немолодая, впервые она появилась в iPhone 4s. И уже успела завоевать много сфер. Bluetooth LE используется во всех устройствах умного дома и в носимой электронике. Сейчас уже есть даже чипы размером с кофейное зерно.

                  А как эта технология применяется в программном обеспечении?

                  Поскольку Apple была первой, кто встроил в своё устройство Bluetooth и начал её использовать, то к настоящему времени они достаточно хорошо продвинулись и встроили технологию в свою экосистему. И сейчас вы можете встретить эту технологию в таких сервисах, как AirDrop, Devices quick start, Share passwords, Handoff. И даже уведомления в часах сделаны через Bluetooth LE. Вдобавок, Apple выложила в открытый доступ документацию, как сделать так, чтобы на ваши собственные устройства приходили уведомления из всех приложений. Какие бывают роли устройств в рамках Bluetooth LE?

                  Broаdcaster. Отправляет сообщения всем, кто находится рядом, к этому устройству нельзя подключиться. По такому принципу работают iBeacons и навигация в помещениях.

                  Observer. Слушает, что происходит вокруг, и получает данные только от общедоступных сообщений. Соединения не создаёт.

                  А вот с Central и Peripheral интереснее. Почему их не назвали просто Server-Client? Логично же, судя по названию. А вот и нет.

                  Потому что Peripheral, на самом деле, выступает как сервер. Это периферийное устройство, которое потребляет меньше энергии и к которому подключается более мощный Central. Peripheral может извещать, что он находится рядом и какие у него есть службы. К нему может подключиться только одно устройство, и у Peripheral есть какие-то данные. А Central может сканировать эфир в поиске устройств, отправлять запросы на подключение, подключаться к любому количеству устройств, может читать, записывать и подписывать на данные у Peripheral.

                  Что же нам, как разработчикам, доступно в экосистеме Apple?

                  Что нам доступно?


                  iOS/Mac OS:

                  • Peripheral и Central.
                  • Фоновый режим.
                  • Восстановление состояния.
                  • Интервал подключения 15 мс.
                  • watchOS 4+/tvOS 9+.
                  • Только Сentral.
                  • Максимум два подключения.
                  • Apple watch series 2+/ AppleTv 4+.
                  • Отключение при переходе в фоновый режим.
                  • Интервал подключения 30 мс.

                  Как работает протокол


                  Как происходит процесс поиска и подключения?

                  Peripheral сообщает о своем присутствии с частотой advertisement-интервала, его пакет очень маленький и содержит всего несколько идентификаторов сервисов, которые предоставляет устройство, а также имя устройства. Интервал может быть достаточно большим и способен варьироваться в зависимости от текущего статуса устройства, режима энергосбережения и других настроек. Apple советует разработчикам внешних устройств привязывать длину интервала к акселерометру: увеличивать интервал, если устройством не пользуются, а когда оно активно — уменьшать, чтобы быстро находить устройство. Advertisement-интервал никак не коррелирует c интервалом подключения и определяется самим устройством в зависимости от энергопотребления и своих настроек. Нам он в экосистеме Apple недоступен и неизвестен, им полностью управляет система.

                  После того, как мы нашли устройство, отправляем запрос на подключение, и вот тут на сцену выходит интервал подключения — время, через которое второе устройство может ответить на запрос. Но это при подключении, а что же происходит при чтении/записи?

                  Интервал подключения также фигурирует и при чтении данных — его уменьшение в 2 раза увеличивает скорость передачи данных. Но нужно понимать, что если оба устройства не поддерживают одинаковый интервал, то будет выбран максимальный из них.

                  Давайте рассмотрим, из чего состоит пакет с информацией, который передает Peripheral.

                  MTU (maximum transmission unit) такого пакета определяется в процессе подключения и варьируется от устройства к устройству и в зависимости от операционной системы. В протоколе версии 4.0 MTU был около 30, и размер полезных данных не превышал 20 байтов. В версии 4.2 всё поменялось, теперь можно передавать около 520 байтов. Но, к сожалению, эту версию протокола поддерживают только устройства младше IPhone 5s. Размер накладных расходов, независимо от размера MTU, составляет 7 байтов: сюда входят ATT и L2CAP заголовков. С записью, в целом, похожая ситуация.

                  Есть только два режима: с ответом и без. Режим без ответа значительно ускоряет передачу данных, поскольку нет интервала ожидания перед следующей записью. Но этот режим доступен не всегда, не на всех устройствах и не на всех системах. Доступ к этому режиму записи может ограничить сама система, потому что он считается менее энергоэкономичным. В iOS eсть метод, в котором можно проверить перед записью, доступен ли такой режим.

                  Теперь давайте рассмотрим, из чего состоит протокол.

                  Протокол состоит из 5 уровней. Слой приложения — эта ваша логика, описанная поверх CoreBluetooth. GATT (Generic Attributes Layer) служит для обмена сервисами и характеристиками, которые есть на устройствах. ATT (Attributes Layer) используется для управления вашими характеристиками и передачей ваших данных. L2CAP — низкоуровневый протокол обмена данными. Controller — это уже сам BT-чип.

                  Вы, наверное, спросите, что такое GATT и как мы можем с ним работать?

                  GATT состоит из характеристики и сервисов. Характеристика — это объект, в котором хранятся ваши данные, словно переменная. А сервис — это группа, в которой находятся ваши характеристики, словно пространство имён. У сервиса есть название — UUID, вы сами его выбираете. Сервис может содержать в себе дочерний сервис.

                  У характеристики тоже есть свой UUID — фактически, имя. Значение (Value) характеристики — это NSData, сюда вы можете записывать и хранить данные. Дескрипторы — это описание вашей характеристики, вы можете описать, какие данные вы ожидаете в этой характеристике, или что они означают. В протоколе Bluetooth есть много дескрипторов, но в Apple-системах пока доступно только два: человеческое описание и формат данных. Также есть уровни доступа (Permissions) для вашей характеристики:

                  Попробуем сами


                  У нас появилась идея сделать возможность передачи денег по воздуху, ничего не требуя от получателя. Представьте, вот ломаете голову над очень интересной задачей, пишете идеальный код, и тут коллега предлагает сходить за кофе. А вы так увлечены задачей, что не можете отлучиться, и просите его купить вам чашечку вкусного капучино. Он приносит вам кофе, и нужно вернуть ему деньги. Можно перевести по номеру телефона, работает отлично. Но вот неловкая ситуация — вы не знаете его номера. Ну вот так, три года работаете, а номерами не обменялись 🙂

                  Поэтому мы решили сделать возможность передачи денег тем, кто находится рядом, без ввода каких-либо пользовательских данных. Как в AirDrop. Просто выбрать пользователя и отправить нужную ему сумму. Давайте посмотрим, что нам для этого нужно.

                  Отображение PUSH


                  Нам нужно, чтобы отправитель:

                  1. Мог найти все устройства, которые находятся рядом и поддерживают наш сервис.
                  2. Мог прочитать реквизиты.
                  3. И мог отослать сообщение получателю о том, что успешно отправил ему деньги.

                  Для начала нужно придумать названия нашего сервиса и характеристик. Как я говорил, это UUID. Просто генерируем их и сохраняем на Peripheral и Central, чтобы на обоих устройствах были одинаковые.

                  Вы вольны использовать любые UUID, кроме тех, которые оканчиваются вот так: XXXXXXXX-0000-1000-8000-00805F9B34FB, — они зарезервированы под разные компании. Вы сами можете купить себе такой номер и никто его использовать не будет. Это будет стоить $2500.

                  Далее нам нужно будет создать менеджеры: один для передачи денежных средств, другой для получения. Нужно просто указать делегатов. Передавать у нас будет Central, получать Peripheral. Мы создаем оба, потому что и отправителем, и получателем может быть одно лицо в разное время.

                  Теперь нам нужно сделать возможность обнаружения получателя и записать в нашу характеристику реквизиты получателя.

                  Для начала создадим сервис. Пропишем UUID и укажем, что он primary — то есть сервис является главным для этого устройства. Хороший пример: пульсомер, для которого главным сервисом будет текущее состояние пульса, а состояние батареи — это второстепенная информация.

                  Далее создаем две характеристики: одну для чтения реквизитов получателя, вторую для записи, чтобы получатель мог узнать об отправке денег. Регистрируем их в нашем сервисе, потом добавляем в менеджер, запускаем обнаружение и указываем UUID сервиса, чтобы все устройства, которые находятся рядом, могли узнать о нашем сервисе до подключения к нему. Эти данные помещаются в пакет, который отправляет Central в ходе вещания.

                  Получатель готов, приступим к отправителю. Запустим поиск и подключение.

                  При включении менеджера мы запускаем поиск устройств с нашим сервисом. При нахождении мы их получаем в методе делегата и сразу подключаемся. Важно: нужно сохранять strong-ссылку на все Peripheral, с которыми вы работаете, иначе они «утекут».

                  После успешного подключения настраиваем делегат, который будет работать с данным устройством, и получаем от устройства нужный нам сервис.

                  Мы успешно подключились к получателю, теперь нужно прочитать его реквизиты.

                  Мы после подключения уже запросили все сервисы с устройства. И после их получения будет вызван метод делегата, в котором будут перечислены все сервисы, доступные на данном устройстве. Находим нужный и запрашиваем его характеристики. Результат можно будет найти по UUID в методе делегата, в котором хранятся данные для перевода. Пробуем их прочитать, и получим искомое опять в методе делегата. Все сервисы, характеристики и их значения кешируются системой, так что запрашивать их впоследствии каждый раз необязательно.

                  Всё, мы отправили деньги за кофе, самое время показать получателю красивое уведомление, чтобы он ждал рубли на своем счёте. Для этого нужно реализовать процесс отправки сообщения.

                  У отправителя достаем нужную нам характеристику, в данном случае мы её взяли из сохраненного значения. Но до этого вам её нужно получить с устройства, как мы делали до этого. А дальше просто записываете данные в нужную характеристику.

                  После этого на другом устройстве получаем в методе делегата запрос на запись. Тут вы можете прочитать данные, которые вам отправляют, ответить на какую-либо ошибкой, например, нет доступа, или данной характеристики не существует. Всё будет работать, но только если оба устройства включены и приложения активны. А нам нужно, чтобы работало и в фоне!

                  Apple позволяет использовать Bluetooth в фоне. Для этого нужно в info.plist указать ключ, в каком режиме мы хотим использовать, в Peripheral или Central.

                  Далее в менеджере нужно указать ключ восстановления и создать метод делегата. Теперь нам доступен и фоновый режим. Если приложение заснёт или будет выгружено из памяти, то при нахождении нужного Peripheral или при подключении Central оно проснётся, а менеджер восстановится с вашим ключом.

                  Всё отлично, уже готовы релизиться. Но тут к нам прибегают дизайнеры и говорят: «Хотим вставить фотографии пользователей, чтобы им было легче находить друг друга». Что же делать? У нас в характеристику можно записать всего какие-то 500 байтов, а на каких-то устройствах вообще 20 🙁

                  Спустимся глубже


                  Чтобы решить эту проблему, нам пришлось спуститься глубже.

                  Сейчас мы общались устройствами на уровне GATT/ATT. Но в iOS 11 у нас есть доступ к протоколу L2CAP. Однако в этом случае придётся самостоятельно позаботиться о передаче данных. Пакеты отправляются с MTU 2 Кб, не нужно ни во что перекодировать, применяется обычный NSStream. Скорость передачи данных до 394 Килобит/с., по заверению Apple.

                  Допустим, вы передаёте какие-либо данные вашего сервиса от Peripheral к Central в виде обычных характеристик. И понадобилось открыть канал. Вы открываете его на Peripheral, в ответ получаете PSM — это номер канала, к которому можно подключиться, и нужно с помощью тех же характеристик передать его Central. Номер динамический, система сама выбирает, какой PSM открыть в данный момент. После передачи можно уже на Сentral подключиться к Peripheral и обмениваться данными в удобном для вас формате. Давайте рассмотрим, как это сделать.

                  Для начала на Peripheral открываем порт с шифрованием. Можно делать и без шифрования, тогда это немного ускорит передачу.

                  Далее мы в методе делегата получаем PSM и отправляем на другое устройство.

                  После подключения другого устройства у нас вызовется метод, в котором из канала мы можем достать нужные нам для передачи NSStream.

                  С Central еще проще, мы просто подключаемся к каналу с нужным номером…

                  … и после этого получаем нужные нам стримы. В них вы можете передавать абсолютно любые данные любого размера, и строить поверх L2CAP свой протокол. Так мы и реализовали у себя передачу фотографий получателя.

                  Но есть подводные камни, куда же без них.

                  Подводные камни


                  Давайте рассмотрим подводные камни при работе в фоновом режиме. Поскольку вам доступны роли Peripheral и Central, вы можете подумать. что в фоне можете определять, какие устройства рядом находятся в фоновом режиме, а какие в активном. В теории так и должно было быть, но Apple ввела ограничение: телефоны, которые находятся в фоновом режиме, будь то Central или Peripheral, не доступны для других телефонов, которые тоже находятся в фоновом режиме. Также телефоны, которые находятся в фоновом режиме, не видны с неiOS-устройств. Давайте рассмотрим почему так происходит.

                  Когда ваше устройство активно, оно посылает обычный broadcast-пакет, в котором может быть имя устройства и список сервисов. которые предоставляет это устройство. И overflow данные — всё что не поместилось.

                  Когда же устройство переходит в фоновый режим, оно не передает название, а список поддерживаемых сервисов переносит в overflow-данные. Если приложение активно, то при сканировании с iOS-устройства оно читает эти данные, а при переходе в фон — игнорирует. Поэтому при переходе в фон вы не сможете видеть приложения, которые также находятся в фоне. Остальные операционные системы Apple всегда игнорируют overflow-данные, поэтому если вы будете искать устройства, поддерживающие ваш сервис, то получите пустой массив. А если подключиться к каждому устройству, которое находится рядом, и запросить поддерживаемые сервисы, то в списке, возможно, будет ваш сервис, и вы сможете с ним работать.

                  Дальше мы уже готовились передавать в тестирование, правили мелкие недочёты, занимались оптимизацией. И вдруг в какой-то момент мы стали получать в консоли эту ошибку:

                  CoreBluetooth[WARNING] Unknown error: 124

                  Самое плохое было в том, что никакой метод делегата не вызывался, мы даже не могли никак обыграть эту ошибку для пользователя. Просто сообщение в лог — и тишина, всё замирало. Никаких особых изменений не вносилось, поэтому мы начали откатываться по коммитам. И обнаружили, что однажды оптимизировали код и переделали способ записи данных. Проблема крылась в том, что не все клиенты были обновлены, поэтому возникала такая ошибка.

                  .write != .writeWithoutResponse

                  Мы, счастливые, что всё исправили, побежали скорее передавать в тестирование, а они нам почти сразу возвращают: «Ваши модные фоточки не работают. Они все недогруженные приходят». Мы начали пробовать, и правда, иногда, на разных устройствах, в разное время приходят битые фотографии. Начали искать причину.

                  И тут снова увидели прежнюю ошибку. Сразу подумали, что дело в разных версиях. Но после полного удаления старой версии со всех тестовых устройств ошибка всё равно воспроизводилась. Мы взгрустнули…

                  CoreBluetooth[WARNING] Unknown error: 722 CoreBluetooth[WARNING] Unknown error: 249 CoreBluetooth[WARNING] Unknown error: 312

                  Начали искать инструмент для отладки. Первое, что нам попалось, это Apple Bluetooth Explorer. Мощная программа, много всего умеет, но вот для отладки протокола Bluetooth LE одна маленькая вкладка с поиском устройств и получением характеристик. А нам-то нужно было анализировать L2CAP.

                  Потом нашли LightBlue Explorer. Оказалась вполне приличная программа, правда, с дизайном из iOS 7. Может делать то же самое, что и Bluetooth Explorer, а еще умеет подписываться на характеристики. И работает стабильнее. Всё хорошо, но опять без L2CAP.

                  И тут нам вспомнился всем известный сниффер WireShark.

                  Оказалось, он знаком с Bluetooth LE: может читать L2CAP, но только под Windows. Хотя это не страшно, что мы, не найдем винду, что ли. Самый большой минус — программа работает только с определенным устройством. То есть нужно было найти где-то устройство в официальном магазине. А вы сами понимаете, в большой компании вряд ли одобрят покупку непонятного устройства на барахолке. Мы даже начали просматривать зарубежные онлайн-магазины.

                  Но тут обнаружили в Additional Xcode Tools программу PacketLogger. Она позволяет смотреть траффик, которой идет на OS X-устройстве. А почему бы не переписать наш MoneyDrop под OS X? Он у нас уже был отдельной библиотеки. Мы просто заменили UIImage на NSImage, всё завелось само через 10 минут.

                  Наконец-то мы могли читать пакеты, которыми обмениваются устройства. Сразу стало понятно, что в момент передачи данных по L2CAP записывалась одна из характеристик. А из-за того, что канал был полностью занят передачей фотографии, iOS игнорировала запись, а отправитель после игнора обрывал канал. После исправления проблем с передачей фотографии не было.

                  На этом всё, спасибо за прочтение 🙂

                  Полезные ссылки


                  WWDC/CoreBluetooth:

                  • https://developer.apple.com/videos/play/wwdc2017/712/
                  • WWDC 2012 Session 703 Core Bluetooth 101
                  • WWDC 2012 Session 705 Advanced Core Bluetooth
                  • https://www.bluetooth.com/specifications/gatt
                  • Getting Started with Bluetooth Low Energy O’Reilly
                  • Arrow Electronics → Bluetooth Low Energy Series

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *