Android: 初始音频处理方法调用耗时较长
Android: Initial audio processing method call takes a long time
我的 Android 应用程序(使用 NDK/OpenSL ES)中的音频回调出现了一个非常奇怪的问题。我正在以 44.1 kHz 和 512 帧流式传输音频输出(这使我的回调时间为 11.6 毫秒)。在回调中,我正在合成几个波形、滤波器等(如合成器)。由于优化,我从未达到超过 5 毫秒的回调时间。但是,当我打开特定效果(数字延迟线)时,它开始在回调中花费更长的时间。数字延迟线将从 7.5 毫秒(在处理完所有 voices/filters 之后)跳到 100 到 350 毫秒。
这是最令人困惑的部分;可能在 1 或 2 秒后,数字延迟执行时间将从极高的时间跳到每次回调的 0.2 毫秒完成时间。
为什么 Android 应用程序需要很长时间才能完成我的数字延迟处理代码,前几次回调,然后消失到非常短且音频愉快的时间?我现在有点不知所措,不知道如何解决这个问题。确认一下,这只发生在延迟处理方法中。它只是一个标准的数字延迟线(你可以在 github 上找到一些)我觉得这里的算法不是问题...
有点像我的音频回调代码的 pseudocode/rough 草图:
static bool myAudioCallback(void *userData, short int *audIO, int numSamples, int srate) {
AudioData *data = (AudioData *)userData;
// Resets pointer array values to 0
for (int i = 0; i < numSamples; i++) data->buffer[i] = 0;
// Voice Generation Block
for (int voice = 0; voice < data->numVoices; voice++) {
// Reset voice buffers:
for (int i = 0; i < numSamples; i++) data->voiceBuffer[i] = 0;
// Generate Voice
data->voiceManager[voice]->generateVoiceBlock(data->voiceBuffer, numSamples);
// Sum voices
for (int i = 0; i < numSamples; i++) data->buffer[i] += data->voiceBuffer[i]];
}
// When app first starts, delayEnabled = false so user must click on a
// button on the UI to enable it.
// Trouble is that when we enable processDelay(double *buffer, in frames) the
// first time, we get a long execution time.
if (data->delayEnabled) {
data->delay->processDelay(data->buffer, numSamples);
}
// Conversion loop
for (int i = 0; i < numSamples; i++) {
double sample = clipOutput(data->buffer[i]);
audIO[2*i] = audIO[(2*i)+1] = CONV_FLT_TO_16BIT(sample * data->volume);
}
}
谢谢!
这不是解决方案的好答案,但这是我所做的:
在用户能够在应用程序上执行任何操作之前,我打开了延迟并让它 运行 正常运行大约 2 秒,然后将其关闭。这允许回调在不破坏音频的情况下执行其奇怪的 300 毫秒长执行时间。
显然这不是一个很好的答案,如果有人能找出更合乎逻辑的解释,我会非常乐意将其标记为答案。
我的 Android 应用程序(使用 NDK/OpenSL ES)中的音频回调出现了一个非常奇怪的问题。我正在以 44.1 kHz 和 512 帧流式传输音频输出(这使我的回调时间为 11.6 毫秒)。在回调中,我正在合成几个波形、滤波器等(如合成器)。由于优化,我从未达到超过 5 毫秒的回调时间。但是,当我打开特定效果(数字延迟线)时,它开始在回调中花费更长的时间。数字延迟线将从 7.5 毫秒(在处理完所有 voices/filters 之后)跳到 100 到 350 毫秒。
这是最令人困惑的部分;可能在 1 或 2 秒后,数字延迟执行时间将从极高的时间跳到每次回调的 0.2 毫秒完成时间。
为什么 Android 应用程序需要很长时间才能完成我的数字延迟处理代码,前几次回调,然后消失到非常短且音频愉快的时间?我现在有点不知所措,不知道如何解决这个问题。确认一下,这只发生在延迟处理方法中。它只是一个标准的数字延迟线(你可以在 github 上找到一些)我觉得这里的算法不是问题...
有点像我的音频回调代码的 pseudocode/rough 草图:
static bool myAudioCallback(void *userData, short int *audIO, int numSamples, int srate) {
AudioData *data = (AudioData *)userData;
// Resets pointer array values to 0
for (int i = 0; i < numSamples; i++) data->buffer[i] = 0;
// Voice Generation Block
for (int voice = 0; voice < data->numVoices; voice++) {
// Reset voice buffers:
for (int i = 0; i < numSamples; i++) data->voiceBuffer[i] = 0;
// Generate Voice
data->voiceManager[voice]->generateVoiceBlock(data->voiceBuffer, numSamples);
// Sum voices
for (int i = 0; i < numSamples; i++) data->buffer[i] += data->voiceBuffer[i]];
}
// When app first starts, delayEnabled = false so user must click on a
// button on the UI to enable it.
// Trouble is that when we enable processDelay(double *buffer, in frames) the
// first time, we get a long execution time.
if (data->delayEnabled) {
data->delay->processDelay(data->buffer, numSamples);
}
// Conversion loop
for (int i = 0; i < numSamples; i++) {
double sample = clipOutput(data->buffer[i]);
audIO[2*i] = audIO[(2*i)+1] = CONV_FLT_TO_16BIT(sample * data->volume);
}
}
谢谢!
这不是解决方案的好答案,但这是我所做的:
在用户能够在应用程序上执行任何操作之前,我打开了延迟并让它 运行 正常运行大约 2 秒,然后将其关闭。这允许回调在不破坏音频的情况下执行其奇怪的 300 毫秒长执行时间。
显然这不是一个很好的答案,如果有人能找出更合乎逻辑的解释,我会非常乐意将其标记为答案。