OpenAL播放中的固有延迟高于预期(Windows,C++)



TL/DR:一个简单的回声程序可以立即记录和播放音频,其延迟高于预期。

我正在开发一个实时音频广播应用程序。我决定使用OpenAL来捕获和播放音频样本。我计划通过局域网发送UDP数据包和原始PCM数据。我在一台机器上录制和在另一台机器播放之间的理想延迟是30ms。(崇高的目标(。

作为一项测试,我制作了一个小程序,记录麦克风上的样本,并立即将其播放给主扬声器。我这样做是为了测试基线延迟。然而,我看到了一个固有的延迟约65-70毫秒从简单的录音和播放它。我已经将openAL使用的缓冲区大小减少到每秒44100个样本的100个样本。理想情况下,这将产生2-3毫秒的延迟。

我还没有在另一个平台(MacOS/Linux(上尝试过,以确定这是OpenAL问题还是Windows问题。

这是代码:

using std::list;
#define FREQ 44100   // Sample rate
#define CAP_SIZE 100 // How much to capture at a time (affects latency)
#define NUM_BUFFERS 10
int main(int argC, char* argV[])
{
list<ALuint> bufferQueue; // A quick and dirty queue of buffer objects
ALuint helloBuffer[NUM_BUFFERS], helloSource;
ALCdevice* audioDevice = alcOpenDevice(NULL); // Request default audio device
ALCcontext* audioContext = alcCreateContext(audioDevice, NULL); // Create the audio context
alcMakeContextCurrent(audioContext);
// Request the default capture device with a ~2ms buffer
ALCdevice* inputDevice = alcCaptureOpenDevice(NULL, FREQ, AL_FORMAT_MONO16, CAP_SIZE);
alGenBuffers(NUM_BUFFERS, &helloBuffer[0]); // Create some buffer-objects
// Queue our buffers onto an STL list
for (int ii = 0; ii < NUM_BUFFERS; ++ii) {
bufferQueue.push_back(helloBuffer[ii]);
}
alGenSources(1, &helloSource); // Create a sound source
short* buffer = new short[CAP_SIZE]; // A buffer to hold captured audio
ALCint samplesIn = 0;  // How many samples are captured
ALint availBuffers = 0; // Buffers to be recovered
ALuint myBuff; // The buffer we're using
ALuint buffHolder[NUM_BUFFERS]; // An array to hold catch the unqueued buffers
alcCaptureStart(inputDevice); // Begin capturing
bool done = false;
while (!done) { // Main loop
// Poll for recoverable buffers
alGetSourcei(helloSource, AL_BUFFERS_PROCESSED, &availBuffers);
if (availBuffers > 0) {
alSourceUnqueueBuffers(helloSource, availBuffers, buffHolder);
for (int ii = 0; ii < availBuffers; ++ii) {
// Push the recovered buffers back on the queue
bufferQueue.push_back(buffHolder[ii]);
}
}
// Poll for captured audio
alcGetIntegerv(inputDevice, ALC_CAPTURE_SAMPLES, 1, &samplesIn);
if (samplesIn > CAP_SIZE) {
// Grab the sound
alcCaptureSamples(inputDevice, buffer, samplesIn);
// Stuff the captured data in a buffer-object
if (!bufferQueue.empty()) { // We just drop the data if no buffers are available
myBuff = bufferQueue.front(); bufferQueue.pop_front();
alBufferData(myBuff, AL_FORMAT_MONO16, buffer, samplesIn * sizeof(short), FREQ);
// Queue the buffer
alSourceQueueBuffers(helloSource, 1, &myBuff);
// Restart the source if needed
// (if we take too long and the queue dries up,
//  the source stops playing).
ALint sState = 0;
alGetSourcei(helloSource, AL_SOURCE_STATE, &sState);
if (sState != AL_PLAYING) {
alSourcePlay(helloSource);
}
}
}
}
// Stop capture
alcCaptureStop(inputDevice);
alcCaptureCloseDevice(inputDevice);
// Stop the sources
alSourceStopv(1, &helloSource);
alSourcei(helloSource, AL_BUFFER, 0);
// Clean-up 
alDeleteSources(1, &helloSource);
alDeleteBuffers(NUM_BUFFERS, &helloBuffer[0]);
alcMakeContextCurrent(NULL);
alcDestroyContext(audioContext);
alcCloseDevice(audioDevice);
return 0;
}

这里是显示输入声音的延迟和产生的回声的波形的图像。此示例显示了大约70ms的延迟。

具有70ms回波延迟的波形

系统规格:

英特尔酷睿i7-9750H24 GB内存Windows 10主页:V 2004-内部版本19041.508声音驱动程序:Realtek Audio(驱动程序版本10.0.19041.1(输入设备:罗技G330耳机

该问题可在其他Windows系统上重现。

编辑:

我尝试使用PortAudio做类似的事情,并获得了类似的结果。我已经确定这是由于Windows音频驱动程序。我用ASIO音频重建了PortAudio,并安装了ASIO4ALL音频驱动程序。这已经实现了<10ms。

我最终通过放弃OpenAL而选择PortAudio和Steinberg ASIO来解决这个问题。我安装了ASIO4ALL,并重建了PortAudio以仅接受ASIO设备驱动程序。我需要使用Steinberg的ASIO SDK来完成这项工作。(此处遵循指南(。这使我能够实现5到10ms之间的延迟。

这篇文章帮助很大:PortAudio回调和ASIO sdk 的输入延迟

最新更新