Воспроизведение 15 звуковых дорожек одновременно с задержкой <50 мс?

Question

Подводя итог, мой вопрос: возможно ли декодировать и воспроизводить 15 сжатых с потерями аудиодорожек на лету одновременно с задержкой до 50 мс и без заикания?

Фон

Я пишу звуковую библиотеку на простом C для создаваемой игры. Я надеюсь, что одновременно будет воспроизводиться до 15 звуковых дорожек с задержкой менее 50 мс.

На данный момент библиотека способна воспроизводить необработанные файлы PCM (упакованные 16-битные сэмплы с частотой 48000 Гц) и может легко воспроизводить 15 звуков одновременно с задержкой 45 мс без перебоев и с минимальным использованием процессора. Это на моей относительно старой машине Intel Q9300 + SSD.

Поскольку необработанные аудиофайлы огромны, я дополнил свою библиотеку для поддержки воспроизведения файлов OPUS с помощью opusfile ( https://mf4.xiph.org/jenkins/view/opus/job/opusfile-unix/ws/doc/html/index.html). Я надеялся, что смогу воспроизвести 15 звуков одновременно без аудиофайлов, занимающих более 200 МБ +. Насколько я был не прав - я смог воспроизвести только 3 или 4 дорожки OPUS одновременно, прежде чем услышал заикание и другие признаки опустошения буфера. Использование ЦП также значительно возросло по сравнению с воспроизведением в формате PCM.

Я также попытался включить поддержку VORBIS с помощью vorbisfile ( http://www.xiph.org/vorbis/doc/vorbisfile/). Я подумал, что, возможно, декодирование VORBIS на лету не будет так сильно загружать процессор. VORBIS немного лучше, чем OPUS - я могу воспроизводить 5 или 6 звуков одновременно, прежде чем заикание становится слышимым (я думаю, VORBIS действительно легче декодировать) - но это все еще не так хорошо, как воспроизведение сырых файлов PCM.

Прежде чем углубиться в низкоуровневые API-интерфейсы libvorbis / libopus и исследовать другие форматы сжатия звука, возможно ли реально декодировать и воспроизводить 15 сжатых с потерями аудиодорожек на лету одновременно с задержкой до 50 мс и без заикания? на настольном компьютере среднего и низкого уровня?

Если это помогает, моя звуковая библиотека в настоящее время вызывает функцию примерно каждые 15 мс, что в основном делает следующее (обработка ошибок и постобработка для ясности опущены):

void onBufferUpdateNeeded(int numSounds, struct Sound *sounds,
    uint16_t *bufferToUpdate, int numSamplesNeeded, uint16_t *tmpBuffer) {
    int i, j;
    memset(bufferToUpdate, 0, numSamplesNeeded * sizeof(uint16_t));
    for (i = 0; i < numSounds; ++i) {
        /* Seek to the specified sample number in the already-opened
        file handle. The implementation of this depends on the file
        type (vorbis, opus, raw PCM). */
        seekToSample(sounds[i].fileHandle, sounds[i].currentSample);

        /* Read numSamplesNeeded samples from the file handle into
        tmpBuffer. */
        readSamples(tmpBuffer, sounds[i].fileHandle, numSamplesNeeded);

        /* Add the samples into the buffer. */
        for (j = 0; j < numSamplesNeeded; ++j) {
            bufferToUpdate[j] += tmpBuffer[j];
        }
    }
}

Заранее благодарю за любую помощь!

Answer 1

Похоже, вы уже знаете ответ на свой вопрос: НЕТ. Как правило, единственный совет, который мне нужно ответить на подобные вопросы (особенно вопросы, связанные с производительностью), - это попробовать и выяснить, возможно ли это. Но вы уже собрали эти данные.

Это правда, что аудиокодеки с восприятием / с потерями имеют тенденцию к вычислительной нагрузке при декодировании. Звучит так, будто вы хотите избежать нехватки памяти в сыром PCM. В этом случае, если вы можете с уверенностью предположить, что у вас достаточно памяти, зарезервированной для вашего приложения, вы можете заранее декодировать аудиопотоки или использовать некоторый механизм кэширования, чтобы справиться с ограничениями памяти. Возможно, это может быть выгружено в другой поток (поскольку упомянутый в вашем вопросе процессор Q9300 является двухъядерным).

В противном случае вам нужно будет найти компрессор с более низкими вычислительными требованиями. Возможно, вас заинтересует FLAC, спонсируемый той же организацией, что и Vorbis и Opus. Это без потерь, поэтому он не будет сжимать так же хорошо, как алгоритмы с потерями, но он должен быть намного, намного быстрее для декодирования.

И если это все еще не подходит, просмотрите этот большой список ~150 аудиокодеков, пока не найдете тот, который соответствует вашим стандартам. Поскольку вы управляете клиентским программным обеспечением, у вас есть много вариантов (например, потоковая передача в веб-браузер).