nuevo - Cómo evitar que el iPhone 3GS filtre las frecuencias bajas(<150Hz)

iphone 3s

Question

Estoy desarrollando una aplicación para la detección de tono de bajos en el iPhone 3GS. Descubrí que no puedo obtener datos de sonido inferiores a 150Hz con RemoteIO. Sin embargo, el bajo puede generar tonos inferiores a 50 hz. Según el informe "iPhone 4 Headset Input Frequency Response", http://blog.faberacoustical.com/2010/iphone/iphone-4-audio-and-frequency-response-limitations/ Hay un marcado descenso por debajo de 150 Hz.

Aquí se muestra cómo configuro la AudioUnit.

// set audio unit
{
    // create AudioUnit
    {
        AudioComponentDescription desc;
        desc.componentType = kAudioUnitType_Output;
        desc.componentSubType = kAudioUnitSubType_RemoteIO;
        desc.componentManufacturer = kAudioUnitManufacturer_Apple;
        desc.componentFlags = 0;
        desc.componentFlagsMask = 0;

        AudioComponent comp = AudioComponentFindNext(NULL, &desc);
        OSAssert(AudioComponentInstanceNew(comp, &m_AudioUnit));
    }

    //enable input on the remote I/O unit (output is default enabled, but input is not)
    {
        UInt32 one = 1;
        OSAssert(AudioUnitSetProperty(m_AudioUnit, kAudioOutputUnitProperty_EnableIO,
                                      kAudioUnitScope_Input, 1, &one, sizeof(one)));
    }

    //set render callback function
    {
        AURenderCallbackStruct callbackInfo;
        callbackInfo.inputProc=staticPerformThru;
        callbackInfo.inputProcRefCon=this;

        OSAssert(AudioUnitSetProperty(m_AudioUnit,
                                      kAudioUnitProperty_SetRenderCallback,
                                      kAudioUnitScope_Input, 
                                      0, &callbackInfo, sizeof(callbackInfo)));

    }

    //set in/output format
    {
        CAStreamBasicDescription outFormat;
        outFormat.SetAUCanonical(channels, false);
        outFormat.mSampleRate = sampleRate;
        OSAssert(AudioUnitSetProperty(m_AudioUnit, kAudioUnitProperty_StreamFormat, kAudioUnitScope_Input, 0, &outFormat, sizeof(outFormat)));
        OSAssert(AudioUnitSetProperty(m_AudioUnit, kAudioUnitProperty_StreamFormat, kAudioUnitScope_Output, 1, &outFormat, sizeof(outFormat)));
    }

    //Initialize remote I/O unit
    OSStatus r=AudioUnitInitialize(m_AudioUnit);
    OSAssert(r);
}
//start audio output
OSAssert(AudioOutputUnitStart(m_AudioUnit));

Esta es la función de devolución de llamada.

OSStatus AudioThruWorker::staticPerformThru(
                                           void                     *inRefCon, 
                                           AudioUnitRenderActionFlags   *ioActionFlags, 
                                           const AudioTimeStamp         *inTimeStamp, 
                                           UInt32                       inBusNumber, 
                                           UInt32                       inNumberFrames, 
                                           AudioBufferList          *ioData)
{

    AudioUnitRender(((AudioThruWorker*)inRefCon)->m_AudioUnit, ioActionFlags, inTimeStamp, 1, inNumberFrames, ioData);

    //Detect pitch here...

    return 0;
}

Para identificar la causa raíz,

1. Modifiqué mi función de devolución de llamada para simplemente pasar por alto los datos de entrada a la salida.
2. Usa Mac para generar ruido blanco.
3. Use iRig para redirigir la señal de los auriculares de Mac a iPhone3Gs que ejecuta mi programa.
4. Usa iRig para redirigir la salida del iPhone a Mac.
5. Registrar datos en Mac. El espectro de datos de salida se muestra en la figura de abajo.

Se puede ver la caída brusca a 150Hz.

Para identificar si el problema está en el lado de entrada o en el de salida, cambié la función de devolución de llamada para ignorar los datos de entrada y emitir un ruido blanco. Aquí está el resultado. Muy claro que NO hay caída a 150 Hz. Por lo tanto, el problema debe en el lado de entrada.

Pensé que esto es una limitación de hardware. SIN EMBARGO, probé la aplicación "Amplitube" en el mismo dispositivo, desactivé todos los efectos, ingresé el ruido blanco y analicé la salida. No tiene caída a 150Hz. Aquí está el resultado. Esto significa que el problema de entrega NO es una limitación de hardware. Debe haber alguna forma en que el software pueda hacer para evitar el problema.

¿Alguien sabe el secreto?

Gracias.

Answer 1

¿Puedo recomendar que vuelva a hacer esta pregunta con un título apropiado? (Tal vez algo así como ''cómo evitar que el iPhone filtre las frecuencias bajas (<150Hz)'') y que contenga toda la información necesaria, también se pegue en esa imagen, es una Parte importante de la pregunta. Es muy fácil incrustar una imagen.

ni siquiera has dicho qué es lo que estás tratando de lograr.

Parece que eres nuevo en el sitio y parece una pregunta muy interesante.

Pero no estás siendo del todo claro.

En primer lugar, este es un problema con la grabación o la reproducción o ambos?

Ahora, ¿qué estás haciendo exactamente en tu experimento? Método científico occidental ... extiéndelo.

¿Está generando estática en su devolución de llamada de render remoto? No, suena como si estuvieras usando pasatiempo, dices que estás poniendo ruido blanco en el iPhone. ¿Cómo estás configurando tu unidad de audio?

así que el ruido blanco va directamente al iPhone, y ... ahora, ¿qué representa esa gráfica? FFT / ¿Análisis espectral de la salida del iPhone? como estas haciendo eso ¿Está introduciendo esto en algún software de gráficos OSX que puede recibir información de la línea?

También, podrías hacer con reducirlo. Si de hecho está pasando el sonido a través del dispositivo, no tiene idea de dónde está ocurriendo el filtrado. por lo que sabe, puede haber filtrado en el dispositivo que genera el ruido blanco, así como en el dispositivo que grafica la salida del iPhone.

¿qué hay de generar su ruido blanco desde el interior de la E / S remota de devolución de llamada de procesamiento?

y luego generándolo externamente y analizando los datos que llegan desde esta devolución de llamada, podría realizar una FFT.

De todos modos, para la entrada, ¿no harías mejor para alimentar ondas sinusoidales de diferentes frecuencias?

Answer 2

Bueno, es un teléfono, un dispositivo optimizado para el habla supuestamente. Y los dispositivos optimizados para el habla generalmente tienen algún tipo de filtro de corte LF para evitar el ruido y la distorsión.

Este filtro probablemente se encuentra en el lado de entrada del teléfono, es por eso que puede generar y generar un rango más amplio de frecuencias, es probable que sea un filtro de hardware / elemento discreto, ya que son fáciles de crear utilizando solo unos pocos componentes y funcionarán En tiempo real sin ningún tipo de esfuerzo en el procesamiento.

No creo que tenga sentido cortar los bajos en el software, sé que no lo haría, bueno, para una aplicación DAW puedes hacerlo, pero para un dispositivo optimizado para filtrar los bajos ...

¿Considerado el hecho de que los desarrolladores de amplitube podrían haber sido conscientes de este problema y agregar un impulso extra bajo para intentar compensar la limitación de hardware?

Por otro lado, es muy posible que se puedan elegir diferentes "rutas de señal" según el escenario de uso, tal vez haya algunas aplicaciones de control de sistema operativo que puedan tocarse y decir "hey, no soy voz, no corte mis mínimos" - Si es así, esta característica debería estar en algún lugar en la descripción de la API.

Answer 3

Interesante pregunta. No conozco ningún filtro de este tipo ... puede establecer una devolución de llamada de entrada en la unidad de E / S remota y obtener un flujo de flotadores.

No he visto ninguna documentación de que este flujo flotante de alguna manera ya esté procesado.

He escrito un detector de tono que toma notas con éxito en el extremo inferior de mi rango de canto (~ 80Hz)

Tal vez el código postal - ¿qué estás haciendo dentro de esta devolución de llamada?