Comandos codec síncronos e assíncronos

A rotina TransferCodecVerbs permite que os drivers de função enviem comandos para codecs de áudio e modem conectados a um controlador de áudio HD. Os comandos codec podem ser executados de forma síncrona ou assíncrona:

• Se uma chamada para TransferCodecVerbs enviar uma lista de comandos a serem processados de forma síncrona, a rotina retornará somente depois que o codec ou codecs tiver processado todos os comandos.

• Se uma chamada para TransferCodecVerbs enviar uma lista de comandos a serem processados de forma assíncrona, a rotina retornará assim que o driver do barramento de áudio HD adicionar os comandos à sua fila de comandos interna, sem esperar que o codec ou codecs processem os comandos. Depois que os codecs processarem os comandos, o driver de barramento notificará o driver de função chamando uma rotina de retorno de chamada.

Dependendo da natureza dos comandos de codec que ele envia, o driver de função usa uma ou mais das seguintes técnicas para recuperar respostas de um codec:

• Se o driver de função precisar ter a resposta do codec antes de poder executar qualquer processamento adicional, ele usará o modo síncrono.

• Se o driver de função não precisar aguardar a conclusão dos comandos codec, para ver as respostas do codec e saber quando os comandos são concluídos, ele usa o modo assíncrono, ignora a rotina de retorno de chamada (exceto para liberar o armazenamento para os comandos codec) e descarta ou ignora as respostas aos comandos do codec.

• Se o driver de função precisar saber quando os comandos do codec forem concluídos, mas não precisar ver as respostas, ele usará o modo assíncrono e dependerá da rotina de retorno de chamada para notificação. No entanto, ele descarta ou ignora as respostas aos comandos codec. A rotina de retorno de chamada pode usar um evento KS (streaming de kernel) para enviar a notificação para o main parte do driver.

• Se o driver de função precisar saber quando os comandos do codec são concluídos e quais são as respostas, mas deve retomar o processamento imediatamente em vez de aguardar a conclusão dos comandos, ele usa o modo assíncrono e evita ler as respostas até receber a rotina de retorno de chamada. A rotina de retorno de chamada ou a parte main do driver podem inspecionar as respostas.

TransferCodecVerbs retornará STATUS_SUCCESS se tiver êxito em adicionar a lista de comandos à fila de comandos interna do driver de barramento. Embora a chamada seja bem-sucedida, as respostas ainda podem ser inválidas. O driver de função deve marcar os bits status nas respostas do codec para determinar se eles são válidos. Essa regra se aplica ao modo síncrono e assíncrono.

A causa de uma resposta inválida provavelmente será uma das seguintes:

• O comando não atingiu o codec.

• O codec respondeu, mas a resposta foi perdida quando ocorreu um estouro de FIFO (primeiro a entrar e sair) no RIRB.

O último problema indica que o FIFO rirb é de tamanho insuficiente.

Cada resposta codec contém um sinalizador IsValid para indicar se a resposta é válida e um sinalizador HasFifoOverrun para indicar se ocorreu um estouro de FIFO RIRB. Se IsValid = 0, indicando que uma resposta é inválida, o sinalizador HasFifoOverrun ajuda a identificar a origem da falha:

• Se HasFifoOverrun = 0, o codec não respondeu dentro do intervalo de tempo necessário. A causa provável é que o comando nunca chegou ao codec.

• Se HasFifoOverrun = 1, o comando provavelmente atingiu o codec, mas a resposta foi perdida devido a um estouro de FIFO.

Durante uma chamada para TransferCodecCommands, o chamador fornece um ponteiro para uma matriz de estruturas HDAUDIO_CODEC_TRANSFER . Cada estrutura contém um comando e fornece espaço para uma resposta. O driver de barramento sempre grava cada resposta na estrutura que contém o comando que disparou a resposta.

Para cada chamada para TransferCodecCommands, a ordem na qual os comandos são processados é determinada pela ordem dos comandos na matriz. O processamento do primeiro comando na matriz sempre é concluído antes do início do segundo comando e assim por diante.

Além disso, se um cliente fizer uma chamada assíncrona para TransferCodecCommands e chamar TransferCodecCommands uma segunda vez sem aguardar a rotina de retorno de chamada da primeira chamada, a ordem relativa na qual os dois grupos de comandos das duas chamadas são processados é definida pela ordem em que o cliente enviou os dois grupos de comandos. Assim, o driver de barramento processa todos os comandos da primeira chamada antes de começar a processar os comandos da segunda chamada.

No entanto, a ordem relativa dos comandos enviados por duas instâncias de driver de função diferentes é indefinida. (Cada instância tem seu próprio objeto de dispositivo físico.) Por exemplo, se a instância 1 chamar TransferCodecCommands para enviar os comandos A, B e C na ordem A-B-C e a instância 2 chamar TransferCodecCommands para enviar os comandos X, Y e Z na ordem X-Y-Z, o driver de barramento poderá executar os comandos na ordem A-X-Y-B-Z-C.

Quando threads de driver de função separados compartilham acesso ao mesmo conjunto de recursos de hardware, a ordem relativa de comandos de threads de driver diferentes pode ser importante. Nesse caso, o driver de função é responsável por sincronizar o compartilhamento dos recursos entre os threads.

Por exemplo, a interface de hardware para gravar uma sequência de bytes de dados em um codec pode consistir em um registro de índice e um registro de dados de 8 bits. Primeiro, o driver de função envia um comando codec para carregar o índice inicial no registro de índice. Em seguida, o driver envia um comando para gravar o primeiro byte de dados no registro de dados. O registro de índice incrementa após cada gravação sucessiva no registro de dados até que a transferência seja concluída. No entanto, se dois threads de driver não sincronizarem corretamente o acesso do índice e dos registros de dados, a ordem relativa do acesso de registro individual pelos dois threads será indefinida e o resultado provável será corrupção de dados ou uma configuração de hardware inválida.

A rotina TransferCodecVerbs está disponível em ambas as versões da DDI de áudio HD.