Пожалуй нативную версию UADx API 2500 можно считать тяжёлым VST. 34 инстанции. То есть 16 инсертов на стерео канале потом этот канал в стерео шину и на ней 16 инсертов и на следующей шине ещё несколько. Интерфейс RME AES32 PCIe. Буфер 32.
CPU для работы с проаудио
- Автор темы AE Ezhkov
- Дата начала
Чем эта катастрофа может мне грозить в будущем? Поделитесь опытом. Возможно я чего-то не учёл.
А частота какая? Uad octo умеет только 32 инстанции Api2500 в стерео запускать при 44.1кгц
Да 44100. На Octo я не пробовал даже. Это нативная версия. И мои 34 инстанции на первой версии UA Connect. Они с каждой версией работали над прожорливостью некоторых плагинов. Думаю сейчас можно на 2-3 инстанции больше.
Садись, два.
Например, берём рекомендации производителя одной из DAW:
Для Windows вместо указания точной модели процессора мы рекомендуем следующие функции...
Высокая одноядерная производительность. Найдите процессор с самой высокой одноядерной производительностью, которую вы можете себе позволить, в пакете с минимум 8 ядрами. Высокая производительность одного ядра желательна, потому что, если какое-либо отдельное ядро не может обрабатывать данные достаточно быстро, не имеет значения, сколько у вас других ядер, при воспроизведении в реальном времени будут возникать сбои звука.
А чем она все-таки так хороша? Я видел эти тесты DAWBench, где Интеля чуть не х1.5 производительность дают с Контактом, когда под ДДР5 работают.
Также я видел тесты, где ДДР5 (на частотах до 6000) проигрывала разогнанной ДДР4 по производительности в игровых бенчмарках.
О каких частотах и таймингах идет речь, для того, чтобы почувствовать реально разницу между ДДР4 и ДДР5 при работе в DAW, that is the question...
У меня-то конкретная проблема, у меня Суп с нейрал дсп лагает) На 6600к))
VSTi - любые или только те, что с сэмплами работают?
По сути, всё, что сейчас есть в распоряжении - это картинка теста гр-на Tafkat c GearSpace, где DAWbench в аля синтетике (никто не может сказать точно по какой методике) показывает при тесте одновременного воспроизведения голосов в Kontakt 6 результат х1.5 в пользу DDR5 с 12900k. В видосе с канала Scan Pro Audio говорят, что память там была 5200...
И вроде как по постам от того же Tafkat выходит, что с DDR5 12900к показывает незначительный прирост в тесте DSP (т.е. просто при последовательном дорожек с плагинами в инсерте).
Как тайминги сказываются на производительности, что происходит на частотах выше 5200 - никто не знает. Ну или я пока не нашел
Ресурсоемкие расчеты уже давно выполняются на GPU.
Мне вот интересно, проникли видеокарты в сферу создания/обработки звука или еще нет.
По логике GPU оптимизированы под float-32, как раз то, что нужно для звука.
А то, может, пора не CPU уже вбирать, а видеокарту.
Мне вот интересно, проникли видеокарты в сферу создания/обработки звука или еще нет.
По логике GPU оптимизированы под float-32, как раз то, что нужно для звука.
А то, может, пора не CPU уже вбирать, а видеокарту.
GPU давно уже мощнее чем процессоры. Но есть какая то причина, по которой они не используются в звуке. Возможно, большая задержка.
Эта причина, что параллельный дизайн DSP - это прыжок сильно выше среднего, тут джус, кукбук и прочие конструкторы "сделай сам" не спасет. И именно поэтому не прекращаются жалобы на тормоза даже на десяткоядерных камнях.
например, готовы ли пользователи платить процентов на 30 больше за тот же алгоритм, но зато оптимизированный подо всё многоядерное?
например, готовы ли пользователи платить процентов на 30 больше за тот же алгоритм, но зато оптимизированный подо всё многоядерное?
@sandriano, @Kokarev Maxim, @basЫl,
Обработка звука распараллеливается гораздо хуже чем обработка видео или инженерные расчёты.
Обработка звука распараллеливается гораздо хуже чем обработка видео или инженерные расчёты.
Почему не получили развития pci-e платы с дсп? разве нельзя сделать плату что будет справляться с аудио задачами?
Мне кажется, Вы отстали от прогресса.)
Вы серьезно?))
да на самом деле многие со зависимые вещи параллелятся плохо, пока не произойдет расчет одного, второе просто не посчитать...т.к. нужно ждать результат первых расчетов.
GPU хорош там, где нужно ворочать огромные матрицы, например для нейронных сетей. Алгоритмы в аудио на GPU выигрыша не поимеют. ТАм данных мало, а алгоритмы сложные. В ИИ наоборот, данных оооочень много, а алгоритмы простые, в плане математики...
CPU -- это универсальный процессор, который работает очень быстро, но с небольшим количеством универсальных данных. Это типа Ферарри -- очень быстро но понемногу. Поэтому когда надо перетащить много, кажется что медленно ))) И «груз» вычислений чаще всего
однопоточный, т.е. можно на разных «ферарри» тащить разные аудиодорожки, но побить дорожку на фреймы и протащить паралельно нельзя. Поэтому важна скорость одной машины -- ядра.
GPU -- это специализированный процессор, который работает сравнительно медленно, но за один такт способен провернуть прорву данных. Это типа фуры, едет медленно, зато везет много. А кажется что быстро ))) Кроме того такие операции отлично параллелятся, в том плане что GPU заточен на матричные операции, и это можно делать блоками.
Для аудио есть отличное реально ультрабыстрое решение -- FPGA, программируемая вентильная матрица. Программировать только запаритесь )))
CPU -- это универсальный процессор, который работает очень быстро, но с небольшим количеством универсальных данных. Это типа Ферарри -- очень быстро но понемногу. Поэтому когда надо перетащить много, кажется что медленно ))) И «груз» вычислений чаще всего
однопоточный, т.е. можно на разных «ферарри» тащить разные аудиодорожки, но побить дорожку на фреймы и протащить паралельно нельзя. Поэтому важна скорость одной машины -- ядра.
GPU -- это специализированный процессор, который работает сравнительно медленно, но за один такт способен провернуть прорву данных. Это типа фуры, едет медленно, зато везет много. А кажется что быстро ))) Кроме того такие операции отлично параллелятся, в том плане что GPU заточен на матричные операции, и это можно делать блоками.
Для аудио есть отличное реально ультрабыстрое решение -- FPGA, программируемая вентильная матрица. Программировать только запаритесь )))
Последнее редактирование:
не так удобно и совсем не мобильно, а это критично в современном мире...ну и финансовый вопрос...если делать одну универсальную, то получим +\- тоже самое что и в нэйтиве.
Мощнее в каком смысле? Они заточены на очень узкий класс многопоточных вычислений, в которых много данных и однотипные алгоритмы. Их производительность кажущаяся.
Ну да, распараллеливание - процесс далеко не механический и имеющий целый ряд существенных ограничений.
Но все-так хотелось бы на конкретном примере.
Вот как я себе представляю: СТЕРЕО - без проблем параллелится на 2 ядра. Больше двух - уже вопрос.
Значит, надо подходить с другой стороны.
Обработка звуков - последовательное применения большого количества разных эффектов. А каждый эффект реализуется своим алгоритмом, который, как правило, также можно разделить на несколько стадий.
Тогда почему бы не представить обработку звука следующим образом:
1. Ядро 1 делает 1-ю стадию эффекта 1 и передает результат ядру 2,
2. Ядро 2 делает 2-ю стадию эффекта 1 и передает результат ядру 3, а ядро 1 в это время обрабатывает уже следующий сэмпл,
3. Ядро 3 делает 3-ю стадию эффекта 1 и передает результат ядру 4, а ядра 1 и 2 в это время обрабатывают уже следующие два сэмпла,
4. Ядро 4 делает 1-ю стадию эффекта 2 и передает результат ядру 5, а ядра 1-3 в это время обрабатывают уже следующие три сэмпла,
...
В результате каждое из ядер имеет нагрузку, которую вполне можно выполнить за отведенное время, например, за 1с/96000 = 10.4 мкс или при частоте 1 ГГц - за 10400 тактов.
Тут, правда возникают два обстоятельства:
- тактика распараллеливания сильно зависит от количества, последовательности эффектов, а также от сложности составляющих их алгоритмов.
- возникает вопрос с операцией "передает", т.к. на современных многоядерных устройствах это довольно длительная операция, которая может свести на нет выигрыш от всех остальных операций. Впрочем, вопрос упирается в архитектуру: ведь DSP именно так и работают.
@sandriano, всё ещё зависит от конкретных плагинов, у некоторых есть буфер и пока он не заполнится, работать не будет. Самый простой пример лимитер с lookahead.
Здесь идеальным выглядит какой нибудь "умный cpu менеджмент", который распараллеливал бы с учётом загрузки ядер системой, а так же индивидуальной структуры обработки внутри проекта. Как я понимаю, сейчас даже при наличии ресурсов системы важно правильно распределить потоки: даже в этой цепочке, если будет перегружено всего одно ядро, добавится лаг ко всем последующим. А, не дай бог, перегрузятся несколько ядер - получим задержку, помноженную на количество ядер, а это значительно хуже, чем проблемы одного ядра.
Понял принял. Я относительно графики и нейросеток и размышлял - там в сравнении с cpu разница то огромная.
Ну камон, один никому не известный проект? Это лишь редкое исключение.
