Альтернатива SDL_Mixer: Прошу любить и жаловать

Спасибо за работу. Потестим, посмотрим...

https://github.com/devbrain/musac/blob/aa9b7c207dd934afaac7f0f35faf88c6369dbd...

2) Constructs an array of the given dynamic size. The array elements are value-initialized. This overload participates in overload resolution only if T is an array of unknown bound. The function is equivalent to:

unique_ptr<T>(new std::remove_extent_t<T>[size]())

(https://en.cppreference.com/w/cpp/memory/unique_ptr/make_unique)

п.с. вообще не вник, почему тут не std::vector?

апд.
[expr.new#7]

If the type-id or new-type-id denotes an array type of unknown bound ([dcl.array]), the new-initializer shall not be omitted; the allocated object is an array with n elements, where n is determined from the number of initial elements supplied in the new-initializer ([dcl.init.aggr], [dcl.init.string]).

Так исторически сложилось :) хотел что-то попроще чем вектор, что-то специально заточенное под задачу

получился в целом вектор) — мне кажется лучше его и использовать.

https://github.com/devbrain/musac/blob/aa9b7c207dd934afaac7f0f35faf88c6369dbd...

https://godbolt.org/z/h7dGd4sMj

тут в листинге асма явно не будет никакой разницы, поскольку там я бы сказал уже ооооочень давно уже делается сея проверка для возможности использования memcpy (если даже std::copy вообще не производительнее будет...)

https://github.com/devbrain/musac/blob/aa9b7c207dd934afaac7f0f35faf88c6369dbd...
тут выдаётся предупреждение:

[20/228] Building CXX object src/musac/sdk/CMakeFiles/musac_sdk.dir/audio_converter.cc.o
/musac/src/musac/sdk/audio_converter.cc: In static member function ‘static musac::buffer<unsigned char> musac::audio_converter::convert(const musac::audio_spec&, const uint8_t*, size_t, const musac::audio_spec&)’:
/musac/src/musac/sdk/audio_converter.cc:73:16: warning: ‘void* memcpy(void*, const void*, size_t)’ writing between 4294967296 and 18446744069414584320 bytes into a region of size between 0 and 4294967295 [-Wstringop-overflow=]
   73 |     std::memcpy(working_buffer.data(), src_data, src_len);
      |     ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

buffer<uint8_t> working_buffer(static_cast<unsigned int>(src_len));

C++

Альтернатива SDL_Mixer

Ага, ну да

О, спасибо. такого не видел. Обязательно проверю

Ну и там выше уже напихали за использование не fixed-size типов

ну больше не фиксед-сайз — а типов, которые заведомо могут быть усечены в неправильном направлении (а так же переполнены).
size_t с моей точки зрения норм — и int тоже...

Странно, у меня такое предупреждение не выстреливает g++ –version g++ (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0

что то, что другое, может оказаться меньше ожидаемых 32 бит.

ну в данном случае неважно сколько бит там — не ожидается определённая битность.

каких-то fixed-size типов вообще может не быть на каких-то системах.

это в данном конкретном месте. но там везде по коду не fixed-size и где-то это может оказаться критичным (в микшере, например). проверять я это, конечно же, не буду

почему-то висит на

-- Examples will use SDL3 backend

после повторной попытке конфигурации (с предварительной очисткой папки build)

апд. отвисло — но чот долгая конфигурация — как я понял собираются во время неё примеры?

возможно у тебя какая-то система где unsigned и size_t одного размера...

[ 86%] Linking CXX executable ../../bin/imgui_player
/usr/bin/ld: ../../lib/libimgui_lib.a(imgui_impl_sdl3.cpp.o): undefined reference to symbol 'SDL_ShowCursor@@SDL3_0.0.0'
/usr/bin/ld: /usr/lib/libSDL3.so.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status

получается что не выставлены все нужные зависимости (проверки) в конфигурации

Конфигурация долгая, потому что зависимости приносит

А какие флаги cmake были использованы?

Похоже, что система сборки пытается слинковать с /usr/lib/libSDL3.so.0 и не находит его. У вас SDL2 или SDL3 установлены в системе?

libmodplug - MOD/tracker format support

Лучше dumb-а, но немного протухла. По нормально нужно переходить на libopenmpt.

никаких:

cmake -B build -DCMAKE_BUILD_TYPE=Release
cmake --build build -j2

похоже на баг в билд системе. попробую воспроизвести

Нет. Как раз не пытается. DSO missing from command line означает, что библиотеки нет в списке для линковки.

А нету её там, потому что вот тут https://github.com/devbrain/musac/blob/master/example/imgui_player/CMakeLists.txt#L40 нет find_package(SDL3) (как в ветке для SDL2)

спасибо за наводку

Вроде починил проблему с линовкой

основная проблема в SDL_Mixer - это отсуствие возможности добавлять свои форматы

какие еще свои форматы? звук это PCM, а вы что предлагаете в рантайм постоянно юзать проц? ну спасибо айболит!

А альтернатива SDL_mixer это OpenAL.

dr_wav, dr_flac, dr_mp3

Можно заменить на miniaudio 0.11.22 от того же автора. И, наверное, её можно будет использовать для вывода звука, как альтернативу SDL.

Фишка в том, что бы использовать SDL для звука (например весь проект на SDL - зачем еще что-то тащить) просто сам SDL не поддерживает вывод аудио из разных форматов (например VOC или MIDI)

сам SDL не поддерживает вывод аудио из разных форматов (например VOC или MIDI)

SDL_native_midi https://github.com/libsdl-org/SDL_native_midi

Посмотрите https://github.com/libsdl-org

например весь проект на SDL - зачем еще что-то тащить

А если это консольная утилита, плеер, например?
Не слежу, часто ли автор обновляет свои dr_*, но в whisper.cpp я в начале года добавил чтение аудиофайлов с использованием miniaudio, недовольных, вроде бы, нет. :)

Фишка в том, что бы использовать SDL для звука (например весь проект на SDL - зачем еще что-то тащить) просто сам SDL не поддерживает вывод аудио из разных форматов (например VOC или MIDI)

Лучше разработать интефейс, позволит разработать API для использования разных форматов audio.

SDL_native_midi - это не то. Здесь используется аппаратное MIDI (со всеми плюсами и минусами) . Кроме того что делать с другими форматами, например CMF ?

Моя библиотека, кроме всего прочего) как-раз и предоставляет интерфейс

Моя библиотека, кроме всего прочего) как-раз и предоставляет интерфейс

Интересна ваша реализация а-ля vector.
Насколько она более эффективна и почему?

Не думаю что она более эфективная, просто я сначала хотел сделать что-то типа вектора, но заточенное под конкретные нужды , и так оно обрастало и обрастало пока не получился вектор :)

… и так оно обрастало и обрастало пока не получился вектор :)

vector конечно весьма полезен, но он вовсе не панацея для всех алгоритмов, а memory его просто ненавидит.

Нет никаких проблем с консольными утилитами - посмотрите на папку examples/

модулярная

модульная

vector конечно весьма полезен, но он вовсе не панацея для всех алгоритмов, а memory его просто ненавидит.

Пошучу на этот счёт.
Из-за использования объектов а-ля vector весьма вольготно, использующих память и иных «любителей покушать память» browsers
и потребляют гиг памяти при запуске.

что мешает кроме лимитов ОС от гигов памяти «на стеке» ?
и как именно vector вольготно использует память?

и как именно vector вольготно использует память?

Скажем ёмкость вектора 2000000 элементов, так вот когда вам понадобится добавить в него 2000001 элемент, то он произведёт resize размера к возможности использования 3500000 элементов.

не подскажешь, для чего ему сделали метод `reserve()`?

а вот на то же количество сделать «стековый» массив нечто неоднобайтовое — будет действительно ужасно (ну и да — поскольку там нужно будет по максимуму сразу делать из потенциального использования — будет всегда очень много памяти потрачено, даже если она вся и не заюзается).

< не подскажешь, для чего ему сделали метод reserve()?

capacity позволяет изменить.

Не совсем точно ответил.
Далее copy/paste из документации.

Значение инициализации новых элементов, добавленных в вектор, если новый размер больше исходного. Если значение опущено, новые объекты используют конструктор по умолчанию.

именно — теперь это (linux.org.ru) наложить на текущий твой пост... и можно получить ответ самому и сделать соответсвтующие выводы на счёт «вальготности» обращения с памятью.

C++ Vector initial capacity
The capacity of a vector cannot be controlled by the constructors - there is no applicable overload.
The C++ standard doesn't give any guarantee about the capacity of a default-constructed vector vector<Foo> bar;. However all well-known implementations use 0 as the default capacity. This is something you can rely on, as allocating memory at that point just doesn't make sense.
So I believe the answer to your question is: just use
vector<Foo> bar;
bar.reserve(4);

Так понятно?