DEV Community: Klakk 開発チーム

低遅延の打鍵音をAVAudioPlayerNodeプールで重ねる設計

Klakk 開発チーム — Thu, 06 Aug 2026 08:05:33 +0000

Macでキー入力に合わせて短い効果音を鳴らすとき、毎回ファイルを開いてプレイヤーを作ると、入力のホットパスにI/Oと初期化が入り込みます。この記事では、私が有料macOSアプリKlakkで使っている現在の構成を題材に、事前準備したPCMバッファとAVAudioPlayerNodeの固定プールをどう分けたかを整理します。

1. キー入力より前に音を準備する

再生時に必要なのは、キーコードからすでに変換済みのバッファを引くことだけにします。

private struct PreparedKeySound {
    let buffer: AVAudioPCMBuffer
    let outputGain: Float
}

private var preparedKeySounds: [String: PreparedKeySound] = [:]
private let stateLock = NSLock()

サウンドパックを読み込む段階で、ファイルの読み込み、必要区間の切り出し、出力フォーマットへの変換、先頭の無音除去、音量係数の計算まで済ませます。再生時に変換を始めないことが一番大きな分離です。

辞書の入れ替えは一度組み立ててから短いロック内で行います。

let preparedSounds = try prepareKeySounds(for: soundPack)

stateLock.lock()
currentSoundPack = soundPack
preparedKeySounds = preparedSounds
loggedMissingKeys.removeAll()
stateLock.unlock()

これなら、別のサウンドパックを読み込んでいる途中の半端な辞書を再生側が見ることはありません。

2. Player Nodeを固定数だけ先に接続する

現在の実装では、起動時に10個の AVAudioPlayerNode を作り、同じ mainMixerNode へ接続しています。

private var playerNodePool: [AVAudioPlayerNode] = []
private let maxConcurrentSounds = 10
private var currentNodeIndex = 0

for _ in 0..<maxConcurrentSounds {
    let node = AVAudioPlayerNode()
    audioEngine.attach(node)
    audioEngine.connect(node, to: audioEngine.mainMixerNode, format: nil)
    playerNodePool.append(node)
}

ノードのattach/connectをキー入力のたびに行わず、入力後はラウンドロビンで次のノードを選びます。

let node = playerNodePool[currentNodeIndex]
currentNodeIndex = (currentNodeIndex + 1) % maxConcurrentSounds

node.stop()
node.volume = masterVolume * preparedSound.outputGain * backgroundModeMultiplier
node.scheduleBuffer(preparedSound.buffer, at: nil, options: [])
node.play()

短い音が重なる通常のタイピングでは、一つのノードだけを使うより前の音を切りにくくなります。

3. 固定プールの限界も仕様にする

この方式は無限に音を重ねません。11個目が10個の再生時間内に来れば、ラウンドロビンで戻ったノードを stop() するため、そのノードの古い音は途中で終わります。

これは単純さと上限の明確さを選んだ結果です。改善案としては次の選択肢があります。

再生中でないノードを優先して探す
最も古いノードだけを再利用する
音の長さに応じてプール数を測定で決める
同時発音数、切断数、再生遅延をテストで記録する

また、currentNodeIndex と音量値へ複数キューから同時に触れる設計へ広げるなら、プレイヤー操作だけでなくアプリ側の状態にも直列化が必要です。「AVAudioPlayerNodeを使っているから全状態が安全」とは扱いません。

4. Engine停止時は、その一音を捨てる

出力デバイス変更などでEngineが止まっていたら、現在の実装は再起動を一度だけ要求し、そのキーの音は再生しません。

guard audioEngine.isRunning else {
    restartLock.lock()
    let shouldRestart = !isRestarting
    if shouldRestart { isRestarting = true }
    restartLock.unlock()

    if shouldRestart { restartAudioEngine() }
    return
}

停止中の入力を後からまとめて鳴らすより、次のキーから正常に戻る方が打鍵フィードバックには自然だからです。再起動中フラグをロックで守り、同時に複数の再起動を走らせないことも重要です。

まとめ

低遅延化は「速いAPIを呼ぶ」だけではなく、キー入力後にしないことを決める作業でした。

ファイルI/O、変換、無音除去、ゲイン計算を事前に終える
Player Nodeを固定数だけattach/connectしておく
再生時は辞書参照、音量設定、schedule/playに限定する
プール上限とEngine再起動時の欠落を隠さない

開発者による開示: 私はKlakkの開発者です。Klakkは14種類の打鍵音を切り替えられる有料Macアプリです。ソフトウェアが追加音を再生するもので、実物のキーボードの物理音や打鍵感は変えません。ASMRや集中の感じ方には個人差があり、ADHDを含む症状を改善する医療製品ではありません。

macOSのInput Monitoring判定で、2つのAPIと「実際に動くか」を分けて観察する

Klakk 開発チーム — Thu, 06 Aug 2026 03:58:33 +0000

macOSでグローバルなキーイベントを受け取るアプリを作ると、権限判定を単純な Bool として扱いたくなります。しかし実装と検証を進めるほど、次の3つは分けて考えた方が安全でした。

TCC上で権限がどう見えているか
ユーザーへ権限を要求した直後か
CGEvent.tapCreate が実際に成功し、イベントを受け取れるか

この記事では、macOS向け打鍵音アプリを作る過程で使った診断方法を、製品固有のUIから切り離して整理します。

2つの事前確認API

Listen-onlyのイベント監視では、次の2つを並べて観察できます。

import CoreGraphics
import IOKit.hidsystem

struct InputMonitoringStatus {
    let hid: IOHIDAccessType
    let cgGranted: Bool

    var looksGranted: Bool {
        hid == kIOHIDAccessTypeGranted || cgGranted
    }
}

func readInputMonitoringStatus() -> InputMonitoringStatus {
    InputMonitoringStatus(
        hid: IOHIDCheckAccess(kIOHIDRequestTypeListenEvent),
        cgGranted: CGPreflightListenEventAccess()
    )
}

ここで重要なのは、looksGranted を「監視が必ず動く」という保証にしないことです。これはあくまで事前状態の観察結果です。プロセス、署名、実行パス、権限変更直後の状態などを切り分けるために、2つの値を別々にログへ残します。

ログへ記録するなら、入力内容ではなく次のような診断情報だけで十分です。

bundle_id=com.example.app
hid_status=granted
cg_preflight=true
event_tap_created=true

キーコード、入力文字列、前後のアプリ名まで診断ログへ入れる必要はありません。

権限要求は「確認」と分ける

要求側のAPIは、確認のたびに呼ぶのではなく、初回案内やユーザーが明示的に「権限を開く」を選んだ時だけ呼びます。

func requestInputMonitoring() {
    let hidRequested = IOHIDRequestAccess(kIOHIDRequestTypeListenEvent)
    let cgRequested = CGRequestListenEventAccess()

    let current = readInputMonitoringStatus()
    print("hidRequested=\(hidRequested), cgRequested=\(cgRequested)")
    print("looksGranted=\(current.looksGranted)")
}

要求APIの戻り値だけで次の画面を決めると、ユーザーがシステム設定へ移動して後から許可した場合を扱いにくくなります。要求後は、アプリ側の状態を次のように分けました。

notRequested: まだ案内していない
waitingForUser: システム設定での操作待ち
preflightGranted: 事前確認では許可済み
monitoring: Event Tapが作成され、監視中
revoked: 監視中に権限を失った

最終判定はEvent Tapの生成結果

事前確認が通っていても、Event Tapの作成失敗は別の事実として扱います。

let mask = (1 << CGEventType.keyDown.rawValue)
         | (1 << CGEventType.keyUp.rawValue)
         | (1 << CGEventType.flagsChanged.rawValue)

let tap = CGEvent.tapCreate(
    tap: .cgSessionEventTap,
    place: .headInsertEventTap,
    options: .listenOnly,
    eventsOfInterest: CGEventMask(mask),
    callback: callback,
    userInfo: context
)

guard let tap else {
    // 権限表示だけでなく、署名・実行パス・再起動要否も切り分ける
    return
}

.listenOnly はイベントを書き換えない設計を表せますが、プライバシー説明の代わりにはなりません。アプリが何を処理し、何を保存せず、何を外部送信しないのかは別途明記する必要があります。

権限変更をポーリングする場合

システム設定を開いた後にアプリへ戻ってもらう導線では、短い間隔で状態を再確認する実装が分かりやすいです。ただし、次の境界を決めておきます。

Timerを重複生成しない
監視開始後は要求用Timerを停止する
権限喪失時はEvent TapとRunLoop Sourceを破棄する
復旧時はユーザー設定が有効な場合だけ監視を再開する
アプリ終了時はTimerも明示的に破棄する

「権限がある」と「監視中」を同じフラグにすると、権限喪失後のUIと実体がずれやすくなります。権限状態、Event Tapの生存状態、ユーザーが機能をオンにしているかを別々に持つ方が復旧処理を書きやすくなりました。

まとめ

IOHIDCheckAccess と CGPreflightListenEventAccess は診断のため別々に観察する
要求APIは確認ループから分離し、ユーザー操作に結び付ける
事前確認が通っていても、Event Tap生成結果を最終的な動作判定にする
権限、監視状態、ユーザー設定を別の状態として管理する
入力内容を診断ログやAnalyticsへ混ぜない

この記事は、macOS向け打鍵音アプリ Klakk の開発チームが、実装中に得た知見を一般化してまとめたものです。自社の有料製品へのリンクを含みます。

ブラウザ試聴: https://tryklakk.com/ja/#demo
Mac App Store: https://apps.apple.com/jp/app/id6754638652?pt=127956280&ct=jp-dev-input-permission-20260806&mt=12
プライバシーポリシー: https://tryklakk.com/ja/privacy/

Klakkは物理キーコードと押下・解放状態をローカルで処理し、入力文字列を組み立てたり送信したりしません。ソフトウェアの音を追加する製品であり、物理キーボード自体の音や打鍵感は変えません。