Descripción general del audio¶

Resumen¶

Esta guía describe el subsistema de audio local de los dispositivos SF32: la cadena de códec, DMA y middleware que interviene en la entrada de micrófono, la salida a altavoz o línea y la reproducción o grabación en el dispositivo. Se centra en decisiones prácticas sobre interfaces, búferes, Audio Server, códecs y consumo energético.

El audio Bluetooth (A2DP y LE Audio) es un tema relacionado, pero distinto, que se trata en el Resumen de Bluetooth. Allí se explica la transmisión inalámbrica; aquí, lo que ocurre una vez que las muestras llegan al chip: captura, mezcla, decodificación y activación de la ruta física de audio.

Consulte esta página al elegir los micrófonos, códecs y estrategias de búfer de un producto y al evaluar su consumo; no se limite a comprobar que una demostración se reproduce una vez. Está dirigida a quienes deben integrar un sistema de audio fiable dentro de las restricciones de Bluetooth, pantalla, almacenamiento y batería.

Defina los requisitos de audio del producto¶

Antes de elegir interfaces o tamaños de búfer, precise lo que el producto necesita:

• ¿Solo reproducción, solo grabación, o ambas simultáneamente (dúplex completo)?
• ¿Cuántos micrófonos se necesitan y de qué tipo: analógicos (AMIC) o digitales (DMIC)?
• ¿Qué formatos de reproducción local se necesitan: PCM sin procesar, MP3, Opus u otro códec?
• ¿Se necesita audio Bluetooth (Classic o LE Audio) en paralelo con el audio local?
• ¿Se requiere activación por voz o escucha continua? ¿Qué presupuesto energético está disponible?
• ¿Qué requisitos debe cumplir la etapa de salida para el altavoz o la salida de línea? ¿Se conectará la salida a un amplificador o códec externo?
• ¿Qué latencia puede tolerar el producto? Las llamadas de voz y la monitorización en tiempo real tienen requisitos mucho más estrictos que los tonos de notificación.

Las respuestas determinan la interfaz (I2S, PDM o ADC/DAC), la configuración del códec y qué partes de la ruta de audio deben permanecer activas.

Ruta de señal de audio del SF32¶

La captura y la reproducción siguen rutas distintas. El diagrama muestra rutas habituales; su disponibilidad y uso simultáneo dependen del modelo, el encapsulado, la placa y la configuración del SDK.

flowchart TB
    subgraph CAP["Captura"]
        direction TB
        A["Micrófono analógico"] --> B["AUDCODEC ADC"] --> C["AUDPRC"] --> M["Búferes DMA / aplicación"]
        D["Micrófonos PDM"] --> E["Conversión PDM a PCM"] --> M
        F["Entrada I2S"] --> C
    end
    subgraph PLAY["Reproducción"]
        direction TB
        N["Búferes DMA / aplicación"] --> G["AUDPRC"] --> H["AUDCODEC DAC"] --> J["Amplificador externo"] --> S["Altavoz"]
        G --> K["Salida I2S"] --> L["Códec / amplificador externo"] --> S
    end
    M ~~~ N

AUDCODEC realiza la conversión analógico-digital y digital-analógica. AUDPRC procesa la mezcla, la ganancia y la conversión de frecuencia de muestreo en las rutas compatibles. Los micrófonos PDM utilizan el bloque PDM para obtener PCM; no pasan por el ADC analógico. I2S ofrece una conexión digital con dispositivos externos. Una interfaz PDM admite hasta dos micrófonos compatibles mediante la selección de canal izquierdo/derecho; dos interfaces pueden admitir hasta cuatro, según los pines disponibles y el soporte del controlador.

Audio Server es software que gestiona flujos y sesiones, no un convertidor físico entre el micrófono y el altavoz. La aplicación suele utilizar sus API y los controladores correspondientes; las pruebas directas del controlador o HAL son útiles durante la puesta en marcha. Seleccione primero las rutas reales de captura y reproducción y compruebe relojes, formatos de muestra, solicitudes DMA y requisitos de accionamiento de la salida. No dé por hecho que el DAC integrado puede accionar el altavoz elegido sin un amplificador externo.

Estas rutas se describen en la guía del controlador AUDPRC/AUDCODEC y la guía HAL de PDM.

Micrófonos e interfaces digitales¶

AMIC y DMIC son tipos de micrófono; PDM e I2S son interfaces digitales. Un micrófono digital puede usar PDM o I2S. No confunda el número de micrófonos con el de canales o interfaces.

Los arreglos mixtos analógicos/digitales requieren rutas simultáneas compatibles y muestras sincronizadas. La formación de haces también necesita una distribución adecuada, calibración y un algoritmo; no basta con conectar varios micrófonos.

Parta de un ejemplo de audio verificado¶

Antes de diseñar el comportamiento de la aplicación, elija y valide el ejemplo de SiFli-SDK que más se aproxime a su caso. Ejemplos de audio del SDK agrupa los ejemplos oficiales de PDM, captura analógica, grabación y reproducción, música local, tarjeta SD, FLAC, Opus y mezcla según la tarea de ingeniería que ilustran. También indica qué aspectos de la placa, la multiplexación de pines, el almacenamiento y la configuración deben comprobarse antes de adaptar un ejemplo al producto.

Elija el dispositivo SF32 adecuado¶

La capacidad de audio varía según la familia. Consulte la hoja de datos del modelo concreto; la tabla ofrece una orientación inicial:

Antes de elegir, confirme el modelo, los pines del encapsulado, su multiplexación y las rutas simultáneas. Una interfaz PDM puede admitir dos micrófonos compatibles; los canales ADC, los canales de micrófono y las interfaces digitales son recursos distintos. Las funciones I2S dependen de la instancia: en SF32LB58x, I2S1 solo admite recepción (RX), mientras que I2S2 e I2S3 admiten recepción y transmisión (RX/TX). Para recibir por I2S2, también hay que habilitar su lado TX como fuente de reloj. Consulte la guía HAL de I2S de SiFli para conocer los detalles de cada instancia y la página Familia SF32 para otros factores de selección.

Fuentes: DS5201, DS5501, Table 0-1, DS5601, DS5801, registros AUDCODEC de SF32LB57x (ADC_CH0/1, DAC_CH0), instancias PDM/I2S de SF32LB57x, notas de SiFli SDK v2.5.1 (configuración PDM de 4 micrófonos en 57x), ejemplo PDM de SiFli SDK (placa 57x, PDM1, canales estéreo).

Patrones de sesión de audio¶

La mayoría de los productos se ajusta a unos pocos patrones de sesión habituales. Elija el que más se aproxime y valídelo de forma explícita:

Defina para cada sesión cómo se inicia, cómo funciona en régimen estable, cómo se recupera de un búfer vacío o desbordado y cómo se cierra. Los problemas de audio suelen aparecer durante las transiciones, no en el bucle de reproducción estable.

Presupuesto de búfer y latencia¶

La duración de audio del búfer se calcula en tramas de muestras: cada trama contiene una muestra de cada canal.

interleaved frames = buffer bytes / (channels * stored bytes per sample)
planar frames per channel = channel buffer bytes / stored bytes per sample
buffer duration (s) = frames / sample rate (Hz)

A 48 kHz, 480 tramas representan 10 ms. En estéreo intercalado, equivalen a 960 muestras individuales; 480 muestras individuales representan solo 5 ms. Para convertir bytes a tramas, utilice los bytes realmente almacenados por muestra, incluido el relleno. Si cada canal tiene su propio búfer, cuente las tramas de cada canal sin sumar ambas longitudes.

Esta es la duración del audio contenido en el búfer, no necesariamente la latencia de extremo a extremo. El doble búfer permite que DMA use una región mientras el software procesa otra. La latencia depende de los datos pendientes en las colas y de los callbacks que notifican la mitad o la finalización de la transferencia, no solo de tener dos búferes. Presupueste y mida conjuntamente los retrasos de captura, procesamiento, transporte, reproducción y planificación.

Fundamentos de reproducción y grabación¶

Ya sea que active un altavoz o capture un micrófono, se aplican los mismos fundamentos:

• Dimensionamiento del búfer: los bloques pequeños pueden reducir la latencia asociada al procesamiento por bloques, pero aumentan la sobrecarga de interrupciones/DMA; los bloques grandes ofrecen más margen de planificación y usan más memoria. La latencia aumenta cuando hay más audio esperando antes de procesarse o reproducirse, no por el mero hecho de reservar más capacidad de búfer.
• Transferencia por DMA: utilice DMA sincronizado por hardware para transferir las muestras del periférico. El software puede copiar o procesar bloques en memoria; evite sondeos de CPU o bucles por muestra que deban atender al periférico en tiempo real.
• Planificación de tasa de muestreo y formato: decida la tasa de muestreo (por ejemplo, 16 kHz para voz, 44,1/48 kHz para música) y la profundidad de bits de antemano; convertir formatos en tiempo de ejecución cuesta CPU y memoria.
• Doble búfer: mientras DMA transfiere una región, el software llena o procesa la otra. Termine antes de que vuelva a necesitarse esa región; dos búferes por sí solos no evitan agotamientos ni desbordamientos.

Para los búferes cacheables compartidos con DMA, defina quién puede acceder a cada región y siga las reglas de alineación y mantenimiento de líneas de caché del SDK. Limpie los datos de reproducción escritos por la CPU antes de que DMA los lea. Prepare el destino antes de que DMA escriba la captura e invalide la región completada antes de que la CPU la lea, según la política de caché del dispositivo. No modifique ni reutilice una región usada por DMA hasta que el callback de finalización lo permita; no mezcle datos ajenos en las líneas de caché afectadas.

Códecs y compresión¶

Distinga el códec de audio por hardware (conversión ADC/DAC) del códec de compresión (como MP3 u Opus). PCM sin comprimir no necesita un decodificador de compresión. Para una señal equivalente, la compresión con pérdida suele reducir el tamaño almacenado y el ancho de banda de lectura, pero deben medirse el tiempo de CPU, los búferes de trabajo y la energía del decodificador; no garantiza menos memoria durante la ejecución.

El SDK ofrece ejemplos de música local, MP3 en tarjeta SD, Opus, grabación y ADC/DAC duales. El ejemplo de dos canales requiere un dispositivo y una placa que los expongan; no significa que todos los SF32 tengan dos ADC/DAC. Parta de la configuración compatible y mida el costo de decodificación en el dispositivo real.

Audio local y audio Bluetooth¶

Distinga conceptualmente ambas rutas, aunque puedan funcionar al mismo tiempo:

• Audio local (esta guía): AUDCODEC/AUDPRC, micrófonos, altavoz/línea de salida, reproducción y grabación en el dispositivo.
• Audio Bluetooth (Resumen de Bluetooth): A2DP/AVRCP/HFP para Classic Bluetooth, o LE Audio unicast/broadcast cuando el dispositivo, la pila y el SDK admitan los roles necesarios. Una radio compatible con BLE no garantiza LE Audio.

En muchos productos se combinan ambas rutas: por ejemplo, se captura audio con un micrófono local y se transmite por Bluetooth, o se recibe audio Bluetooth y se mezcla con un sonido de notificación local mediante Audio Server. Si ambas funcionan a la vez, defina quién gestiona los búferes y cómo se mezclan las señales.

Lista de comprobación del diseño de audio en la placa¶

El firmware no puede compensar por completo un diseño analógico deficiente. Revise estos puntos al diseñar el esquemático y la PCB:

En productos que combinan RF y audio analógico, compruebe el ruido con Bluetooth activo, la pantalla en funcionamiento, el cargador conectado y la carcasa final montada.

Consumo energético del audio¶

Mida por separado la alimentación de los micrófonos, los convertidores, el procesamiento digital, los accesos a memoria y el amplificador; después mida la sesión completa. La contribución de cada parte depende del hardware, la carga de trabajo y el ciclo de actividad de escucha y reproducción.

• Entre sesiones, detenga las rutas que no se utilicen siguiendo la secuencia exigida por el componente y el controlador. Compruebe el silenciamiento y apagado del amplificador, los relojes, la alimentación y los estados GPIO para evitar chasquidos, alimentación inversa y fugas por las interfaces.
• Para la activación por voz con escucha continua, mantenga la captura necesaria y elija la estrategia de procesamiento de menor consumo que esté admitida. No apague la ruta de la que depende la detección y mantenga ligero su modelo. Consulte el Resumen de IA.
• Agrupe el procesamiento sin superar los límites de latencia ni los plazos de los búferes. DMA transfiere las muestras, pero los bloques completados aún deben procesarse a tiempo; reducir los despertares de CPU no debe causar desbordamientos ni agotamientos del búfer.
• Coordine los tiempos de audio con Bluetooth y la pantalla. Consulte el Resumen del diseño de bajo consumo y Resumen de Bluetooth: coexistencia.

Matriz de validación de audio¶

Repita las mismas pruebas de audio después de modificar el códec, Bluetooth, la pantalla, la alimentación o los relojes:

Conserve un archivo WAV/PCM de referencia validado y una grabación validada de la placa de evaluación. Facilitan mucho más la detección de regresiones que la escucha subjetiva por sí sola.

Diagnóstico de problemas de audio¶

Errores comunes¶

• Atender cada muestra del periférico mediante sondeo de CPU en lugar de DMA sincronizado por hardware.
• Usar una estrategia de búfer insuficiente o mal gestionada que incumpla los plazos de DMA; recurrir al doble búfer cuando el controlador lo admita y resulte adecuado.
• Elegir tipos y cantidades de micrófono sin comprobar las instancias PDM/I2S, los pines disponibles y las rutas simultáneas.
• Tratar el audio Bluetooth y el audio local como completamente independientes cuando se ejecutarán concurrentemente en el producto real.
• Ignorar la coherencia de caché y las reglas de propiedad de los búferes compartidos entre DMA y CPU.
• Mantener activas rutas no utilizadas entre sesiones, o desactivar una captura necesaria para la escucha continua.
• Comprometerse con un formato comprimido antes de confirmar que el costo de decodificación se ajusta al presupuesto de energía y CPU.

Lista de comprobación de puesta en marcha¶

• Confirme para el dispositivo y la placa concretos los tipos y canales de micrófono, las instancias PDM/I2S, los pines disponibles y las rutas simultáneas admitidas.
• Defina la frecuencia de muestreo, el tamaño almacenado por muestra, la disposición de canales y los tamaños de búfer de captura y reproducción.
• Ponga en marcha la captura elegida mediante ADC/AUDPRC, PDM o I2S y la reproducción mediante DAC o I2S; pruebe cada dirección antes del funcionamiento dúplex completo.
• Una vez que funcionen las rutas básicas, integre las sesiones compatibles con Audio Server y sus controladores; conserve pruebas directas de HAL para el diagnóstico.
• Elija el formato de audio (PCM/MP3/Opus) y mida, cuando haya decodificación, su carga de CPU, memoria y energía.
• Valide la propiedad y alineación de los búferes DMA y las operaciones de limpieza e invalidación de caché.
• Pruebe el audio local y Bluetooth simultáneos si el producto utiliza ambos.
• Mida el consumo activo y en reposo; verifique las secuencias de apagado y reinicio, los estados de los pines y la captura que deba seguir activa para la escucha continua.

Puntos clave¶

• Seleccione la ruta física: el audio analógico usa AUDCODEC, la captura PDM usa el bloque PDM y el audio digital externo usa I2S. Gestione las sesiones compatibles con Audio Server y los controladores; no trate todas las rutas como una misma cadena de códec.
• Elija los tipos de micrófono y las rutas PDM/I2S según las capacidades del dispositivo concreto y la disposición de micrófonos, sin trasladar supuestos de otro chip.
• Use transferencias DMA sincronizadas por hardware y una capacidad de búfer suficiente. El doble búfer es una solución habitual cuando el controlador lo admite, pero aun así hay que cumplir los plazos de los callbacks y de reutilización del búfer.
• El audio local y el Bluetooth son subsistemas distintos que a menudo deben funcionar a la vez; planifique explícitamente la mezcla y la gestión de los búferes.
• Trate el consumo de audio como el de Bluetooth y la IA: reduzca el tiempo activo, evite despertares innecesarios de la CPU y mida sesiones reales, no solo la reproducción en régimen estable.

Última actualización: 2026-10-12