为何Lightning接口耳机下AudioUnit每帧采集940字节？iOS录音问题咨询

Hey there, let's break down why you're hitting this inconsistent frame/byte count issue with your AudioUnit-based recording app. I’ve dealt with similar iOS audio routing quirks before, so here are the most likely reasons behind what you’re seeing:

• 硬件缓冲区的原生差异
  iPhones without a 3.5mm jack (like iPhone 7 and later) use a completely different audio hardware stack compared to the iPhone 6s. The Lightning-only audio subsystem has its own fixed native buffer size that might not align with your requested 1024 bytes per frame. When the hardware can’t accommodate your requested buffer size, it falls back to its default—hence the 940 bytes per frame and associated errors. Your iPhone 6s works with Lightning headphones because its Lightning audio module shares buffer alignment with the 3.5mm jack, which isn’t the case for newer Lightning-only models.

• AudioSession未适配路由切换
  When you switch between 3.5mm, Lightning, or built-in audio routes, iOS resets some audio subsystem parameters. If your app isn’t listening for AVAudioSessionRouteChangeNotification to reconfigure the AudioUnit after a route change, it’ll keep using the old buffer size settings that don’t match the new hardware. This is probably why the 6s works with both headphone types (you’re not switching routes on the same device, or the route change doesn’t break the buffer alignment) but newer devices fail.

• 音频格式参数配置错误
  Double-check your AudioStreamBasicDescription struct—mix-ups between frames and bytes are super common here. For example, if you’re using 16-bit mono audio, each frame is 2 bytes. A "1024 bytes" collection would translate to 512 frames, not 1024 frames. If your app is incorrectly calculating bytes per frame or frames per packet, different hardware will interpret your buffer size request differently, leading to unexpected byte counts in callbacks.

• 硬编码缓冲区大小未适配硬件偏好
  Instead of hardcoding a fixed 1024 bytes, you should query the audio hardware’s preferred buffer size dynamically. iOS lets you suggest a buffer size, but it’ll override it if the hardware can’t support it. Use AVAudioSession to get the actual supported buffer duration, then calculate the corresponding frame/byte count:

  // Objective-C example
  AVAudioSession *session = [AVAudioSession sharedInstance];
  NSError *error = nil;
  [session setPreferredIOBufferDuration:0.02 error:&error]; // Adjust based on latency needs
  if (!error) {
      NSTimeInterval actualDuration = session.IOBufferDuration;
      UInt32 frameCount = (UInt32)(session.sampleRate * actualDuration);
      // Use this frameCount to configure your AudioUnit
  }
  

  This ensures your buffer size matches what the hardware can handle consistently across all devices.

To fix this, start by validating your audio format parameters, then add route change listening to reconfigure the AudioUnit, and finally replace the hardcoded buffer size with a dynamically queried value based on the current hardware.

内容的提问来源于stack exchange，提问作者Grayson