Comandos de códec sincrónicos y asincrónicos

La rutina TransferCodecVerbs permite a los controladores de función enviar comandos a códecs de audio y módem que están conectados a un controlador de audio HD. Los comandos de códec pueden ejecutarse de forma sincrónica o asincrónica:

• Si una llamada a TransferCodecVerbs envía una lista de comandos que se van a procesar de forma sincrónica, la rutina solo devuelve después de que el códec o los códecs hayan procesado todos los comandos.

• Si una llamada a TransferCodecVerbs envía una lista de comandos que se van a procesar de forma asincrónica, la rutina se devuelve tan pronto como el controlador del bus de AUDIO DE HD agrega los comandos a su cola de comandos interna, sin esperar a que el códec o los códecs procesen los comandos. Después de que los códecs hayan procesado los comandos, el controlador de bus notifica al controlador de función llamando a una rutina de devolución de llamada.

En función de la naturaleza de los comandos de códec que envía, el controlador de función usa una o varias de las técnicas siguientes para recuperar respuestas de un códec:

• Si el controlador de función debe tener la respuesta del códec para poder realizar cualquier procesamiento adicional, usa el modo sincrónico.

• Si el controlador de función no necesita esperar a que se completen los comandos de códec, para ver las respuestas del códec y saber cuándo se completan los comandos, usa el modo asincrónico, omite la rutina de devolución de llamada (excepto liberar el almacenamiento de los comandos de códec) y descarta o omite las respuestas a los comandos de códec.

• Si el controlador de función debe saber cuándo se completan los comandos de códec, pero no necesita ver las respuestas, usa el modo asincrónico y se basa en la rutina de devolución de llamada para la notificación. Sin embargo, descarta o omite las respuestas a los comandos de códec. La rutina de devolución de llamada podría usar un evento de streaming de kernel (KS) para enviar la notificación a la parte principal del controlador.

• Si el controlador de función debe saber cuándo se completan los comandos de códec y cuáles son las respuestas, pero debe reanudar el procesamiento inmediatamente en lugar de esperar a que se completen los comandos, usa el modo asincrónico y evita leer las respuestas hasta que reciba la rutina de devolución de llamada. La rutina de devolución de llamada o la parte principal del controlador pueden inspeccionar las respuestas.

TransferCodecVerbs devuelve STATUS_SUCCESS si tiene éxito al agregar la lista de comandos a la cola de comandos interna del controlador de bus. Aunque la llamada se realiza correctamente, es posible que las respuestas no sean válidas. El controlador de función debe comprobar los bits de estado en las respuestas del códec para determinar si son válidos. Esta regla se aplica al modo sincrónico y asincrónico.

Es probable que la causa de una respuesta no válida sea una de las siguientes:

• El comando no alcanzó el códec.

• El códec respondió, pero la respuesta se perdió cuando se produjo una saturación de la primera entrada y salida (FIFO) en el RIRB.

El último problema indica que el FIFO de RIRB es de tamaño insuficiente.

Cada respuesta de códec contiene una marca IsValid para indicar si la respuesta es válida y una marca HasFifoOverrun para indicar si se ha producido una saturación de FIFO de RIRB. Si IsValid = 0, que indica que una respuesta no es válida, la marca HasFifoOverrun ayuda a identificar el origen del error:

• Si HasFifoOverrun = 0, el códec no pudo responder dentro del intervalo de tiempo necesario. La causa probable es que el comando nunca alcanzó el códec.

• Si HasFifoOverrun = 1, el comando probablemente alcanzó el códec, pero la respuesta se perdió debido a una saturación de FIFO.

Durante una llamada a TransferCodecCommands, el autor de la llamada proporciona un puntero a una matriz de estructuras HDAUDIO_CODEC_TRANSFER . Cada estructura contiene un comando y proporciona espacio para una respuesta. El controlador de bus siempre escribe cada respuesta en la estructura que contiene el comando que desencadenó la respuesta.

Para cada llamada a TransferCodecCommands, el orden en que se procesan los comandos viene determinado por el orden de los comandos de la matriz. El procesamiento del primer comando de la matriz siempre se completa antes de procesar el segundo comando, etc.

Además, si un cliente realiza una llamada asincrónica a TransferCodecCommands y, a continuación, llama a TransferCodecCommands una segunda vez sin esperar la rutina de devolución de llamada desde la primera llamada, el orden relativo en el que se procesan los dos grupos de comandos de las dos llamadas se define mediante el orden en el que el cliente envió los dos grupos de comandos. Por lo tanto, el controlador de bus procesa todos los comandos de la primera llamada antes de comenzar a procesar los comandos desde la segunda llamada.

Sin embargo, el orden relativo de los comandos enviados por dos instancias de controlador de función diferentes no está definido. (Cada instancia tiene su propio objeto de dispositivo físico). Por ejemplo, si la instancia 1 llama a TransferCodecCommands para enviar comandos A, B y C en el orden A-B-C y la instancia 2 llama a TransferCodecCommands para enviar comandos X, Y y Z en el orden X-Y-Z, el controlador de bus podría ejecutar los comandos en el orden A-X-Y-B-Z-C.

Cuando los subprocesos del controlador de función independientes comparten el acceso al mismo conjunto de recursos de hardware, el orden relativo de comandos de diferentes subprocesos de controlador puede ser importante. Si es así, el controlador de función es responsable de sincronizar el uso compartido de los recursos entre los subprocesos.

Por ejemplo, la interfaz de hardware para escribir una secuencia de bytes de datos en un códec podría constar de un registro de índice y un registro de datos de 8 bits. En primer lugar, el controlador de función envía un comando de códec para cargar el índice inicial en el registro de índice. A continuación, el controlador envía un comando para escribir el primer byte de datos en el registro de datos. El registro de índice se incrementa después de cada escritura sucesiva en el registro de datos hasta que se complete la transferencia. Sin embargo, si dos subprocesos de controlador no pueden sincronizar correctamente su acceso al índice y los registros de datos, el orden relativo del acceso de registro individual por los dos subprocesos no está definido y el resultado probable es daños en los datos o una configuración de hardware no válida.

La rutina TransferCodecVerbs está disponible en ambas versiones de HD Audio DDI.