Sonar и производительность HDD на больших проектах (1 онлайн

[Kokarev Maxim]

Сразу оговорюсь, что проблемы со щелчками или дропаутами у меня нет. Но есть неприятная штуковина, которая... съедает моё время и ощущение комфортной работы. Итак.
В последнее время, при работе с большими проектами (более 50 аудио треков) заметил, что Сонар не мгновенно реагирует на нажатие кнопки Play, а с 3-4 секундной задержкой (в эти секунды непрерывно горит лампочка hdd, похоже на предварительное кэширование), + примерно 1 секунда "подвисания" после остановки воспроизведения. Это очень неприятно, особенно, если учитывать, что за время работы этих Play/Stop'ов огромное количество и с каждым я теряю 5 секунд.

Пытаясь самостоятельно разобраться с проблемой, я создал тестовый проект из 50 аудиотреков по ~4 минуты каждый (отмечу, это не один аудио файл, скопированный на 50 треков - это 50 разных аудиофайлов на 50 треках), без прочей обработки, загрузка CPU около нуля. Задержка есть, игра с настройками буфера ничего не дала. Уменьшая количество треков, задержки менее 1с. я добился при количестве 5 дорожек...
Далее. Создаю аналогичный проект в Samplitude, аудио файлы в той же папке - старт/стоп практически мгновенный, прогресс бар буферизации мелькает, но это происходит в доли секунды.

От версии Сонаров тоже ничего не зависит, проверял на 8.5.3 и x2.

В итоге, в чём может быть причина?

1. Известная проблема Сонаров и единственное хоть какое то решение - брать быстрый HDD?
2. Или всё же есть какие то настройки в Preferences или AUD.INI, которые помогут убрать эту фичу?
3. Может я что-то упустил, возможно индивидуальные проблемы моей системы. Как у вас, можете протестировать по технологи описанной выше?

По проблеме нагуглить ничего не получилось, по форуму тоже ничего не нашёл.

 

[cherkes]

Галки с Enable Read/Write caching в настройках audio - sync and cache сняты?

 

[Kokarev Maxim]

cherkes, это в первую очередь пробовал. Точнее, пробовал их ставить, ибо сняты они у меня всегда по умолчанию.

 

[dromax]

у меня была проблема при записи треков 12 примерно, тоже зависал ... как ни странно, виноват был Касперский.
Сонар 8.5

 

[Magnusstudio]

Гы гы, в Лоджике бывает секунд 10 до стопа играет, можно перекурить выйти пока оно остановится...:scared:

 

[Osman]

Hdd под аудио отдельный?

 

[Kokarev Maxim]

Osman, да, конечно.

dromax, у меня avira. пробовал отключать - безрезультатно.

Гы гы, в Лоджике бывает секунд 10 до стопа играет, можно перекурить выйти пока оно остановится...:scared:

Как то это не радостно


Ребята, если кто таки созреет до простого практического эксперимента (50 разных файлов на 50 аудиотреков, измеряем время от нажатия кнопки до старта воспроизведения), сильно поможете. Есть подозрение, что это фича и вообще не лечится...

 

[smack]

Аж заинтриговали... Поднял недавнюю работу. Один проджект - длина 20 минут, 94 трека - старт примерно через пару секунд, а в более легких местах (там, где треков около 50) - старт почти мгновенный.

Другой проджект - длина 10 минут, 63 трека - та же картина...

Файлы, естественно, разные - работа реальная, а не экспериментальная.

На всякий случай сообщу: все на разных винтах - система, проекты, библиотеки, архивы...

 

[smack]

cool, пробежался по докам - нигде подобное не обсуждается, в основном о latency - но у вас суть иная...
Интересно будет узнать, как все разрешится.

На всякий случай, путем полунаучного тыка (хотя проблема немного иная - выпадение аудио при максимальных значениях latency):
если размер буфера в закладке General (Audio Options) даже превышает буфер диска, это не выход. Повышая latency, необходимо также увеличить размер буфера диска в закладке Audio Options - Advanced - I/O Buffer Size
Вдруг такой танец поможет?

 

[Kokarev Maxim]

smack, спасибо, пробовал. И похоже проблема не в настройках. К сожалению...

Итак, есть неприкольные открытия. Сравнил "влоб" с Samplitude и Reaper. Если первый стартует и останавливается практически мгновенно, то у Рипера близкая к Сонару проблема: эпизодически (!) он стартует с 2-3 секундной задержкой, причём, чем ближе к началу проекта, тем меньше вероятность этих "медленных стартов", а ближе к концу 3-х минутного проекта едва ли не каждый второй раз.

Копая глубже, я проследил за интенсивностью обращения к HDD всех трёх DAW. Скриншоты встроенного в Виндовс7 монитора ресурсов (проект лежит на диске D):

В свободное время ещё попробую поковыряться с AUD.INI, но уже почти отчаялся - пока кроме покупки быстрого hdd в голове нет идей.

upd.
Потестил зависимость от скорости hdd. Один и тот же проект на самом быстром диске (sata2, ~100mb/s) и самом медленном (ide, ~55mb/s) с секундомером в руках. Отклик отличается ровно в два раза: 2 секунды на быстром и 4 секунды на медленном. В итоге, похоже я пришёл к единственному решению - покупке быстрого диска для рабочих проектов. Эхх, а если бы много лет назад выбрал Samplitude, сэкономил бы на покупке диска

 

[smack]

cool, так вы работаете на ползучем IDE? А скорость не 5400? Даже такой консерваторы, как я, давно уже перешли на более быстрое ) Так что ларчик просто открывался. Ничего, купить новый винт - не самое тяжкое ).

И спасибо за эксперименты. Результаты пригодятся всем в случае подобной ситуации.

Кстати, еще некоторые мелочи, позволяющие снизить затыки: дефрагментация, только не штатными средствами. Я дефрагментирую диски разными методами, в зависимости от содержимого: системный - Сomplete/Modified - не затрагивает неизменяемые системные файлы; библиотеки - Complete/Name (файлы выстраиваются внутри директорий по названиям, что минимизирует "порхание" головки. Есть еще режим Complete/Access, который дефрагментирует файлы, к которым идет частое обращение.

Попробуйте, вдруг будет ощутимый результат.

 

[Kokarev Maxim]

так вы работаете на ползучем IDE?

Неее Просто старый винт подключил для теста. Основные у меня sata на 7200, правда и они уже староваты и медлительны.

 

[NIKEs11]

Недавно сводил проект, где было в районе 70 дорожек (некоторые просто дублировались, но тем не менее). Под конец сведения мало того, что сонар начал воспроизводить проект с 3й-4й секунды, так у меня ещё и отказала вся прописанная автоматизация уровня громкости send-посылов (ревера, дилеи).
В сонаре есть на каждой дороге значёк W (запись автоматизации) и R (чтение автоматизации). Так вот, когда была нажата кнопка R, автоматизированные фейдеры становились в положение 0 и не менялись. Автоматизация начинала работать только при нажатии записи (W). Пришлось всё в режим записи поставить, а это не удобно.

Было ли у кого такое? Проблема появляется исключительно в загруженных проектах (не 1й раз такое).

 

[Osman]

Кстати, еще некоторые мелочи, позволяющие снизить затыки: дефрагментация, только не штатными средствами

А чем дефрагментацию делаешь, Влад? Прога какая в смысле?

 

[smack]

O&O Defrag. Масса настроек, гибкий. Но, ЕМНИП, в 64битной семерке не работает.

 

[Alf_Zetas]

чепуха и разводилово все єти альтернативные дефрагментаторы - они все работают через виндовый АРІ и отличаются друг-от-друга только мордой-лица. И только штатный (и отнедавна еще парочка каких-то) умеют пользоваться базами данных и результатами анализов префетчера для оптимального размещения файлов.

ЗЫ Что касается семплов, то они читаются по списку в патче, а не по алфавиту. К тому же когда библы заливаются на винт, файлы как раз копируются и размещаются по алфавиту - потом лежат так себе годами и ни в какой дефрагментации не нуждаются.

ЗЗЫ самый оптимальный вариант в командной строке
defrag C: /B /U

вместо С: подставляем букву нужного диска

 

[Kokarev Maxim]

Было ли у кого такое? Проблема появляется исключительно в загруженных проектах (не 1й раз такое).

Было подобное, плюс, не отображался интерфейс некоторых плагинов. У меня такая ерунда начиналась, если Сонар занимал оперативной памяти больше, примерно, 1.2 гигабайта. Это в диспетчере задач можно посмотреть, для процесса SONARPDR.EXE. Ну и решение у меня было очевидным - фризил вст инструменты, а чуть позже бриджил вст плагины, чтобы запускались отдельными процессами.

 

[Victuar]

только штатный (и отнедавна еще парочка каких-то)

Какие именно?

 

[PaulVadim]

А оперативки сколько стоит на компе, и какая Винда?
Помнится менял ритм-секцию в оркестровых мультисессиях. Около 60 аудио-треков, плюс BFD, Kontakt с кучей сэмплов и пару VST-синтов.
Не сажу, что тормоза были сильными. Заметил пару особенностей.
Чем больше склеек, тем труднее "взлетает" проект.
Если не используемые при редактировании треки переместить в folder и свернуть с экрана, то почему-то проект начинает работать легче.

 

[Alf_Zetas]

Какие именно?

я их имена не запоминал, т.к. считаю любые сторонние дефраги бессмысленными

 

[Kokarev Maxim]

А оперативки сколько стоит на компе, и какая Винда?

Windows7, 4 (3.2) гигабайта оперативной памяти.

Проблему я решил. Просто взял SSD "на убой" для рабочих проектов (планируется последующее архивирование на HDD). Тестовый проект стартует очень быстро, секундомером не успеваю оперировать, но на глаз это примерно 0.5с или даже меньше. При гарантии на диск 5 лет, если он протянет в таком режиме хотя бы года два-три, это будет победа

 

[NIKEs11]

Интересно, решится ли таким способом проблема с автоматизацией? Не могли бы проверить? Был бы благодарен!

p.s. Моя система: Win 7 64x, 12гб оперативки, проц - i7 3.4 Ггц, так что может это и не связано с ОЗУ...

 

[Kokarev Maxim]

Интересно, решится ли таким способом проблема с автоматизацией? Не могли бы проверить?

Так у меня нет проблем с автоматизацией после ситуации, о которой я говорил выше. Ещё давно я пробриджил все тяжёлые плагины и не знаю бед. У вас 64 битная система, не знаю как в ней ведёт себя Сонар, но в 32-х битной у меня было всё предсказуемо: если процесс SONARPDR.EXE раздувался больше 1гигабайта, начинались глюки. После использования jbridge (в частности на Контакте) даже с огромными библиотеками SONARPDR может занимать 300-500мегабайт памяти. Повторюсь - это всё наблюдения по 32-х битной системе, в 64 я не работал.

 

[NIKEs11]

После использования jbridge (в частности на Контакте) даже с огромными библиотеками SONARPDR может занимать 300-500мегабайт памяти.

Понял, спасибо. При использовании jBridge у меня проекты грузятся только в SafeMode. :sad:

 

[alikdio]

cool,

Ещё давно я пробриджил все тяжёлые плагины и не знаю бед

Будьте любезны, расскажите, что такое бридж и как это делается
уже не надо, проясняется.

а также, что есть тяжелые плагины, можно примеры?

 

[Kokarev Maxim]

alikdio, "тяжёлые" - те, что много оперативной памяти занимают. Сэмплер "Kontakt", например.

 

[CakeWorker]

"Kontakt", например.

Или Superior2...

 

[Microtonic]

Сэмплер "Kontakt" сам по себе много не жрёт оперативки. Жрут библиотеки, которые туда загружаются. Можно загрузить скрипки на 3 гига, а можно простой синтезатор на 50 мегабайт.

 

[radarik]

Заметил пару особенностей.
Чем больше склеек, тем труднее "взлетает" проект.
Если не используемые при редактировании треки переместить в folder и свернуть с экрана, то почему-то проект начинает работать легче.

Да, я заметил такую, постоянную причем, особенность... А лечится пересчитыванием отображаемой волны, выделить все - свойства клипов ( альт энтер) - пересчитать картинку(rucompute pictures). При следующем открытии этого файла - та же фигня, приходится еще раз все пересчитать... Либо закрывать в папки.

 

[Microtonic]

А кто как максимально загружал Sonar X2a? У меня складывается такое ощущение, что если у меня загрузка оперативки уходит больше 8 гигов (а физически у меня 16 гигов, и свободной памяти ещё где-то под 5 гигов) и подгружено 10 Контактов и более, то Sonar X2a всё чаще уходит в небытие.

У меня сложилось такое впечатление, что Sonar X2a не любит тяжёлые проекты. Сложилось впечатление, что старый Cubase 5 x32, работал стабильней в тяжёлых проектах чем Sonar X2a x64.