Optymalizacja systemu pod pracę z muzyką (Ableton Live!)

Dzisiaj odrobina teorii połączonej z praktyką. Ostatnimi czasy miałem dość spore problemy spowodowane niespodziewanym uszkodzeniem dysku HDD firmy Seagate (a jakże). To już kolejny dysk tej firmy, który odmówił mi posłuszeństwa z tym, że tym razem na poważnie – uszkodzeniu uległy głowice, zapiłowane talerze i tego typu sprawy. Dam sobie rękę uciąć, że nic z dyskiem nie robiłem, żadnych wstrząsów, zamontowany był w porządnej obudowie na gumowych podkładkach a wiatr z dwóch 14 cm wiatraków owiewał go lekką bryzą powietrza (max. 40 stopni) . Słowem – prawie idealne warunki do pracy. I jeb, skończyło się. Pech chciał, że dwie najważniejsze partycje miałem właśnie na tym dysku. Backup szczątkowy ale udało się odzyskać połowę pracy. Ale nie o tym miało być – gdy już kupiłem nowe dyski (tak tak, jeden na backup) to przystąpiłem do reinstalacji systemu. Jako, że dawno nie aktualizowałem kompa w myśl zasady „nowe jest wrogiem dobrego”, tym razem postanowiłem nadgonić zaległe 2 lata. Poszedł update BIOS’u, Maverick ustąpił El Capitano , Windows 7 dostał serwis Pack i przesiadłem się w na Ableton 9.5 (akurat zbieg okoliczności, że nowa wersja wyszła właśnie w czasie moich zmagań z instalacją kompa). Tu należy się chwila wyjaśnienia – ja wyznaję zasadę dwóch systemów – jeden do muzyki a drugi do internetu i ogólnie „pracy”.

Powoli dochodzimy do sedna – gdy już wszystko zostało zainstalowane – odpaliłem swoje uratowane projekty i … jeb po raz drugi. Nie nie, to nie dysk – to meter w Abletonie. Skacze conajmniej jak opętany kangur z piosenki posła Liroya. WTF sobie myślę pamiętając, że przed reinstalacją meter zachowywał się normalnie. Oczywiście, czasem sobie podskoczył na chwilę np. z 30% na 50% ale potem spokojnie wracał do poprzedniego stanu i było wszystko pięknie. Zero dropów na buforze 256. A teraz? Projekt wczytany, połowy pluginów nie ma, NIE GRA a meter skacze. A jak włączę PLAY to dropy za dropem i dopiero ustawienie bufora na 2048 powodowało, że można cokolwiek posłuchać. Co więcej – podobne zachowanie występowało nawet na czystym projekcie przy pojedynczym instrumencie typu Massive… O nie, tego było za wiele !! Problemem zajmowałem się prawie miesiąc, przeczytałem setki porad, wertowałem forum’y wzdłuż i wszerz aż w końcu znalazłem … znalazłem cholernego chwasta … a było nim – uwaga, werble – oszczędzanie energii. Ale nie to software’owe w Windowsie czy OSX, nie nie – przyczyną był SpeedStep Technology w BIOS’ie. Okazuje się, że ta „genialna”, Intelowska technologia pozwalająca na dynamiczną zmianę wartości mnożnika i napięcia pracy niektórych procesorów tej firmy zupełnie nie sprawdza się z zadaniach audio. Nie wnikam dlaczego tak się dzieje, ale fakt jest taki, że po wyłączeniu tego dziadostwa, moje stare projekty zaczęły żyć tak, jak kiedyś. Znów bufor 256 zagościł na stałe … komponowanie znów nabrało barw … a jakbyście chcieli przy okazji trochę podpimpować swoją windę pod kątem pracy z dźwiękiem, to polecam sprawdzić ten link. Zwłaszcza, jak macie sporo dropów.

Dajcie znać w komentach czy ta sztuczka przyniosła zauważalną różnicę w zachowaniu programu (wydaję mi się, że inne programy powinny w podobny sposób reagować). Przypominam, że nie wszystkie procesory mają tę technologię to raz, nie wszystkie BIOS’y dają nad nimi kontrolę to dwa a trzy – posiadacze maków muszą obejść się smakiem. Można co prawda próbować grzebać w Kext’ach i próbować wyłączyć SpeedStep’a ale nie ręczę za późniejsze prawidłowe działanie maka.