Leistung zwischen CoreAudio und AVFoundation

Question

Ich habe eine Frage zu CoreAudio und AVFoundation.

Ich habe eine Pro-Audio-Anwendung mit CoreAudio mit einem AUGraph und AudioUnit gebaut.

Ich würde gerne zu AVFoundation Framework wechseln, das wirklich toll zu sein scheint. Aber da ich mir Sorgen um die Leistung mache, würde ich gerne ein bisschen mehr darüber wissen.

In meinem Kern-Audio-Render-Callback kann ich 512 Samples mit einer Samplerate von 44100 kHz verarbeiten, so dass mein Callback alle 10ms aufgerufen wird, und ich denke, dass es schneller gehen könnte (habe ich Recht?).

Jetzt in AVFoundation ist der Render-Callback der Tap des AVAudioNode. Und ich habe in dem Kommentar gelesen, dass der Parameter pufferSize the requested size of the incoming buffers in sample frames. Supported range is [100, 400] ms. ist Also bedeutet es, dass ich weniger als 4410 Proben bei jedem Aufruf verarbeiten kann?

Kommt die Einschränkung von den Objective-C-Einschränkungen (Nachrichtenaufrufe, Sperren usw.)?

Wird es sich nicht auf den Echtzeit-DSP-Prozess auswirken?

Answer 1

In meinen Experimenten mit der iOS AVAudioEngine API (iOS 10.3.3) fand ich tatsächlich, dass die Installation eines Tap auf einem AVAudioNode-Bus keine Puffer kürzer als 4410 Samples auf meinem iPhone 7 liefert. Dies könnte daran liegen, dass ein AVAudioEngine tappt liefert Puffer an einen Thread mit niedrigerer Priorität als CoreAudio-Audio-Unit-Callbacks und kann daher nicht so oft zuverlässig abgerufen werden, was zu einer höheren Latenz führt.

Allerdings kann man eine V3 AUAudioUnit-Unterklasse mit den von der Instanz internalRenderBlock für die Ausgabe empfangenen Puffern von 512 bis zu 64 Samples auf einem iPhone 7 erstellen. Calling setPreferredIOBufferDuration für die Audiositzung scheint gesetzt zu sein die bevorzugte AUAudioUnit Render-Blockpuffergröße. Ich habe einen Teil meines Testcodes geposted (gemischt mit Swift 3 und Objective C), um etwas zu erschaffen, was meiner Meinung nach eine V3 AUAudioUnit-Tongenerator-Unterklasse mit niedriger Latenz ist. Man muss Echtzeitcodierungseinschränkungen (keine Methodenaufrufe, Sperren, Speicherzuweisungen usw.) innerhalb des Renderblocks verstehen und befolgen, so dass einfaches C für den Audiokontextcode innerhalb des Blocks am besten erscheint (vielleicht sogar obligatorisch).

Für Mikrofoneingänge mit geringer Latenz mit gleich kurzen Puffern können Sie versuchen, Ihre Audioeinheit-Unterklasse mit dem InputNode der audioEngine zu verbinden und dann den AURenderPullInputBlock des Eingangs in Ihrem Einheiten-Renderblock aufzurufen.