OSX CoreAudio:提前获取inNumberFrames-进行初始化吗? [英] OSX CoreAudio: Getting inNumberFrames in advance - on initialization?

问题描述

我正在尝试用C语言编写一个简单的基于单AU播放的，(几乎)无延迟的 tracking phase vocoder 原型.它是一个独立程序.我想找到一个渲染回调可以安全承受的处理负载，因此我宁愿不要使用异步DSP.

I'm experimenting with writing a simplistic single-AU play-through based, (almost)-no-latency tracking phase vocoder prototype in C. It's a standalone program. I want to find how much processing load can a single render callback safely bear, so I prefer keeping off async DSP.

我的概念是仅使用一个预定值，即 窗口步长 或 跳跃大小 或 抽取因子 (在不同文献来源中使用的同一术语的不同名称).此数字将等于inNumberFrames，这在某种程度上取决于 设备采样率 (还有什么?).所有其他参数(例如 窗口大小 和 FFT大小 )都将根据窗口步长进行设置.对于一个回调中的所有内容，这似乎是最简单的方法.

My concept is to have only one pre-determined value which is window step, or hop size or decimation factor (different names for same term used in different literature sources). This number would equal inNumberFrames, which somehow depends on the device sampling rate (and what else?). All other parameters, such as window size and FFT size would be set in relation to the window step. This seems the simplest method for keeipng everything inside one callback.

在实际渲染开始之前(即在调用AudioOutputUnitStart()之前)是否存在一种安全的方法来独立于计算机并安全地猜测或查询为inNumberFrames?

Is there a safe method to machine-independently and safely guess or query which could be the inNumberFrames before the actual rendering starts, i.e. before calling AudioOutputUnitStart()?

相位声码器算法通常是标准且非常简单的，它使用vDSP函数进行FFT，加上自定义相位积分，我对此没有任何疑问.

The phase vocoder algorithm is mostly standard and very simple, using vDSP functions for FFT, plus custom phase integration and I have no problems with it.

此代码正在监视输入回调中的计时:

This code is monitoring timings within the input callback:

static Float64 prev_stime;  //prev. sample time
static UInt64  prev_htime;  //prev. host time        
printf("inBus: %d\tframes: %d\tHtime: %lld\tStime: %7.2lf\n",
       (unsigned int)inBusNumber,
       (unsigned int)inNumberFrames,
       inTimeStamp->mHostTime   - prev_htime,
       inTimeStamp->mSampleTime - prev_stime);
prev_htime = inTimeStamp->mHostTime;
prev_stime = inTimeStamp->mSampleTime;

很好奇，参数inTimeStamp-> mSampleTime实际上显示了渲染的帧数(参数名称似乎有些误导).无论是否在运行时通过 AudioMIDISetup.app 重新设置了另一个采样率，此数字始终为512，就好像该值已通过编程方式进行硬编码一样.一方面，

Curious enough, the argument inTimeStamp->mSampleTime actually shows the number of rendered frames (name of the argument seems somewhat misguiding). This number is always 512, no matter if another sampling rate has been re-set through AudioMIDISetup.app at runtime, as if the value had been programmatically hard-coded. On one hand, the

inTimeStamp->mHostTime - prev_htime

间隔以数学上清晰的方式根据设置的采样率动态变化.只要采样率值与44100Hz的倍数匹配，实际渲染就在进行.另一方面，48kHz的倍数会产生渲染error -10863 ( = kAudioUnitErr_CannotDoInCurrentContext ).我一定错过了很重要的一点.

interval gets dynamically changed depending on the sampling rate set in a mathematically clear way. As long as sampling rate values match multiples of 44100Hz, actual rendering is going on. On the other hand 48kHz multiples produce the rendering error -10863 ( = kAudioUnitErr_CannotDoInCurrentContext ). I must have missed a very important point.

推荐答案

帧数通常是采样率乘以缓冲区持续时间.有一个Audio Unit API可以请求采样率和首选的缓冲区持续时间(例如44100和5.8 mS，导致256帧)，但是并非所有OS版本上的所有硬件都遵循所有请求的缓冲区持续时间或采样率.

The number of frames is usually the sample rate times the buffer duration. There is an Audio Unit API to request a sample rate and a preferred buffer duration (such as 44100 and 5.8 mS resulting in 256 frames), but not all hardware on all OS versions honors all requested buffer durations or sample rates.

这篇关于OSX CoreAudio:提前获取inNumberFrames-进行初始化吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！