Выше ожидаемой собственной задержки при воспроизведении OpenAL (Windows, C ++)

TL / DR: простая программа эха, которая немедленно записывает и воспроизводит звук, показывает большую задержку, чем ожидалось.

Я работаю над приложением для аудиовещания в реальном времени. Я решил использовать OpenAL как для захвата, так и для воспроизведения аудиосэмплов. Я планирую отправлять UDP-пакеты с необработанными данными PCM по локальной сети. Моя идеальная задержка между записью на одной машине и воспроизведением на другой составляет 30 мс. (Высокая цель).

В качестве теста я сделал небольшую программу, которая записывает сэмплы с микрофона и немедленно воспроизводит их на основных динамиках. Я сделал это, чтобы проверить базовую задержку. Однако я наблюдаю внутреннюю задержку около 65-70 мс при простой записи звука и его воспроизведении. Я уменьшил размер буфера, который использует openAL, до 100 выборок со скоростью 44100 выборок в секунду. В идеале это даст задержку 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;
}

Вот изображение формы волны, показывающее задержку входящего звука и результирующее эхо. Этот пример показывает задержку около 70 мс.

Форма волны с задержкой эха 70 мс

Системные характеристики:

Intel Core i7-9750H 24 ГБ ОЗУ Windows 10 Домашняя: V 2004 - сборка 19041.508 Звуковой драйвер: Realtek Audio (версия драйвера 10.0.19041.1) Устройство ввода: гарнитура Logitech G330

Проблема воспроизводится в других системах Windows.

РЕДАКТИРОВАТЬ:

Я попытался использовать PortAudio, чтобы сделать то же самое, и добился аналогичного результата. Я определил, что это связано с аудиодрайверами Windows. Я перестроил PortAudio, используя только звук ASIO, и установил аудиодрайвер ASIO4ALL. Таким образом достигается приемлемая задержка <10 мс.


person Jacob Blomquist    schedule 15.10.2020    source источник
comment
openal может быть не самым быстрым, хотя я не знаю, насколько хорошо он работает без фильтров.   -  person bipll    schedule 15.10.2020
comment
@bipll Я согласен, я думаю, что задержка возникает из-за прохождения OpenAL от устройства захвата к устройству вывода, хотя я не совсем уверен, как это подтвердить. Нативные API, вероятно, будут лучшим вариантом, или Juce, если он предназначен для кроссплатформенности   -  person fdcpp    schedule 15.10.2020
comment
Также стоит отметить, что размер буфера может отличаться от запрошенного . Обратите внимание, что реализация может использовать больший буфер, чем запрошенный, если это необходимо, но реализация установит буфер не менее запрошенного размера. < / i> Из спецификации и справочника Open AL   -  person fdcpp    schedule 15.10.2020
comment
Для целостности исходный код здесь. Размер буфера обычно выражается в степени двойки. Получаете ли вы какое-либо изменение задержки при изменении размера буфера? скажем на 64 или 256?   -  person fdcpp    schedule 15.10.2020
comment
Создать это в macOS немного сложнее, чем в Windows. В Windows 10 он, похоже, ведет себя так, как ожидалось. Здесь может быть проблема с тем, как вы измеряете задержку. Вы должны быть осторожны, чтобы ваши выходные данные не попали в ваши входные данные.   -  person fdcpp    schedule 15.10.2020
comment
Спасибо за комментарии. Уменьшение размера буфера до степени двойки не влияет на задержку. Следует отметить, что я использую реализацию OpenAL Soft. Я хочу использовать OpenAL из-за пространственного звука. Я попытаюсь создать аналогичный пример с Port Audio и посмотреть, будет ли это лучше. Я бы предпочел не ехать родным маршрутом, но при необходимости пойду.   -  person Jacob Blomquist    schedule 15.10.2020


Ответы (1)


В конечном итоге я решил эту проблему, отказавшись от OpenAL в пользу PortAudio и Steinberg ASIO. Я установил ASIO4ALL и перестроил PortAudio, чтобы он принимал только драйверы устройств ASIO. Для этого мне нужно было использовать ASIO SDK от Steinberg. (См. Руководство здесь). Это позволило мне достичь задержки от 5 до 10 мс.

Этот пост очень помог: задержка ввода с обратным вызовом PortAudio и ASIO sdk

person Jacob Blomquist    schedule 15.10.2020