¿Por qué una muesca de 8 kHz en la entrada de micrófono de los auriculares de un Qualcomm WCD9330?

Aquí tengo un teléfono inteligente que usa un códec de audio Qualcomm WCD9330 IC. (Es un Galaxy Note 4). Mediante pruebas, descubrí que la entrada del micrófono de los auriculares muestra una muesca de aproximadamente 10 dB en su respuesta de frecuencia a aproximadamente 8 kHz y, además de preocuparme, también tengo curiosidad por saber cuáles son las posibles explicaciones de ingeniería para esto . , intencional o no. (En parte, también estoy tratando de averiguar si esta es una característica de este modelo o si el teléfono se dañó).

Rebobinando un poco, una vez que supe el IC involucrado, por supuesto agarré la especificación de su dispositivo (en realidad resultó ser para un dispositivo diferente pero muy similar; no puedo encontrar la especificación para el WCD9330, pero incluso el WCD9335 es similar). En este punto, todo lo que sabía era que el sonido grabado estaba amortiguado, como si hubiera pasado por un filtro de paso bajo. Los ADC tienen frecuencias de muestreo de 8, 16, 32, 48, 96 y 192 kHz, por lo que se me ocurrió, particularmente al ver el cuadro de respuesta de frecuencia de 16 kHz en la página 30, que tal vez el firmware del teléfono tiene la frecuencia de muestreo del hardware atascada en 16kHz (a pesar de que la aplicación de grabación pedía y estaba recibiendo 44,1kHz). Eventualmente decidí probar esta teoría físicamente.

Tengo acceso a un generador de barrido, un osciloscopio, etc., pero al no tenerlos a mano en el apartamento, opté por un enfoque más gueto. Creé un archivo WAV en mi PC con 28 tonos sinusoidales puros, 0dBFS, 500ms cada uno, en intervalos de 1kHz de 1kHz a 20kHz e intervalos de 500Hz en el área de interés donde supuse que estaba el roll-off. Acabo de conectar la salida de la interfaz de sonido de la PC directamente a los cables del micrófono en un conector TRRS de 3,5 mm. ¡Lo sé, terrible! Sin embargo, básicamente funcionó. Utilicé una aplicación de grabación de terceros en el teléfono para capturar PCM sin procesar de 44,1 kHz en un archivo WAV para que no haya ninguna interferencia por parte de un compresor de datos con pérdida.

Inicialmente, bajé completamente el control de volumen del software de la PC, no queriendo inundar la entrada de nivel de micrófono, pero finalmente descubrí que tenía que configurarlo bastante alto, alrededor del 75%, para obtener una señal que se acercara a 0dBFS en el grabando, y todavía no había recorte. Esto también puede ser parte del problema y es consistente con la observación de que las grabaciones de auriculares en este teléfono salen con un nivel de señal bastante bajo.

Saqué el archivo resultante a un programa de audio en la PC que puede hacer análisis de potencia RMS y FFT en regiones seleccionadas. El resultado no es exactamente lo que esperaba.

Bueno, primero que nada, estaba lleno de distorsión armónica. Lo culpo a una combinación de circuitos de entrada y salida bastante baratos y la horrible forma en que los conecté. Probablemente debería haber usado una resistencia de carga para igualar correctamente la impedancia, y también quizás usar un capacitor de bloqueo de CC. (Eso sí, en el último punto, no vi ningún sesgo de CC significativo en el resultado). Sin mencionar que no consideré si el teléfono alimenta el micrófono a través de esos mismos cables. Pero yo estaba ansioso y perezoso. Y los tonos principales aún eran más o menos claramente perceptibles en las FFT a pesar de tener también fuertes armónicos, así que pensé que los resultados todavía significarían algo, y parece que lo hicieron.

Cuando vi una caída hacia los 8kHz pensé, hey, tenía razón, está muestreando a 16kHz. Pero luego la curva de respuesta me desconcertó al volver a subir. Desde 14kHz hasta 20kHz, ¡la respuesta vuelve a ser máxima! Hasta 20kHz, la frecuencia principal es el pico más fuerte, por un claro margen; así que, según Nyquist, ¡el teléfono debe usar muestreo de 48, 96 o 192 kHz después de todo!

Ahí es donde  realmente empiezo a rascarme la cabeza. Es como si lo hubieran puesto a través de un filtro de muesca de 8 kHz... pero ¿por qué?  Aquí están los resultados:

(El gráfico azul se redondea al dB más cercano, por lo tanto, los golpes. Técnicamente, el RMS total probablemente debería haber sido más alto que el principal, pero estos se midieron con diferentes herramientas).

Estoy bastante seguro de que esto no es un artefacto de mi configuración de medición descuidada, porque esto refleja mucho lo que estaba viendo y escuchando en las grabaciones realizadas con los auriculares Samsung: sibilancias silenciadas y espectros de potencia que se hundieron alrededor de 8kHz. También confirmó mi observación de que exactamente los mismos auriculares en otro modelo de teléfono Samsung (Note II) no producían este sonido apagado; ahora está doblemente claro que es algo en el propio teléfono.

Desearía tener una segunda unidad idéntica para probar esto y descartar que algo realmente esté roto en el teléfono, pero no lo tengo. ¡Ni siquiera estoy seguro de cómo algo podría romperse de una manera tan específica!

Me cuesta entender qué explicaciones razonables, ya sean intencionales o no, podrían existir para esta muesca tan específica.

Tal vez sea una falla de diseño en el WCD9330, pero si me preguntan, una muesca de 10dB de dos octavas a 8kHz sería una falla tan vergonzosa que no puedo ver a una compañía con la mitad de reputación que Qualcomm lanzando tal cosa. ¡Es tan grande que pude caracterizarlo con el equivalente de ingeniería de un reloj de sol!

Ahora, soy consciente de que los ADC pueden producir fuertes artefactos de alias donde la entrada tiene componentes por encima de la frecuencia de Nyquist y, por lo tanto, deben tener un filtro de paso bajo analógico delante de ellos. Se me ocurrió que tal vez algún desarrollador de firmware se olvidó de establecer la frecuencia de corte de AAF de manera adecuada para la frecuencia de muestreo utilizada, pero esta explicación parece, bueno, un poco extraña, por dos razones. (i) Las frecuencias arbitrariamente altas pueden producir aliasing, por lo que un AAF debería ser un paso bajo, y sospecho que también son más simples que las muescas; y (ii) no puedo pensar en ningún caso de uso para configurar el AAF independientemente de la frecuencia de muestreo, por lo que supondría que el conjunto de chips uniría los dos a nivel de hardware, ¡aunque no lo he confirmado!

Otra dimensión de este problema es que el nivel de la señal del micrófono del auricular es realmente  bajo, y sospecho que esto probablemente se deba a una configuración del firmware (por lo tanto, una pregunta de Android SE). No sé si una ganancia o atenuación realmente baja en el amplificador de entrada podría afectar la respuesta de frecuencia de la entrada de esta manera. ¿Es eso posible o probable? (Si es así, ¿por qué?)

El WCD93xx también tiene un par de filtros IIR digitales de cinco etapas, que por supuesto podrían configurarse para producir la muesca, pero tengo la impresión de que los teléfonos normalmente usan el IIR para el efecto local, ¡no para silenciar el micrófono! XDD

No sé con certeza si el teléfono tiene algún circuito antes que el WCD9330, pero por lo que puedo deducir, probablemente no tenga mucho. Pude desenterrar el manual de servicio de un modelo estrechamente relacionado que es básicamente el mismo, excepto que se admiten las bandas UMTS y LTE. Es para el SM‑N910F en lugar del SM‑N910W8 que tengo aquí. Esto es lo que muestra para el circuito de auriculares:

El gran IC es, por supuesto, el WCD9330, lo mejor que puedo decir (¡al manual le falta el manifiesto de la pieza!) El manual no muestra dónde van EAROUT_L, EAROUT_R, HPH_REF, EAR_MIC_P y EAR_MIC_N, pero estoy más o menos asumiendo que van directamente (a través de un PCB separado) al conector de 3,5 mm. Esto también parece ser sugerido por la parte relevante del diagrama de "aplicación típica" del muy similar WCD9311:

Sin embargo, una cosa que me confunde es que HPH_REF y EAR_MIC_N se muestran como líneas separadas e incluso tienen resistencias separadas, pero de hecho los auriculares del teléfono usan un enchufe TRRS (cuatro conductores), en el que el anillo de tierra se comparte entre los auriculares y micrófono de auriculares Hmmmmm. Entonces, ¿qué está pasando allí?

De todos modos, mi pregunta principal es, ¿ cuáles son las explicaciones posibles/probables para esta muesca de 8kHz?

EDITAR:   No lo he probado objetivamente, pero de oído, esta pérdida de fidelidad no parece afectar las grabaciones realizadas con los micrófonos internos. Parece estar solo en el puerto de auriculares. Dada la explicación en la respuesta de Brian Drummond, esto hace que parezca un descuido del firmware.