El códec AC'97 parece dominar el mundo de la E/S de audio digital, pero lo extraño es que no tiene interrupciones ni búfer, por lo que es difícil interactuar con un controlador, que tiene otras actividades. El AC97 exige sondearlo periódicamente (44k veces por segundo), verificando el tiempo para comunicar una siguiente muestra. Esta no es la forma habitual de comunicarse por lo general. Por lo general, la CPU llena un búfer y recibe una notificación cuando se completa la operación o espera explícitamente el resultado si no tiene nada más que hacer. Tal "procesamiento por lotes" es más eficiente porque, en primer lugar, enviar ráfagas es más eficiente que hacer un elemento a la vez y, en segundo lugar, reduce el cambio de contexto n veces, lo que también optimiza los recursos computacionales en consecuencia. Pero, necesitas un FIFO para eso. Lo que hay de bueno en esto, en muestra a tiempo, terrible diseño de AC97 y por qué a nadie le importa? Veo que Xilinx lo arregla con la placa de demostración ML507 (veo FIFO en el controlador AC97 presentado allí) pero tengo la placa V5 Genesys de Digilent cuyo controlador no proporciona ningún FIFO. De modo que Microblaze debe comunicar una muestra cada 1/44100 de segundo. ¿Es eficiente? ¿Cómo se supone que debes controlarlo?
La parte de enlace de CA de la especificación AC97 define la interfaz de cinco hilos entre el códec y un controlador. Esto no es solo una interfaz de datos, sino también una interfaz de tiempo. Esta distinción puede no parecer importante en un pequeño sistema integrado con solo un códec, pero se vuelve crucial en un sistema más grande, como una mesa de mezclas digital de 96 canales. En este tipo de sistema, todas las interfaces de audio deben funcionar exactamente con la misma frecuencia de muestreo y alineación de fase, y el estándar AC-link está diseñado para admitir eso.
Como han insinuado las otras respuestas, es responsabilidad del dispositivo en el otro extremo del enlace, el "controlador", que podría ser un ASIC dedicado, parte de un FPGA o un microcontrolador, administrar tanto el tiempo de la códecs en el sistema según sea necesario, así como el movimiento de datos de un dominio de tiempo a otro con el uso de FIFO o búfer adecuados.
Los códecs de audio son dispositivos en tiempo real. Esperan que les proporcione (o lea de ellos) muestras en cada período de muestra. El diseño de un códec de audio simple sería mucho más complejo si les trasladara esa responsabilidad. Más fácil para ti, más difícil y más caro para el códec.
Una posible solución sería usar un motor/canal DMA. Así que coloque sus bits de audio pcm en alguna ubicación contigua en la memoria y apunte el motor DMA a esos bits y su interfaz AC97. Haga que la frecuencia de escritura de dma sea de 44.1K y luego déjelo funcionar. Puede hacer lo contrario para obtener audio.
Usted también podría hacer este bloque usted mismo, simplemente teniendo su propio fifo hecho de memoria fpga interna.
Aquí hay un núcleo de controlador AC97 en OpenCores con soporte dma externo http://opencores.org/project,ac97
Probablemente podría diseñar el FPGA para que contenga un MicroBklaze para sondear y escribir datos en el subsistema AC97. Sin embargo, realmente sugeriría dar un paso atrás y pensar de dónde provienen realmente los datos de origen. En la mayoría de los casos, querrá diseñar un widget de hardware, en lógica FPGA, para tomar el flujo de datos de origen y enviarlo al subsistema AC97 sobre la marcha a la velocidad correcta. Si la velocidad de datos es correcta pero puede haber algunas variaciones espurias en el flujo de datos, entonces tendría mucho sentido insertar búferes elásticos FIFO como parte del widget de hardware. Los FPGA tienen buenos módulos para crear FIFO
Oli Glaser
yippie
valle
yippie
valle