Capturing stereo audio from built-In microphones

At a glance

Project structure

StereoAudioCapture/
├── MainViewController.swift
├── Audio/
│   ├── AudioController.swift
│   └── MeterTable.swift
├── Model/StereoLayout.swift
├── StereoLevelMeterView.swift
├── StereoLayoutView.swift
└── Extensions/
    ├── FileManagerExtensions.swift
    └── UIViewExtensions.swift

Structure observations

• AudioController is the single boundary around audio session, recorder, player, and file state.
• Meter rendering and microphone-layout rendering are separate custom views; StereoLayout translates framework orientations into display cases.

Overall architecture

flowchart LR
    User["User"] --> VC["MainViewController"]
    VC --> Audio["AudioController"]
    Audio --> Session["AVAudioSession data source"]
    Audio --> Recorder["AVAudioRecorder"]
    Audio --> Player["AVAudioPlayer"]
    Audio --> Files["Documents recording.wav"]
    Meter["StereoLevelMeterView"] --> Provider["StereoLevelsProvider"]
    Audio -. conforms .-> Provider
    VC --> Layout["StereoLayoutView"]

Reference code

StereoAudioCapture/Audio/AudioController.swift:134 — the façade resolves a UI option into an AVAudioSession data source and stereo orientation.

func selectRecordingOption(_ option: RecordingOption,
                           orientation: Orientation,
                           completion: (StereoLayout) -> Void) {
    let session = AVAudioSession.sharedInstance()
    guard let preferredInput = session.preferredInput,
          let dataSources = preferredInput.dataSources,
          let newDataSource = dataSources.first(where: { $0.dataSourceName == option.dataSourceName })
    else { return }
    // Configure the selected source and report its layout.
}

Interpretation

The UIKit controller maps buttons and orientation to coarse audio commands. AudioController owns framework state and produces a semantic StereoLayout; the meter only knows the small StereoLevelsProvider capability.

Ownership and state

classDiagram
    MainViewController *-- AudioController : creates
    MainViewController --> StereoLevelMeterView : outlet
    MainViewController --> StereoLayoutView : outlet
    AudioController *-- AVAudioRecorder : owns
    AudioController *-- AVAudioPlayer : owns while playing
    AudioController *-- MeterTable : owns
    AudioController o-- AudioControllerDelegate : weak
    StereoLevelMeterView o-- StereoLevelsProvider : observes

Ownership evidence

StereoAudioCapture/MainViewController.swift:15 — the screen creates its audio service and supplies it to the meter/delegate relationships.

class MainViewController: UIViewController {
    // ...
}

Class and protocol design

Access control

Reference code

StereoAudioCapture/Audio/AudioController.swift:38 — the model exposes a title but confines its device key to this file.

struct RecordingOption: Comparable {
    let name: String
    fileprivate let dataSourceName: String
}

Logic ownership and placement

Design patterns

Naming conventions

• Coordinator names use role nouns: AudioController, MainViewController.
• Capability protocols use provider/delegate suffixes: StereoLevelsProvider, AudioControllerDelegate.
• Commands use concrete verbs: selectRecordingOption, setupRecorder, record, play.
• UI files match their primary view; model and extension folders expose their purpose.

Architecture takeaways

• Hide device-source identifiers while presenting a small display model to UI code.
• Use protocols to normalize only the capability the consumer needs, such as metering.
• Keep recorder, player, state, and persistence under one lifecycle authority.
• Map hardware orientation into a semantic value before updating the view.

Source map

• Official Apple documentation