Почему вообще существует проблема игольного ушка asio? Если это чисто программная реализация,то там же можно было ушко и пошире сделать,как я понимаю. Или это проблема на уровне железа?
Core Audio vs. ASIO (2 онлайн)
- Автор темы Anton_OSC
- Дата начала
@Гуманитарий, В силу нереалтаймовой природы потребительских осей процу гораздо легче перерабатывать большие объёмы данных, но делать это реже (т.е. ему гораздо комфортнее при работе с большим буфером). Т.е. ему намного легче наполнить водой условную бочку воды, таская её вёдрами. Но многие пытаются заставить его таскать воду бегом в ладошках, а потом удивляются - почему это неэффективно, да ещё и расплёскивается по дороге (те самые выпадения сигнала в виде щелчков и треска при малых значениях буфера).
С современными компами уже нет никакой проблемы с ASIO и low latency, ASIO Guard (anticipative Fx) также отличная штука.
Носят значит 99 бравых хлопцев воду вёдрами, ну, а одному приспичило в ладошках потаскать, но так чтобы сандалии дымились, ну дай Боже ему здоровья.
П.С. Только лучше нормальный интерфейс, чтобы всё-таки он в стакане с крышкой таскал.
Носят значит 99 бравых хлопцев воду вёдрами, ну, а одному приспичило в ладошках потаскать, но так чтобы сандалии дымились, ну дай Боже ему здоровья.
П.С. Только лучше нормальный интерфейс, чтобы всё-таки он в стакане с крышкой таскал.
Последнее редактирование:
Хорошо, напишите Вы.
Бравые хлопцы - это треки, на которых не активирован прямой мониторинг. Вёдра - это большой буфер, т.е. включён режим Anticipative Fx
Индивидуум - это трек с прямым мониторингом, который работает на буфере, который выставлен в настройках.
Что не так?
Последнее редактирование:
Не так то, что при слабом процессоре ваших бравых хлопцев не спасёт ни какой буфер выставленный в Anticipative Fx, да и для индивидуума прийдётся ставить буфер большой.
Так что - всё по прежнему, чем мощнее процессор, тем удобнее работа.
Ну, наверное, под современными компами, я имел ввиду не пентиумы первые, как думаете?
Мне пока не доводилось поработать на таком компе, чтобы можно было вообще ничего не фризить и не думать о производительности. Но до меня доходили слухи, что уже есть какие-то компы, которых кому-то полностью хватает.
Да и блин, это такая бесконечная гонка -- производительность железа против пофигизма разработчиков, которую невозможно выиграть. Сколько производительности не дай, всю задействуют и всё равно будет мало
Да и блин, это такая бесконечная гонка -- производительность железа против пофигизма разработчиков, которую невозможно выиграть. Сколько производительности не дай, всю задействуют и всё равно будет мало
И по-прежнему низкий буфер - это стрессовое состояние для проца.
Так я не думаю, я всё сам проверяю.
Как на мои запросы - мне нужен комп с 16 ядрами и частотой ядра где то 50-60 Ghz, тогда я на время расслаблюсь.
А пока - даже на самых мощных процессорах очень быстро добираюсь до их предела возможностей.
Anticipative Fx устроен чуть сложнее, чем просто больший буфер для треков без записи и мониторинга.
Добавлено:
101%
Ну….., не только пофигизма, увеличение мощности даёт возможность радивым программистам создавать более точные и сложные алгоритмы.
Компьютеры - машины универсальные, с ростом производительности проца растут и запросы (прерывания) современных осей (фон. процессы, службы и пр. резидентные проги).
Вот это вот всё - вредоносные и не нужные для нас плюшки, которые производители Винды и Мак Оси могли бы и дать отключать ВСЕ одним кликом, чтоб не нужно было заниматься этим всем по одной службе.
Да уж, разбежались! Я думал Линух в этом отношении лучше, но там тоже самое. Хотя если шарить можно сделать его под себя, Archlinux.
@N0-body, Тут даже ещё хуже... не только не пытались, а когда-то попросту убили то, что уже было создано (BeOS).
Линукс пока нативно не будет поддерживать VST3 - нафиг ни кому не нужен. Да и настраивать его нужно так же как и Win 10.
Это было бы очень дорого. Осы потому и дешевые, что стараются быть универсальными и для всего сразу. В лучшем случае может быть чтото типа репака со всеми обрезанными ненужностями. Но с поддержкой новья будет полный швах и ее нужно будет перепиливать ежегодно. И это врядли будет стыковаться с правообладателями
А откуда там будет лучше - это такая же нериалтаймовая ОС как windows или macOS. Так что там все те же самые грабли. Как только одно ядро загружается полностью, ждите дропаутов, сколько б других свободных ядер у вас ни было.
Только это и требуется. Отсутствие мусора, долгий цикл обновления (мажорная версия раз в 3-5 лет), только багфиксы между мажорными версиями.
Кстати, серверная винда выпускается именно так. Я когда-то во времена XP использовал вместо неё windows server 2003 потому что она почему-то работала гораздо лучше. Может это и сейчас имеет смысл попробовать, не знаю
Там же как-то можно скомпиллировать реалтаймовое ядро. И решения есть работающие... ну тот же Receptor или Waves Soundgrid Server... или Korg Kronos.
Что-то я о таком не слышала... да и в любом случае, даже если ядро риалтаймовое, приложения тоже должны быть в ядре... может, я, конечно, сильно отстала, и на базе (а скорее по мотивам) линукса сделали риалтайм ОС, которую как-то также назвали... но это уже точно не обычный Линукс.
Receptor - вроде самый обычный комп. Да что там, Maschine+ даже самый обычный комп кажется. Ну да, разумеется стараются оптимизировать ОС по максимуму. Но... Про Waves/Korg не знаю, но сильно сомневаюсь.
Можно, в интернете полно информации. Так же на этом крутятся и новые MPC, и все энтузиастские распберри-подобные проекты
C VST-хостом на Линуксе. А про Waves даже ветка на ГС есть по сборке самопального сервера с осью на основе некомпилированных исходников, выложенных самим Waves.
Не совсем так. Линукс - это ядро (с набором дистров вокруг) в котором есть возможности рт реализации, причем уже очень давно.
Кроме этого, есть ещё юникс подобные системы на базе *BSD, которые используются ещё чаще всеми, кому не лень, начиная от Плэй Стэйшн, заканчивая маршрутизаторами, но это скорее уже вопросы лицензирования
Нууу, с этим в линупсе проблем нет от слова совсем, они скорее даже обратного характера: как ненужные выгрузить из ядра