В настоящее время SDL_Mixer имеет два типа звуковых ресурсов: куски и музыку.Запуск музыки как фрагментов SDL_Mixer
Помимо ограничений API и поддерживаемых форматов, есть ли причины не загружать и воспроизводить музыку как SDL_Chunk и канал? (память, скорость и т. д.)
API - это настоящая проблема. «Музыкальные» API разработаны для работы с потоковой сжатой музыкой, а «звуковые» API - нет. Опять же, если вам удастся заставить его работать в вашем приложении, тогда он работает.
Я не смотрел код SDL, но я предполагал, что «куски» предназначены для меньших образцов звука и кэшируются в памяти, декодируются целиком, пока «музыка» транслируется (не кэшируется в памяти целиком, но при необходимости декодируется и буферизируется с предположением, что по большей части он будет воспроизводиться с самого начала и непрерывно с этой точки, возможно, некоторое время назад возвращается к началу)
Итак, причина в памяти. Вы не хотите декодировать, скажем, 4 минуты 16-битной стереозаписи в память, так как она будет потреблять 44100 Гц * 2 байта * 2 канала * 4 минуты * 60 сек/мин == 42336000 байт, если вы попытаетесь, когда сможете декодировать и будьте осторожны.
OTOH, если у вас есть 10 Мб ОЗУ в минуту музыки, чтобы тратить время, и вам нужен процессор, который будет потребляться при помощи декодирования на лету ... возможно, вы могли бы использовать куски.
Итак, с большими звуковыми файлами музыкальный API быстрее загружается, чем звуковой API ...? – luiscubal
Думаю, что да. Прошло некоторое время с тех пор, как я работал с SDL_Mixer. Просто подумал, что я попытаюсь внести небольшой вклад, потому что никто не отвечает ни на что здесь ... –
Я не думаю, что это загрузка быстрее, я думаю, что это экономия памяти. Необработанные данные PCM очень дороги. Декомпрессия музыкального потока и его воспроизведение более дорогостоящи, чем просто воспроизведение, но это экономит много места. – notlesh