лоджик выдает такую вот ошибку

  • Автор темы Автор темы molbn
  • Дата начала Дата начала

molbn

New Member
24 Янв 2008
35
0
0
Всем привет! Во время работы лоджика стало выскакивать сообщение о перегрузке:

System Overload.
The audio engine was not able to process all required data in time.
(-10011)

что делать?

у меня:
макбук
ось леопард
лоджик 8
120 жесткий
1 гиг оперативки

PS хочу сразу предположить, что это как то связано с моим аудиоинтерфейсом (коннект 24д) и аудиокором макбука, когда копаюсь в настройках аудио в лоджике, там есть i/o buffer size и параметры от 64 до 1024, так вот когда я их по всякому переключаю, то на некоторое время проблема решается, но потом опять начинает выдавать
 
Последнее редактирование:
У меня похожее сообщение периодически выскакивает только там написано
"disk too slow". в принципе не обламывает (появляется редко) но хотелось бы узнать может это тоже решаемо тоже какой-нибудь галкой? спасибо.
 
попробуй убрать галку с i/o buffer

да уже запарился убирать - уберешь, не появляется, затем опять появляется, снова ставлю галку не появляется до поры до времени, а потом опять напрягает да так, что через каждые три секунды!
И ЕЩЕ ХОЧУ ПОЖАЛОВАТЬСЯ - лоджик, да и сам макбук стали зверски тормозить - аж бесит! Кто знает, где нужно чего подчистить чтоб опять быстро работал???
 
Последнее редактирование:
Disk Utility/Repair Permissions.
Еще говорят можно чистить кэш. Но точно не скажу. Может папки Cash? Но в какой именно директории не помню. Они есть и в юзере и в библиотеке и в системе.
 
molbn написал(а):
хочу сразу предположить, что это как то связано с моим аудиоинтерфейсом (коннект 24д)
Коннект вообще по глюкам чемпион среди звуковых карт. Попробуйте увеличить буфер в лоджике. Может у вас диск полон?
 
на диске еще 40 гигов
менять размкер буфера немного помогает но лишь на время
короче достало меня это все!
 
Попробуйте все таки подключить и проверить на другой Firewire звуковой карте. Если там заработает нормально, значит коннект виноват. Если нет, значит в программе надо копаться. Может из за плагинов каких сторонних? Лоджик не любит мелодин.
 
да буфер карты и все тут ну и лардж для подстраховки как ранее сказано было, но не принципиально
 
Дело в коннекте 24. (в настройке латенси ) в лоджике оптимально 250
Хотя после 2х летних мучений с коннектом я ничему не удивляюсь (в результате я с ним расстался и не жалею)
 
Такие приколы бывают и на маках с 4 гигами и с разными установками.похоже,это совокупность засорённости системы,хотя и говорят ,что на маках этого не может быть,системных установок лоджика(буфер,кэш и т.д.) и....пофигизмом написания программы программерами Эппла.как ни странно на Винде с 5.5.1 это у меня бывало редко.похоже ,что Лоджик при первых попытках воспроизведения оптимизирует память,подчитывает в кэш..а потом начинает работать.у меня это бывает даже на небольших проэктах.
 
У меня вот посмотрел, только один лоджик гигабайт оперативной памяти занимает в среднем проекте. А еще маку надо для системы, а они с давних времен были жручими до памяти.

Ну глюки-то могут быть действительно не в этом. Но память бы хорошо расширить все равно.
 
Может опять русский язык первичный стоит?
 
Меня тоже достал этот систем оверлоад.
Машина 2на 2GHz Dual-core. 3гига оперативки.
Что делать?
 
Хороший совет. :padonak: Только саму проблему это не уберет, только лишь уведомление о ней. А проигрывание проекта может в любой момент остановится. Это, к сожалению, баг программы. Короче говоря, вся надежда на новые апдейты лоджика, иначе придется с ним попрощаться.
 
проблема программы и ее совместимости со сторонними плагами...
если не писюшный Эблтон, то может тогда про тулз с заменой железа? всерьез задумался, ибо работать просто невозможно...
 
Я такой проблемы не замечал, попробуйте почистить систему программой Onyx. У меня хак на АМД 6400+ и карта PCI RME.
Еще полезно раскидывать нагрузку по ядрам процессора - ведь каждый channel strip идет только на одно ядро, если обработки сделать последовательно на несколько BUS то нагрузка раскидывается по количеству этих BUS по ядрам процессора.
 
Disk Utility/Repair Permissions.
Еще говорят можно чистить кэш. Но точно не скажу. Может папки Cash? Но в какой именно директории не помню. Они есть и в юзере и в библиотеке и в системе.

наешешл я эту папку, library/cashes.... там в ней файло, системное кажеться, его точно можно удалить?
 
а что она означает?

вот кстати недавно, лазил я по настройкам, поставил эту галку из любопытства вечером перед окончанием работы. А утром долго не мог понять, почему лоджик ни с того ни с сего стал затыкаться на ровном месте. Вспомнил, убрал и всё опять стало ок.

Наверное она организует дополнительный буфер записи, но при этом за счет дополнительной нагрузки на проц. Возможно ее имеет смысл ставить когда комп мощный (у меня не особо, G5 PPC еще)
 
2автор:
какая версия лоджа? 8.02? если нет - обновись.


2all и автору:
посмотрите все внимательно на равномерность загрузки ядер при работе с лоджем. частенько вы видите, что 1е ядро на себя берет основную работу, и когда лодж стартует с места где одновременно много дорог - он может затыкаться.
солюшен откопал где-то на эппловских форумах. Чаще посылайте out'ы с дорог на различные aux-ы и "щастье" будет. вот тут то многоядерность проца начинает отрабатывать в полной мере.
я думаю все или многие посылают несколько дорожек с перкуссиями на какой-либо bus(aux), то же самое делайте с вокалом, лидами, пэдами..
это работает - проверял на себе.
да возьмите хотя бы трек Plaid с последнего диска к лоджу, разфризьте все дорожки - вот там как раз все более менее равномерно распределяется.
 
я вам больше скажу... часто при открытии следующего по счету проекта возникает аццкий скрежет на немерянных децебелах... либо пропадает правый канал, индикатор нагрузки винчестера при этом зашкаливает, каждый раз такое... Пропадает при многократном запуске-стопе, желательно без звука)))) От ошибки спасает перенос данных треков в новый созданный проект, но, согласитесь, это ни разу не вариант.
мне вообще иногда кажется, что до обновления лодж работал стабильнее... вот и гадай теперь... точно на диджи надо пересаживаться.
 
Увеличил память с 4гб до 8ми, почистил ониксом систему, им же дефрагментировал, равномерно распределил нагрузку по аукс шинам. Установил лоджику максимальный приоритет в системе. Этот комплекс мер помог.

Тестовый "грузный" проект проиграл 8 часов без ошибки System Overload. В лоджике показывал нагрузку около 80% на каждое ядро. В Activity Monitor - около 65%. Больше нагрузить не удается, начинает периодически выдавать System Overload.

В принципе доволен. Убрал в лоджике индикатор CPU/HD, теперь можно спокойно работать, а не на датчики смотреть.
:to_become_senile:
 

Сейчас просматривают