Ну понятное дело, если на мастершину повесить жручий плагин - то оно все съест. На пальцах все примерно так - представьте, что у Вас есть 5 треков и одна мастершина. Плюс многоядерный комп. Обработка будет выглядеть так - данные треков будут себе спокойно параллелиться, а вот обработка мастершины будет стоять, пока не будут приготовлены все данные по трекам. Когда они будут приготовлены и просуммированы - то будет запущена обработка мастершины.
Теперь ситуация чуть сложнее. Пять треков, два из них посланы в ревербератор, выход ревербератора на мастершину (треки, естественно, тоже на мастершину идут).
Что получаем: треки обработали параллельно, ревер и мастершина ждут готовности данных от треков. Как только они готовы (те два, которые посланы в ревер) - запускается ревербератор, а мастершина еще стоит (потому что ей не только данные от всех пяти треков нужны, но и от ревера). Как только ревербератор закончил свою работу - запускается мастершина (т.к. теперь у нее есть все данные), ну и дальше на выход.
Понятное дело, что если ревер тяжелый (ну, например, длинный импульс) - то ситуация с производительностью сильно усугубится. Правда, есть два позитивных момента - есть ревера, которые умеют свертку делать в многопотоковом режиме, и второй - скажем, два ревера в такой ситуации обработаются параллельно.
Аналогично, всяких мастершин может же быть несколько в проекте, если это, скажем, сетап для лайва - всякие мониторы вполне можно рассматривать как отдельные мастершины.
Давайте я Вам расскажу, как у меня устроены проекты для лайвов:
Понятное дело, входные каналы/треки, понятное дело, их обработки (всякие гейты/компрессоры/эквалайзеры), потом это все в группы (ну там гитары, барабаны, etc). Тут как бы все вполне достойно распараллеливается - потому что все достаточно независимо - сначала отдельные каналы, потом несколько параллельных групп. Какие-то посылы в ревербераторы (отдельные на вокалы, отдельные на инструменты, отдельные - в мониторах) и посылы на шины мониторинга музыкантов (пусть это тоже называется мастершинами). Выходы ревербераторов, понятное дело, направлены на нужные мастершины. Т.е. достаточно такой развернутый вариант топологии, описанный выше.
Что тут можно сделать для улучшения ситуации с производительностью? Ну так как основную жручесть проявляют сверточные ревербераторы (а еще и именно они ждут, пока все данные будут готовы, а их готовности ждут все остальные мастрешины), то я сделал вот что - завел несколько пар выходов-входов в виде лупбэков, посылаю сигналы не непосредственно на ревербераторы, а на выходы, которые через цифровой лупбэк попадают обратно на входы, на которых стоят ревербераторы. Выходы ревербераторов уже идут на мастершины.
Что получается в такой схеме:
Треки обрабатываются, но в это же время обрабатываются сигналы реверберации (правда, они задержаны на время одного буфера ASIO, но это же просто плюс, скажем 1-2мс к предилею, что не является проблемой). В результате данные реверберации и данные треков готовятся уже не последовательно, а параллельно, а значит - раньше готовы по времени, чем в обычной ситуации. Потом у нас происходит суммирование на мастершинах сигналов треков и сигналов реверберации, и суммирование посылов в лупбэки (то, что на следующем цикле ASIO попадет в ревербераторы).
Мастершину, которая валит в зал в таком сетапе, можно тоже обернуть разок через лупбэк - для того, чтобы повесить какую-то тяжелую обработку, скажем, какой-то плагин выравнивания АЧХ. Эта обработка будет выполнена параллельно с обработкой треков и реверберацией, а дополнительная задержка на выход в зал на один буфер - это не принципиально. Мониторные линии так не стоит оборачивать, это да, потому на них лучше обработку не вешать слишком яростную - выбирайте мониторы музыкантов, которые можно эквализировать до вменяемого результата простенькой параметрикой, а не огромными FIR-фильтрами
Вот такие пироги. Я как раз себе комп студийный собрался апдейтить, но не по ГГц, а по ядрам. 4->10. Мне с такой схемой самый сок будет.
