Wie verhindert man, dass das iPhone 3GS tiefe Frequenzen ( < 150Hz ) filtert?

Question

Ich entwickle eine Bassgitarre Tonhöhenerkennung App auf iphone 3GS. Ich habe festgestellt, dass ich mit RemoteIO keine Tondaten unter 150 Hz erhalten kann. Die Bassgitarre kann jedoch Töne unter 50 Hz erzeugen. Laut dem Bericht "iPhone 4 Headset Input Frequency Response", http://blog.faberacoustical.com/2010/iphone/iphone-4-audio-and-frequency-response-limitations/ Unterhalb von 150 Hz gibt es einen starken Abfall.

Hier wird gezeigt, wie ich die AudioUnit eingerichtet habe.

// 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));

Dies ist die Rückruffunktion.

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;
}

Ermittlung der Grundursache,

1. Ich habe meine Callback-Funktion so geändert, dass sie nur die Eingabedaten zur Ausgabe umleitet.
2. Mac zur Erzeugung von weißem Rauschen verwenden
3. Verwenden Sie iRig, um das Signal vom Mac-Headset auf das iPhone3Gs umzuleiten, auf dem mein Programm läuft.
4. Verwenden Sie iRig, um die Ausgabe des iPhone zurück auf den Mac zu leiten.
5. Daten auf dem Mac aufzeichnen. Das Spektrum der Ausgangsdaten ist in der folgenden Abbildung dargestellt.

Sie können den starken Abfall bei 150 Hz sehen.

Um festzustellen, ob das Problem auf der Eingabe- oder der Ausgabeseite liegt, habe ich die Callback-Funktion so geändert, dass sie die Eingabedaten ignoriert und ein weißes Rauschen ausgibt. Hier ist das Ergebnis. Ganz klar, dass es bei 150 Hz KEINEN Abfall gibt. Daher sollte das Problem auf der Eingangsseite liegen.

Ich dachte, dies sei eine Hardware-Beschränkung. JEDOCH habe ich die App "Amplitube" auf demselben Gerät ausprobiert, alle Effekte ausgeschaltet, weißes Rauschen eingegeben und die Ausgabe analysiert. Es hat KEINEN Abfall bei 150Hz. Hier ist das Ergebnis. Das bedeutet, dass das Drop-off-Problem NICHT auf die Hardware zurückzuführen ist. Es muss einen Weg geben, wie die Software das Problem umgehen kann.

Kennt jemand das Geheimnis?

Danke.

Answer 1

Nun, es ist ein Telefon, ein Gerät, das angeblich für Sprache optimiert ist. Und Geräte, die für Sprache optimiert sind, haben normalerweise eine Art NF-Sperrfilter, um Rumpeln und Verzerrungen zu vermeiden.

Dieser Filter befindet sich wahrscheinlich auf der Eingangsseite des Telefons, weshalb Sie einen breiteren Frequenzbereich erzeugen und ausgeben können. Wahrscheinlich handelt es sich um einen Hardware-/Diskretfilter, da diese mit nur wenigen Bauteilen einfach zu erstellen sind und in Echtzeit funktionieren, ohne die Verarbeitung zu belasten.

Ich glaube nicht, dass es sinnvoll ist, die Bässe in der Software abzuschneiden. Ich weiß, dass ich es nicht tun würde, für eine DAW-Anwendung kann man es tun, aber für ein Gerät, das dafür optimiert ist, Bässe zu filtern...

Ist es möglich, dass die Entwickler von Amplitube sich dieses Problems bewusst waren und einen zusätzlichen niedrigen Boost hinzugefügt haben, um die Hardwarebeschränkung auszugleichen?

Andererseits könnte es durchaus möglich sein, je nach Nutzungsszenario unterschiedliche "Signalpfade" zu wählen, vielleicht gibt es einen os-Handle, mit dem Apps sagen können: "Hey, ich bin nicht die Stimme, schneide meine Bässe nicht ab" - falls ja, sollte diese Funktion irgendwo in der API-Beschreibung stehen.

Answer 2

Eine interessante Frage. Mir ist kein solcher Filter bekannt... Sie können einen Eingabe-Callback auf der Remote-IO-Einheit setzen und einen Strom von Floats erhalten.

Ich habe keine Unterlagen gesehen, aus denen hervorgeht, dass dieser Float-Stream bereits in irgendeiner Weise verarbeitet wird.

Ich habe einen Tonhöhen-Detektor geschrieben, der erfolgreich Noten am unteren Ende meines Gesangsbereichs (~80Hz) aufnimmt

Vielleicht Code posten - was tun Sie innerhalb dieses Rückrufs?

Answer 3

Ich empfehle Ihnen, diese Frage erneut zu stellen, mit einem passenden Titel (vielleicht so etwas wie "Wie kann man verhindern, dass das iPhone niedrige Frequenzen (< 150 Hz) filtert?") und mit allen notwendigen Informationen, außerdem sollten Sie das Bild einfügen, das ein wichtiger Teil der Frage ist. es ist sehr einfach, ein Bild einzubetten.

Sie haben nicht einmal angegeben, was Sie erreichen wollen.

Es sieht so aus, als ob Sie neu auf der Website sind, und es sieht nach einer sehr interessanten Frage aus.

Aber Sie sind überhaupt nicht klar.

Erstens: Ist dies ein Problem mit der Aufnahme oder der Wiedergabe oder beidem?

Was genau machen Sie nun in Ihrem Experiment? Westliche wissenschaftliche Methode... leg es dar.

Sie generieren statische Daten in Ihrem remoteIO-Render-Callback? Nein, es hört sich so an, als würden Sie Passthrough verwenden. Sie sagen, dass Sie weißes Rauschen in das iPhone einspeisen. wie richten Sie Ihre Audioeinheit ein?

Das weiße Rauschen geht also in das iPhone hinein und geradeaus wieder hinaus... was stellt dieser Graph nun dar? FFT/Spektralanalyse der Ausgabe des iPhones? Wie machst du das? Gibst du das in eine OSX-Grafiksoftware ein, die Eingaben von der Eingangsleitung entgegennehmen kann?

Außerdem sollten Sie die Auswahl einschränken. Wenn Sie den Ton tatsächlich direkt durch das Gerät leiten, haben Sie keine Ahnung, wo die Filterung stattfindet. Soweit Sie wissen, könnte die Filterung sowohl in dem Gerät stattfinden, das das weiße Rauschen erzeugt, als auch in dem Gerät, das den iPhone-Ausgang grafisch darstellt.

Wie wäre es, wenn Sie Ihr weißes Rauschen innerhalb des Remote-I/O-Render-Callbacks erzeugen?

und dann extern zu erzeugen und die Daten zu analysieren, die von diesem Rückruf ankommen - Sie könnten eine FFT durchführen.

Wäre es nicht trotzdem besser, Sinuswellen mit unterschiedlichen Frequenzen einzuspeisen?