Поделиться через

Синхронные и асинхронные команды кодека

  • Статья

Подпрограмма TransferCodecVerbs позволяет драйверам функций отправлять команды в аудио- и модемные кодеки, подключенные к контроллеру HD Audio. Команды кодека могут выполняться синхронно или асинхронно:

  • Если вызов TransferCodecVerbs отправляет список команд для синхронной обработки, подпрограмма возвращается только после того, как кодек или кодеки обработают все команды.

  • Если вызов TransferCodecVerbs отправляет список команд для асинхронной обработки, подпрограмма возвращается, как только драйвер шины HD Audio добавит команды во внутреннюю очередь команд, не дожидаясь, пока кодек или кодеки обработают команды. После того как кодеки обработают команды, драйвер автобуса уведомляет драйвер-функцию, вызывая подпрограмму обратного вызова.

В зависимости от характера команд кодека, которые он отправляет, драйвер функции использует один или несколько из следующих методов для получения ответов от кодека:

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

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

  • Если драйвер функции должен знать, когда выполняются команды кодека, но не должен видеть ответы, он использует асинхронный режим и использует подпрограмму обратного вызова для уведомления. Однако он отменяет или игнорирует ответы на команды кодека. Подпрограмма обратного вызова может использовать событие потоковой передачи ядра (KS) для отправки уведомления main части драйвера.

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

TransferCodecVerbs возвращает STATUS_SUCCESS, если ему удастся добавить список команд во внутреннюю очередь команд водителя шины. Несмотря на то, что вызов выполнен успешно, ответы могут по-прежнему быть недопустимыми. Драйвер функции должен проверка биты состояния в ответах кодека, чтобы определить, являются ли они допустимыми. Это правило применяется как к синхронному, так и к асинхронному режиму.

Причиной недопустимого ответа, скорее всего, является одна из следующих причин:

  • Команда не достигла кодека.

  • Кодек ответил, но ответ был потерян, когда в RIRB произошло переполнение первым в, первым выходом (FIFO).

Последняя проблема указывает, что RIRB FIFO имеет недостаточный размер.

Каждый ответ кодека содержит флаг IsValid , указывающий, является ли ответ допустимым, и флаг HasFifoOverrun , указывающий, произошло ли переполнение RIRB FIFO. Если Значение IsValid = 0, указывающее, что ответ недопустим, флаг HasFifoOverrun помогает определить источник сбоя:

  • Если HasFifoOverrun = 0, кодек не смог ответить в течение требуемого интервала времени. Вероятная причина заключается в том, что команда никогда не достигла кодека.

  • Если HasFifoOverrun = 1, то команда, вероятно, достигла кодека, но ответ был потерян из-за переполнения FIFO.

Во время вызова Метода TransferCodecCommands вызывающий объект предоставляет указатель на массив HDAUDIO_CODEC_TRANSFER структур. Каждая структура содержит команду и предоставляет пространство для ответа. Водитель автобуса всегда записывает каждый ответ в структуру, содержащую команду, которая вызвала ответ.

Для каждого вызова TransferCodecCommands порядок обработки команд определяется порядком команд в массиве. Обработка первой команды в массиве всегда завершается до начала обработки второй команды и т. д.

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

Однако относительный порядок команд, отправленных двумя разными экземплярами драйвера функций, не определен. (Каждый экземпляр имеет собственный физический объект устройства.) Например, если экземпляр 1 вызывает Метод TransferCodecCommands для отправки команд A, B и C в порядке A-B-C, а экземпляр 2 вызывает TransferCodecCommands для отправки команд X, Y и Z в порядке X-Y-Z, то драйвер шины может выполнять команды в порядке A-X-Y-B-Z.

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

Например, аппаратный интерфейс для записи последовательности байтов данных в кодек может состоять из регистра индекса и 8-битового регистра данных. Сначала драйвер функции отправляет команду кодека для загрузки начального индекса в регистр индекса. Затем драйвер отправляет команду для записи первого байта данных в регистр данных. Регистр индекса увеличивается после каждой последующей записи в регистр данных до завершения передачи. Однако если двум потокам драйвера не удается правильно синхронизировать доступ к индексу и регистрам данных, относительный порядок доступа к отдельной регистрации двумя потоками не определен, а вероятным результатом является повреждение данных или недопустимая конфигурация оборудования.

Подпрограмма TransferCodecVerbs доступна в обеих версиях HD Audio DDI.