Using voice processing

At a glance

Project structure

AVEchoTouch/
├── ViewController.swift
├── AudioEngine.swift
├── LevelMeterView.swift
├── PowerMeter.swift
├── MeterTable.swift
└── Audio/
    ├── Synth.aif
    └── sampleVoice*.wav

Structure observations

• AudioEngine centralizes AVAudioEngine graph/lifecycle behavior; the view controller retains AVAudioSession interruption and route UI policy.
• Meter calculation (PowerMeter/MeterTable) is separate from meter drawing (LevelMeterView).

Overall architecture

flowchart LR
    User["UIKit controls"] --> VC["ViewController"]
    VC --> Session["AVAudioSession"]
    VC --> Audio["AudioEngine"]
    Audio --> Input["Voice-processing input node"]
    Audio --> Speech["Speech player"]
    Audio --> FX["FX player"]
    Audio --> Recorded["Recorded-file player"]
    Speech --> Mixer["Main mixer → output"]
    FX --> Mixer
    Recorded --> Mixer
    Input --> File["Recorded AVAudioFile"]
    Input --> Power["PowerMeter"]
    Power --> Meter["LevelMeterView"]

Reference code

AVEchoTouch/AudioEngine.swift:95 — one service configures voice processing, node routing, recording, and metering taps.

func setup() {
    let input = avAudioEngine.inputNode
    try? input.setVoiceProcessingEnabled(true)
    let mainMixer = avAudioEngine.mainMixerNode
    avAudioEngine.connect(fxPlayer, to: mainMixer, format: fxBuffer.format)
    avAudioEngine.connect(speechPlayer, to: mainMixer, format: speechBuffer.format)
    avAudioEngine.connect(recordedFilePlayer, to: mainMixer, format: voiceIOFormat)
    input.installTap(onBus: 0, bufferSize: 256, format: voiceIOFormat) { buffer, _ in
        self.voiceIOPowerMeter.process(buffer: buffer)
    }
}

Interpretation

The screen coordinates user-facing lifecycle and system notifications. AudioEngine is authoritative for graph objects and recording/playback state. Taps feed focused meter objects that expose only display-ready levels.

Ownership and state

classDiagram
    ViewController *-- AudioEngine : creates
    AudioEngine *-- AVAudioEngine : owns
    AudioEngine *-- AVAudioPlayerNode : owns three
    AudioEngine *-- AVAudioFile : owns while recording
    AudioEngine *-- PowerMeter : owns three
    LevelMeterView o-- AudioLevelProvider : observes
    PowerMeter ..|> AudioLevelProvider
    PowerMeter *-- MeterTable : owns

Ownership evidence

AVEchoTouch/ViewController.swift:71 — the screen constructs the service, injects its meter providers, then starts it.

audioEngine = try AudioEngine()
speechMeter.levelProvider = audioEngine.speechPowerMeter
fxMeter.levelProvider = audioEngine.fxPowerMeter
voiceIOMeter.levelProvider = audioEngine.voiceIOPowerMeter
setupAudioSession(sampleRate: audioEngine.voiceIOFormat.sampleRate)
audioEngine.setup()
audioEngine.start()

Class and protocol design

Access control

Reference code

AVEchoTouch/AudioEngine.swift:24 — readable service outputs keep external setters closed.

public private(set) var voiceIOFormat: AVAudioFormat
public private(set) var isRecording = false
public private(set) var speechPowerMeter = PowerMeter()
public private(set) var fxPowerMeter = PowerMeter()
public private(set) var voiceIOPowerMeter = PowerMeter()

Logic ownership and placement

Design patterns

Naming conventions

• Framework wrapper uses the direct role name AudioEngine; views use UIKit ViewController/View suffixes.
• Commands state behavior: bypassVoiceProcessing, toggleRecording, speechPlayerPlay.
• Readable state follows is naming: isRecording, isPlaying, isNewRecordingAvailable.
• Meter types separate raw responsibility (PowerMeter) from display (LevelMeterView).

Architecture takeaways

• Give one service ownership of the entire AVAudioEngine graph and recording lifecycle.
• Expose meter data through a tiny read-only protocol rather than sharing audio nodes.
• Keep session interruption policy at the app/screen boundary and graph recovery in the audio service.
• Separate signal calculation from visualization so each can evolve independently.

Source map

• Official Apple documentation