Forum Magazynu Estrada i Studio

Witajcie.

Czas pogadać na tematy które zaczynają doskwierać tym którzy na potęgę wykorzystują nowoczesne komputery do pracy z DAW.

 Nadeszły czasy kiedy wielordzeniowe procesory są zbyt wydajne w stosunku do możliwości aplikacji.

Wiedzą o tym szczególnie ci którzy lubią pracować w trybie online i mieć wszystko wyliczane w realtime. Zarówno partie midi jak i procesory sygnałowe.  Bez freezowania.  Są tego oczywiste korzyści - mniejsze zużycie dysku, miejsca na dysku, możliwość łatwej korekty/edycji czy transpozycji lub zmiany tempa. Wszystkich plusów trudno wypisać.

Ale w całej tej pięknej sielance nieograniczonych, wydawałoby się,  możliwości jest coś co skutecznie ukróca nasze nasze nieograniczone ambicje.

Mianowicie:

1.  Złożone projekty audio-midi  szybko zapychają system DSP w naszym DAW. Efekt jest taki mając zużycie 4 rdzeniowego CPU na poziomie 30% system DSP oscyluje w granicach 90%.

Przykład - Superior Drummer z ustawionym pełnym zestawem procesorów w mikserze obciąża DSP około 13%. Kiedy CPU oblicza to lekko paroma procentami.

2. Asynchroniczna praca rdzeni powodowana różnym czasem zakańczania różnych zadań w sesji. Często widzimy sytuacje gdzie jeden rdzeń idzie na full, drugi na na połowę a reszta na 40%. Przy czym DSP idzie na max. Zadanie wykonane szybciej czeka na pozostałe.

Oczywiście każda sesja zachowuje się inaczej gdyż wynika to z konfiguracji sesji. Ile BUS'ów, SUB mixów czy insertów na ścieżkach czy sekcji master. Czasami udaje się obciążyć CPU mocniej. Szczególnie w mniej skomplikowanych sesjach ale obciążonej jednostkowo cięższymi zadaniami. Sytuacja dotyczy oczywiście wszystkich DAW'ów.  

Mam tutaj jedno pytanie.  Na czym dokładnie polega wyliczanie % zużycia systemu DSP. Do czego się konktretnie odnosi?  Gdyż nie jest to procentowe zużycie mocy CPU. Na moje oko jest to wykaz możliwej do wykorzystania mocy ustawionym buforze do pracy z niskim poziomie latencji.  Ale skoro tak jest,  to jaka przyszłość nas czeka?  Ze CPU będa sie rozwijały a my będziemy ograniczeni poprzez DSP? Jak rozwiązać ten problem, czy da sie to załatwić zmianą/ulepszeniem protokołu ASIO, komunikacji miedzy interfejsem a aplikacją.

Gdzie konkretnie leży problem? Na dłuższą metę jest to poważne ograniczenie.

Czekam na jakieś ciekawe informacje od ludzie którzy temat znają od strony programowania i są to wstanie jakość łatwo przekazać.

Pozdrowienia!

Lukas

ASIO ma już parę lat - i jak do tej pory dobrze się sprawdza, sam protokół niczemu winien nie jest. Problemem są 4 rdzenie, różna ich współpraca, oraz optymalizacja DAW przez programistów - tu jest pies pogrzebany. Należy też pamiętać że rdzenie nie współpracują ze sobą na zasadzie niezależności, jakbyśmy mieli 4 procesory - inna jest troszkę konstrukcja AMD i Intela jeśli chodzi o współpracę - są 3 poziomy cache (4 nawet), inaczej rozwiązane FSB, dzielenie się zadaniami, wielowątkowość etc. Problemem większości aplikacji jest właściwe, optymalne wykorzystanie 4 rdzeni - przeważnie do "roboty" zaprzęga się dwa, pozostałe supportują system i to co działa w tle - nie korzystam z najnowszego oprogramowania gdzie ta współpraca z quadami jest lepsza - być może coś się zmieniło na lepsze:). Co do DSP, no cóż... Nie nadąża zwyczajnie za CPU, więc nie ma co się dziwić że co dla niego jest już dławieniem się, komputer rozłoży sobie na poszczególne rdzenie.

Co nas czeka? Nowe standardy, może ASIO3 albo coś nowego;), sprzętowe karty DSP z wieloma procesorami/rdzeniami, a marzeniem by było wykorzystanie czegoś podobnego do architektury np CUDA czy Tesla od nVidii i dostosowanie do wymagań audio - żaden procesor czy karta do ProToolsa nie da takiej mocy obliczeniowej. Co tam mocy - takiej ilości jednostek obliczeniowych w jednym urządzeniu - pzerzucenie tylu procesów na niezależne "tory" byłoby na pewno idealnym wyjściem:). Druga sprawa czy to się opłaca producentom - lepiej wypuszczać coraz to nowe wersje softu, sprzętu i kart proaudio niż dać narzędzie na lata które zapchać może chyba tylko realizowana na 256 instrumentów symfonia oparta na VST z modelowaniem fizycznym, pełnym pakietem wtyczek insertowych na każdy kanał i co tam jeszcze ktoś sobie wymyśli;-).

przy okazji: Cubase 5.5 update

The 5.5 update includes new enhancements for the Cubase audio engine that boosts performance in several areas, including improved resource handling for computers with multiple cores.

...
przy okazji: Cubase 5.5 update

The 5.5 update includes new enhancements for the Cubase audio engine that boosts performance in several areas, including improved resource handling for computers with multiple cores.

 
Bardzo wyczekuję na ten update. Zwłaszcza na nową obsługę video (chociaż znalazłem już pewien sprawdzony sposób, gdzie nic się nie wiesza i jest gites pod 64bit Cubase).

Cubase 4 i wyżej całkiem nienajgorzej radzi sobie z 4 rdzeniami. Fakt jest taki, że niektóre wtyczki mają dostęp tylko do jednego rdzenia. Czyli na przykład w sytuacji gdy mamy uruchomiony jeden instrument VST (jeden instrument w racku) i w nim załadowane x instrumentów. Zdarza się tak, że używany będzie tylko jeden rdzeń.

Dlatego też zalecane jest "rozporządzaniem" zasobów procesora na własną rękę - czyli np. zamiast ładowania 16 instrumentów w jeden instrument w racku, otwieramy 4 i w każdym dajemy po 4.

W praktyce jednak z mojego doświadczenia wynika, że większość z nowych wtyczek, jakoś sobie radzi sama ;).

- Piotr 

NO dobra. Czego dokładnie wskaźnikiem jest ten szanowny DSP (co składa sie na ten wskaźnik, jakie składowe i zależności miedzy nimi), wie ktoś? Od czego zależy "przepustowość" w zakresie 0 - 100%, jaki ma związek z buforami itp.

...
NO dobra. Czego dokładnie wskaźnikiem jest ten szanowny DSP (co składa sie na ten wskaźnik, jakie składowe i zależności miedzy nimi), wie ktoś? Od czego zależy "przepustowość" w zakresie 0 - 100%, jaki ma związek z buforami itp.

 ... 

Jeżeli na przykładzie Superior Drummera obserwujemy takie zjawisko że system DSP jest obciążony w 13% kiedy CPU tylko 2%, na pewnie ma to związek z generowaną latencją (z powodu ilosci wewnętrznych zadań).  Ale jeżeli to latencja robi problem to jakie z tego wyjście na przyszłość?  Przecież nie da się zejść po niżej pewnego progu. A granica "przepustowości" DSP jest jakość ściśle określona. Pytanie czym i dlaczego akurat w takich granicach? 

...
...
NO dobra. Czego dokładnie wskaźnikiem jest ten szanowny DSP (co składa sie na ten wskaźnik, jakie składowe i zależności miedzy nimi), wie ktoś? Od czego zależy "przepustowość" w zakresie 0 - 100%, jaki ma związek z buforami itp.

 ... 

Jeżeli na przykładzie Superior Drummera obserwujemy takie zjawisko że system DSP jest obciążony w 13% kiedy CPU tylko 2%, na pewnie ma to związek z generowaną latencją (z powodu ilosci wewnętrznych zadań).  Ale jeżeli to latencja robi problem to jakie z tego wyjście na przyszłość?  Przecież nie da się zejść po niżej pewnego progu. A granica "przepustowości" DSP jest jakość ściśle określona. Pytanie czym i dlaczego akurat w takich granicach? 

 ... 

***************

Juz kiedys o tym dyskutowalismy. Wskaznik pokazuje ile czasu aplikacja spedza na obsludze ASIO. Wiec im wiecej wtyczek (a bedzie ich tym wiecej im szybszy procesor) i im nizsza latencja tym aplikacja zuzywa wiecej zasobow. Szczerze powiedziawszy czesto pracuje na projektach wielosladowych z wieloma insertami per slad i nie przypominam sobe takiej sytuacji, kiedy wskaznik ASIO pokazuje 90% a CPU jest na poziomie 30%. Co prawda nie pracuje na bardzo niskiej latencji bo tego nie potrzebuje, ale taki rozrzut w znacznym stopniu zalezy od jakosci sterownika interfejsu i aplikacji, ktora z niego korzysta i samych wtyczek. Przy tej ilosci (tu mozna juz mowic o duzej skali) mozliwych do zapiecia wtyczek, ktora umozliwiaja dzisiejsze wielordzeniowe procesory, jakosc sterownika, aplikacji i wtyczek (oraz ich rodzaj, bo specyfika dzialania okreslonej wtyczki moze wymagac znacznego uzycia zasobow) zaczyna odgrywac kluczowa role w wydajnosci calego systemu. Ja na Twoim miejscu w powyzszym projekcie pobawilbym sie wielkoscia bufora oraz masowo dla testu powymienial wtyczki i zobaczyl jaki to ma wplyw na wydajnosc. Program hostujacy tez bym sprobowal uruchomic inny i zobaczyl jak to sie przeklada zuzycie zasobow. Na pewno wiecej na ten temat moglby napisac WG, ktory implementuje aplikacje pracujace na ASIO i na pewno wie gdzie i przy jakich warunkach moga pojawic sie waskie gardla w systemie.

Nie wierze tez, ze w duzych projektach pracujesz na wszystkich sciezkach na raz. To niemozliwe. Naprawde warto zamrazac slady, na ktorych w danej chwili nic sie nie robi, skoro dalsza praca i tak staje sie uciazliwa, a to pozwala sie skupic na tych elementach projektu, ktore wymagaja naszej uwagi w danej chwili. Podobnie jest jesli pracujesz na tym etapie projektu, kiedy nie dogrywasz nic na zywo, to czy na pewno potrzebujesz niskiej latencji ? Tak samo jak nalezalo by sie zastanowic czy na etapie budowania aranzu na pewno pracujemy nad aranzem a nie nad kilkoma innymi elemntami produkcji rownoczesnie... wiec wlasciwe podejscie do danego projektu tez pozwala ograniczyc uzycie zasobow i zajecie sie dokladnie tym nad czym w danej chwili pracujemy, a nie wieloma rzeczami na raz. Wiem, mozliwosci kusza, ale naprawde szybciej sie pracuje skupiajac sie nad jedna a nie nad kilkoma rzeczami na raz.

Juz kiedys o tym dyskutowalismy. Wskaznik pokazuje ile czasu aplikacja spedza na obsludze ASIO. Wiec im wiecej wtyczek (a bedzie ich tym wiecej im szybszy procesor) i im nizsza latencja tym aplikacja zuzywa wiecej zasobow. Szczerze powiedziawszy czesto pracuje na projektach wielosladowych z wieloma insertami per slad i nie przypominam sobe takiej sytuacji, kiedy wskaznik ASIO pokazuje 90% a CPU jest na poziomie 30%. Co prawda nie pracuje na bardzo niskiej latencji bo tego nie potrzebuje, ale taki rozrzut w znacznym stopniu zalezy od jakosci sterownika interfejsu i aplikacji, ktora z niego korzysta i samych wtyczek. Przy tej ilosci (tu mozna juz mowic o duzej skali) mozliwych do zapiecia wtyczek, ktora umozliwiaja dzisiejsze wielordzeniowe procesory, jakosc sterownika, aplikacji i wtyczek (oraz ich rodzaj, bo specyfika dzialania okreslonej wtyczki moze wymagac znacznego uzycia zasobow) zaczyna odgrywac kluczowa role w wydajnosci calego systemu. Ja na Twoim miejscu w powyzszym projekcie pobawilbym sie wielkoscia bufora oraz masowo dla testu powymienial wtyczki i zobaczyl jaki to ma wplyw na wydajnosc. Program hostujacy tez bym sprobowal uruchomic inny i zobaczyl jak to sie przeklada zuzycie zasobow. Na pewno wiecej na ten temat moglby napisac WG, ktory implementuje aplikacje pracujace na ASIO i na pewno wie gdzie i przy jakich warunkach moga pojawic sie waskie gardla w systemie.

Nie wierze tez, ze w duzych projektach pracujesz na wszystkich sciezkach na raz. To niemozliwe. Naprawde warto zamrazac slady, na ktorych w danej chwili nic sie nie robi, skoro dalsza praca i tak staje sie uciazliwa, a to pozwala sie skupic na tych elementach projektu, ktore wymagaja naszej uwagi w danej chwili. Podobnie jest jesli pracujesz na tym etapie projektu, kiedy nie dogrywasz nic na zywo, to czy na pewno potrzebujesz niskiej latencji ? Tak samo jak nalezalo by sie zastanowic czy na etapie budowania aranzu na pewno pracujemy nad aranzem a nie nad kilkoma innymi elemntami produkcji rownoczesnie... wiec wlasciwe podejscie do danego projektu tez pozwala ograniczyc uzycie zasobow i zajecie sie dokladnie tym nad czym w danej chwili pracujemy, a nie wieloma rzeczami na raz. Wiem, mozliwosci kusza, ale naprawde szybciej sie pracuje skupiajac sie nad jedna a nie nad kilkoma rzeczami na raz.

 ...

Dzięki za odzew.  To co napisałeś jest jak najbardziej zrozumiałe. Zawsze kiedy brakuje mi juz zasobów frezuje ostatecznie slady bo nie mam wyjscia. Zawsze jednak czekam do ostatniego momentu aż braknie, gdyż zawsze drobne zmiany w aranzu robie do konca (to crash, to hihat, czy jedna nutka dla urozmaicenia). Ale mniejsza z tym. Wprawdzie i tak mam bardzo duzo mocy do pracy online, ale stara sie tak pozostawiac projekty żeby nie generować gigabajtów danych. Moje archiwizacje zaczynają zabierać coraz więcej m2

Nie zauwazylem różnicy zwiększając latencje z 256 na 512-1024 przykładowo. Również nie ma roznicy kiedy bufor w hoście nie jest mniejszy niż 2048. Powyżej nie zauwazylem roznicy i poziom DSP nie spada. Ale musze przeprowadzić bardziej szczegółowe testy. Bede informował.

A jest może jest możliwe określenie gdzie leży granica systemu DSP? Chodzi  mi o konkretna informacje , bo gdzies musi ona być.  Pomijając sposoby na optymaliacje sesji i radzenie sobie z tym ograniczeniem. Ale chciałbym zrozumieć dlaczego to ograniczenie jest takie a nie inne?

No i czy jest z tego jakieś wyjście? Bo po co na szybkie CPU, ale nie bedzie mozna uzyc wielu wtyczek.

Uperdliwie wypytuje ale nadal nie mam satysfakcjonujacej mnie odpowiedzi

 

No i czy jest z tego jakieś wyjście? Bo po co na szybkie CPU, ale nie bedzie mozna uzyc wielu wtyczek.

************

Ale czego oczekujesz ? Matematycznej formuly ? Nie ma takiej, bo nie znasz algorytmow, ktore sa stosowane w oprogramowaniu, ktore uzywasz. Nie rozumiem tez o jakim ograniczeniu mowisz. Przeciez uzywasz wiecej wtyczek niz uzylbys dysponujac procesorem slabszym. Nie mozesz tez oczekiwac liniowego przyrostu "mocy", bo przeciez z mocniejszym procesorem uzywasz wiecej wtyczek, ale to chyba zrozumiale. Mechanizm jest wspolzalezny, bo im wiecej wtyczek, tym wiecej operacji na ASIO, wiec im mocniejszy procesor tym wiecej operacji musi wykonac, a poniewaz jest szybszy, to wykonuje je w tym samym albo nawet krotszym czasie niz procesor slabszy. Nie mozesz tez oczekiwac ze "uzycie ASIO" bedzie kiedykolwiek odpowiadac uzyciu CPU, bo to sa *rozne* wskazniki i nie mozna ich porownywac ani oczekiwac rownomiernego wysycenia jednego i drugiego zasobu rownoczesnie. Takie oczekiwanie jest z zalozenia bledne.

Jesli mowa o ograniczeniach, ograniczeniem sa niechlujnie napisane sterowniki, wtyczki i kto wie czy nie same hosty. Jakis czas temu uzywalem calkiem znany poglos z odpowiedziami impulsowymi. Sesje mialem w 24/96, a przy wyborze impulsow z pospiechu wybralem impuls 16/44.1. Oczywiscie wskaznik ASIO zwariowal, bo wtyczka chyba konwertowala caly strumien na swoim wyjsciu w locie... zamiast chocby krzyknac mi oknem, ze nie zgadzaja sie rozdzielczosci bitowe z ustawieniami projektu.

Nie rozumiem tez dlaczego wymagasz takiego samego uzycia kazdego rdzenia CPU. To niemozliwe.

Zawsze przed archiwizacja projektu warto oczywiscie odmrozic slady i problem z glowy.

A w ramach testow warto tez zmienic interfejs na inny (aby porownac inne rozwiazania) i popatrzec jak ta sama sesja zachowuje sie w tym przypadku.

...
 

No i czy jest z tego jakieś wyjście? Bo po co na szybkie CPU, ale nie bedzie mozna uzyc wielu wtyczek.

************

Ale czego oczekujesz ? Matematycznej formuly ? Nie ma takiej, bo nie znasz algorytmow, ktore sa stosowane w oprogramowaniu, ktore uzywasz. Nie rozumiem tez o jakim ograniczeniu mowisz. Przeciez uzywasz wiecej wtyczek niz uzylbys dysponujac procesorem slabszym. Nie mozesz tez oczekiwac liniowego przyrostu "mocy", bo przeciez z mocniejszym procesorem uzywasz wiecej wtyczek, ale to chyba zrozumiale. Mechanizm jest wspolzalezny, bo im wiecej wtyczek, tym wiecej operacji na ASIO, wiec im mocniejszy procesor tym wiecej operacji musi wykonac, a poniewaz jest szybszy, to wykonuje je w tym samym albo nawet krotszym czasie niz procesor slabszy. Nie mozesz tez oczekiwac ze "uzycie ASIO" bedzie kiedykolwiek odpowiadac uzyciu CPU, bo to sa *rozne* wskazniki i nie mozna ich porownywac ani oczekiwac rownomiernego wysycenia jednego i drugiego zasobu rownoczesnie. Takie oczekiwanie jest z zalozenia bledne.

Jesli mowa o ograniczeniach, ograniczeniem sa niechlujnie napisane sterowniki, wtyczki i kto wie czy nie same hosty. Jakis czas temu uzywalem calkiem znany poglos z odpowiedziami impulsowymi. Sesje mialem w 24/96, a przy wyborze impulsow z pospiechu wybralem impuls 16/44.1. Oczywiscie wskaznik ASIO zwariowal, bo wtyczka chyba konwertowala caly strumien na swoim wyjsciu w locie... zamiast chocby krzyknac mi oknem, ze nie zgadzaja sie rozdzielczosci bitowe z ustawieniami projektu.

Nie rozumiem tez dlaczego wymagasz takiego samego uzycia kazdego rdzenia CPU. To niemozliwe.

Zawsze przed archiwizacja projektu warto oczywiscie odmrozic slady i problem z glowy.

A w ramach testow warto tez zmienic interfejs na inny (aby porownac inne rozwiazania) i popatrzec jak ta sama sesja zachowuje sie w tym przypadku.

 ... 

Hehe, spokojnie, nie oczekuje algorytmów bo nie bedą one odpowiedzią. Nie oczekuje rownomiernego rozłożenia na rdzeniach, bo to niemożliwe (doskonale to wiem). Użyłeś określenia "wysycenia ASIO", no właśnie, tej odpowiedzi oczekuje. Czym jest owo "wysycenie"? Da sie to przecież powiedzieć bez uzywania algorytmów.  Jeżeli wiesz to powiedz.  

Wiem że to proces złożony, ale jest musi byc jakiś czynnik ograniczający niejako "na sumie" górną granice wydajności tego systemu. Być może jestem tępy i niedouczony, ale nadal nikt mi na to nie odpowiedział na to jakże banalne pytanie.