Opóźnienia w instalacji: jak je skutecznie zredukować?

W sztuce nowych mediów i na hackathonach artystyczno-technologicznych nawet niewielka różnica między działaniem a reakcją potrafi zmienić odbiór całej pracy. To, co miało przypominać żywy dialog z systemem, zaczyna wyglądać jak sterowanie techniczną atrapą.

Warto jednak od razu odrzucić myślenie o jednym uniwersalnym progu latencji. To, co będzie zauważalne podczas gry na instrumencie, nie musi przeszkadzać w instalacji reagującej na powolny ruch całego ciała. Znaczenie ma rodzaj interakcji, sposób jej prezentacji, odległość widza od ekranu, charakter dźwięku oraz to, czy opóźnienie jest stałe, czy zmienia się w czasie.

Latencja w instalacji interaktywnej nie jest jedną wartością, lecz sumą opóźnień nakładających się na siebie: konwersji analogowo-cyfrowej w interfejsie audio, transportu sygnału MIDI, przetwarzania w programie, renderowania klatek w TouchDesigner, czasu odczytu czujnika, przesyłania danych i buforowania w systemie operacyjnym. Każdy z tych etapów ma swój udział i każdy można próbować ograniczyć — ale zwykle kosztem stabilności, jakości obrazu, obciążenia procesora albo prostoty konfiguracji.

Mechanika latencji: skąd bierze się opóźnienie w systemie audio-wideo

Opóźnienie w instalacji nie jest pojedynczym problemem, który da się rozwiązać suwakiem w jednym oknie ustawień. To ciąg zdarzeń: sygnał trafia do interfejsu audio lub czujnika, zostaje przetworzony, przesłany do aplikacji, zamieniony na komunikat sterujący, wykorzystany do obliczenia obrazu lub dźwięku, a następnie wyświetlony, odtworzony albo wysłany dalej. Na każdym etapie może powstać niewielka zwłoka. Dopiero ich suma staje się odczuwalnym opóźnieniem.

W przypadku sygnału audio droga jest stosunkowo łatwa do opisania. Interfejs próbuje falę dźwiękową lub sygnał z czujnika, zamienia ją na postać cyfrową, a oprogramowanie — na przykład Ableton, Max/MSP, Reaper albo inny silnik audio — analizuje dane i generuje odpowiedź. Jeżeli sygnał wraca przez przetwornik cyfrowo-analogowy do głośnika, dochodzi jeszcze etap wyjściowy. Czas między wejściem a wyjściem określa się często jako latencję całej pętli, czyli round-trip latency. Warto odróżnić ją od wartości podawanej przez sam sterownik dla wejścia lub wyjścia, ponieważ ta druga nie zawsze obejmuje cały rzeczywisty łańcuch.

W systemie wizualnym opóźnienie może powstać między innymi w:

• czujniku i jego układzie pomiarowym;
• sterowniku urządzenia oraz warstwie komunikacji;
• transmisji przewodowej lub bezprzewodowej;
• aplikacji odbierającej dane;
• logice sterującej i przeliczeniach wykonywanych w czasie rzeczywistym;
• renderowaniu obrazu;
• kolejce klatek karty graficznej;
• wyświetlaczu, projektorze lub dodatkowym procesorze obrazu.

Do tego dochodzi zjawisko nierównej latencji. Stałe opóźnienie jest łatwiejsze do przewidzenia i często można je skompensować w logice instalacji. Znacznie bardziej kłopotliwe są skoki: pojedyncze klatki trwające dużo dłużej niż pozostałe, chwilowe zablokowanie wątku, ponowne przesłanie pakietu w sieci albo nagłe wybudzenie procesu systemowego. Widz nie musi znać wartości w milisekundach, żeby zauważyć, że instalacja raz reaguje natychmiast, a chwilę później zaczyna się spóźniać.

W przypadku interakcji muzycznych i ruchowych często mówi się o bardzo niskich wartościach opóźnienia, ale nie należy traktować konkretnych progów percepcji jako reguły obowiązującej każdą instalację. Wrażliwość widza zależy od rytmu, powtarzalności gestu, rodzaju sprzężenia zwrotnego i oczekiwań budowanych przez dzieło. Inaczej odbiera się opóźnienie w reakcji na dotknięcie wirtualnego instrumentu, inaczej w powolnej projekcji reagującej na obecność osoby, a jeszcze inaczej w systemie, w którym dźwięk i obraz powinny pozostawać zsynchronizowane z ruchem.

Źródła opóźnień można pogrupować w trzy warstwy:

• Warstwa sprzętowa — obejmuje czujniki, interfejsy, przetworniki, kartę graficzną, wyświetlacz oraz rodzaj połączenia. Sama wysoka częstotliwość próbkowania nie gwarantuje krótszej reakcji, jeśli reszta konfiguracji jest źle dobrana.
• Warstwa sterowników — w systemie Windows istotną rolę odgrywa ASIO, a w macOS Core Audio. To tutaj ustawia się między innymi rozmiar bufora i sposób komunikacji z urządzeniem.
• Warstwa oprogramowania i systemu — obejmuje wielkość sceny w TouchDesigner, rozdzielczość materiału wejściowego, liczbę operacji wykonywanych na klatkę, zarządzanie energią procesora i procesy działające w tle.

Latencja nie jest tym samym co przepustowość łącza. Można mieć szybkie połączenie sieciowe i jednocześnie wysokie opóźnienie, jeśli sygnał przechodzi przez wiele urządzeń, czeka w buforze lub jest obsługiwany przez niestabilny sterownik. Z kolei prosty komunikat sterujący może być przesyłany przez sieć bez dużego obciążenia, ale jego czas dostarczenia będzie się zmieniał. W instalacjach reagujących na ruch ta zmienność bywa bardziej widoczna niż sama średnia wartość.

Bufor audio i sterowniki ASIO: praktyczne ustawienia

Najczęściej regulowanym parametrem jest bufor audio wyrażany w próbkach. Typowe ustawienia to 64, 128 i 256 próbek. Przy częstotliwości próbkowania 48 kHz bufor 64 próbek odpowiada około 1,3 ms dla jednej strony toru, 128 próbek — około 2,7 ms, a 256 próbek — około 5,3 ms. Są to wartości wynikające z samego rozmiaru bufora, a nie pełna latencja instalacji. Rzeczywisty wynik zależy także od sterownika, konwersji, aplikacji, bufora wyjściowego i sposobu pomiaru.

Im mniejszy bufor, tym krótsza może być latencja, ale tym mniej czasu procesor ma na wykonanie obliczeń. Przy zbyt małym ustawieniu pojawiają się trzaski, przerwy, kliknięcia i błędy przetwarzania. W systemie wystawienniczym problemem nie jest tylko pojedynczy artefakt. Jeżeli instalacja działa przez wiele godzin, nawet sporadyczne przeciążenia mogą zepsuć odbiór bardziej niż nieco wyższa, ale stabilna latencja.

W praktyce można przyjąć następującą kolejność testów:

1. Zacząć od 128 próbek, jeśli projekt wymaga reakcji w czasie rzeczywistym, ale nie jest wyjątkowo ciężki obliczeniowo.

2. Zmniejszyć bufor do 64 próbek dopiero po sprawdzeniu stabilności całego toru, a nie tylko krótkiego fragmentu działania.

3. Zwiększyć go do 256 próbek, jeśli projekt zawiera wiele ścieżek, wtyczek lub operacji, a priorytetem jest ciągłość pracy.

4. Po każdej zmianie wykonać dłuższy test z rzeczywistym sygnałem wejściowym i wszystkimi aktywnymi elementami instalacji.

Sterownik ASIO w systemie Windows lub Core Audio w macOS odpowiada za komunikację z interfejsem audio z pominięciem części systemowych warstw miksowania. W instalacjach artystycznych jakość sterownika potrafi mieć większe znaczenie niż sama deklarowana specyfikacja urządzenia. Dwa interfejsy o podobnej częstotliwości próbkowania mogą zachowywać się zupełnie inaczej pod obciążeniem: jeden będzie pracował stabilnie przy małym buforze, drugi zacznie gubić próbki albo generować błędy.

Na macOS można łączyć kilka urządzeń w Aggregate Device, ale taka konfiguracja wymaga szczególnej uwagi. Różnice w zegarach urządzeń mogą prowadzić do problemów z synchronizacją, a dodatkowa warstwa konfiguracji utrudnia znalezienie źródła błędu. Jeżeli projekt pozwala, pojedynczy dobrze skonfigurowany interfejs zwykle jest prostszym i bezpieczniejszym rozwiązaniem.

Trzeba też rozdzielić opóźnienie audio od opóźnienia komunikatów MIDI. Sam komunikat MIDI jest niewielki, lecz jego droga może obejmować kontroler USB, sterownik, aplikację pośredniczącą, zegar synchronizacyjny i instrument programowy. Jeśli komunikat uruchamia ciężki syntezator, efekt lub wizualizację, to właśnie przetwarzanie po odebraniu danych może zdominować cały czas reakcji. Dlatego opóźnienie sygnału MIDI w instalacji artystyczno-technologicznej mierzy się w kontekście konkretnego łańcucha, a nie na podstawie samego rodzaju protokołu.

Bufor audio to kompromis, nie wyłącznik: zejście poniżej granicy stabilności nie musi skrócić odczuwalnej reakcji, za to może wprowadzić trzaski, przerwy i nierówny czas działania.

Płynność obrazu w TouchDesigner: downscaling i oszczędzanie klatek

W instalacjach z wizualizacjami generowanymi w czasie rzeczywistym — między innymi w TouchDesigner, Notch, vvvv czy Unity — czas renderowania klatki może zdominować cały budżet opóźnienia. Jeżeli pojedyncza klatka trwa długo albo czas jej wykonania mocno się waha, system zaczyna reagować nierówno. Wysoka średnia liczba klatek na sekundę nie wystarczy, jeśli co jakiś czas pojawia się wyraźny skok czasu renderowania.

Jedną z najskuteczniejszych technik jest downscaling, czyli praca na obrazie o mniejszej rozdzielczości przed wykonaniem kosztownych operacji. W TouchDesigner można wykorzystać do tego między innymi operator Fit TOP, który skaluje obraz przed dalszym przetwarzaniem. Zmniejszenie materiału z 4K do 1080p oznacza wyraźne ograniczenie liczby pikseli, a zejście do 720p może być uzasadnione w projekcji oglądanej z większej odległości. Nie jest to jednak decyzja czysto techniczna. Znaczenie mają rozmiar powierzchni, odległość widza, ostrość projektora, charakter tekstur i to, czy instalacja opiera się na drobnych detalach.

Downscaling nie powinien być stosowany bezpośrednio na całej sieci. Najpierw trzeba ustalić, które operacje rzeczywiście korzystają z wysokiej rozdzielczości. Część elementów można przetwarzać w mniejszym rozmiarze, a dopiero końcową kompozycję skalować do wyjścia. W innych przypadkach zmniejszenie rozdzielczości na wejściu zniszczy szczegóły potrzebne do analizy obrazu lub śledzenia obiektu. Ta technika działa najlepiej wtedy, gdy jest dopasowana do konkretnego wąskiego gardła.

Drugim frontem optymalizacji jest praca z klatkami. Nie każda część instalacji musi aktualizować się z taką samą częstotliwością. Logika sterująca, analiza obecności albo wolno zmieniające się parametry mogą być odświeżane rzadziej niż warstwa odpowiedzialna za płynność ruchu. Operatorzy Timer i Speed pomagają kontrolować czasowanie poszczególnych fragmentów sieci, ale trzeba pilnować, aby ograniczenie częstotliwości nie stało się dodatkowym źródłem opóźnienia w reakcji.

Warto rozdzielić trzy rzeczy:

• częstotliwość odczytu danych z czujnika;
• częstotliwość aktualizacji logiki;
• częstotliwość renderowania obrazu wyjściowego.

Jeżeli czujnik dostarcza dane często, lecz logika wykorzystuje je dopiero co kilka klatek, widz odczuje zwłokę mimo wysokiej płynności obrazu. Z drugiej strony utrzymywanie maksymalnej częstotliwości we wszystkich modułach może niepotrzebnie obciążyć procesor i kartę graficzną. Celem nie jest najwyższa liczba FPS w każdej części projektu, tylko spójna reakcja całego łańcucha.

Renderowanie do bufora pośredniego może pomóc ustabilizować złożoną kompozycję, ale jego koszt nie jest stały. Dodatkowa kolejka, tekstura lub etap przetwarzania może zwiększyć opóźnienie o wartość zależną od sprzętu, sterownika i ustawień synchronizacji. Na jednej konfiguracji będzie to prawie niezauważalne, na innej — wyraźne. Dlatego bufor pośredni należy traktować jako narzędzie do sprawdzenia pomiarem, a nie gwarantowany sposób na uzyskanie określonego narzutu.

W TouchDesignerze warto obserwować nie tylko ogólny wskaźnik wydajności, lecz także czas poszczególnych operatorów. Ciężki filtr, duża liczba instancji, system cząsteczek albo operacja wykonywana na pełnej rozdzielczości może blokować cały przepływ. Czasem większą poprawę daje uproszczenie jednego operatora niż obniżenie jakości wszystkich elementów sceny.

Pomocne są również proste zasady organizacyjne:

• przygotować materiały w rozdzielczości adekwatnej do wyjścia;
• unikać wielokrotnego skalowania tego samego obrazu;
• ograniczyć niepotrzebne konwersje formatów;
• wyłączyć nieużywane gałęzie sieci;
• sprawdzić, czy efekt wykonywany na każdej klatce rzeczywiście musi działać w czasie rzeczywistym;
• testować projekt w docelowej rozdzielczości i z rzeczywistym urządzeniem wyjściowym.

Jak uniknąć spadków wydajności: core parking i zarządzanie energią

Jedno z mniej oczywistych źródeł opóźnień leży w systemie operacyjnym. Komputer wystawienniczy często jest traktowany jak zwykła stacja robocza, choć pracuje w zupełnie innych warunkach: przez wiele godzin, w zamkniętej obudowie, z aktywną siecią, urządzeniami wejściowymi i aplikacją działającą bez przerwy.

Na komputerach z procesorami hybrydowymi system może przenosić zadania między rdzeniami o różnej charakterystyce. W przypadku procesorów Intela są to między innymi rdzenie wydajnościowe i efektywnościowe. W komputerach Apple podobne różnice wynikają z podziału na klastry rdzeni. Samo przeniesienie procesu nie musi być problemem, ale przy źle dobranej konfiguracji może powodować nierówny czas wykonywania zadań, skoki obciążenia i wahania płynności.

Także mechanizm core parking, czyli czasowe usypianie części rdzeni, może wpływać na zachowanie systemu. Nie należy jednak wyłączać go automatycznie w każdej instalacji. Zmiana ustawień zasilania może zwiększyć pobór energii, temperaturę i hałas, a na części komputerów nie przyniesie zauważalnej poprawy. Najpierw trzeba sprawdzić, czy rzeczywiście występują skoki czasu reakcji związane z zarządzaniem procesorem.

Praktyczne działania obejmują:

• Ustawienie odpowiedniego planu zasilania — tryb oszczędny może powodować zmiany częstotliwości procesora i opóźnione reagowanie na chwilowe obciążenie.
• Ograniczenie usypiania aplikacji — w macOS warto sprawdzić między innymi działanie App Nap, a w Windows ustawienia aktywności aplikacji w tle.
• Przypisanie priorytetów i rdzeni — w razie potrzeby można przetestować przypisanie DAW-u lub silnika wizualnego do konkretnych rdzeni, ale nie należy zakładać, że każdy projekt skorzysta z identycznego ustawienia.
• Kontrola temperatury — throttling termiczny może pojawić się dopiero po dłuższym czasie, dlatego krótki test po uruchomieniu komputera jest niewystarczający.
• Wyłączenie zadań wykonywanych w tle — synchronizacja chmury, indeksowanie dysku, skanowanie antywirusowe i aktualizacje mogą powodować chwilowe skoki obciążenia.
• Zablokowanie automatycznych zmian w trakcie ekspozycji — konfigurację systemu najlepiej przygotować przed instalacją i nie modyfikować jej bez potrzeby podczas działania pracy.

Szczególną uwagę trzeba zwrócić na laptopy. Po kilku godzinach pracy urządzenie może obniżyć taktowanie procesora lub karty graficznej, nawet jeśli początkowo instalacja działała płynnie. Podstawka chłodząca może pomóc, ale nie zastąpi sprawdzenia przepływu powietrza, temperatury i zachowania systemu pod długotrwałym obciążeniem. W niektórych miejscach stabilniejsza będzie jednostka stacjonarna, nawet jeśli na papierze ma podobne parametry.

Ta sama logika dotyczy sieci. W instalacji reagującej na gesty lepiej, o ile to możliwe, użyć połączenia Ethernet niż polegać na bezprzewodowej sieci galerii. Wi-Fi może działać poprawnie przez większość czasu, a mimo to generować nieregularne skoki opóźnienia przy większej liczbie urządzeń, zmianie kanału albo chwilowym przeciążeniu punktu dostępowego. Jeżeli sieć jest konieczna, warto ograniczyć liczbę pośrednich usług i sprawdzić działanie instalacji przy obciążeniu typowym dla miejsca ekspozycji.

Komputer wystawienniczy nie jest zwykłą stacją roboczą: każdy proces w tle, zmiana trybu zasilania i skok temperatury może ujawnić się jako nierówna reakcja, nawet gdy średnie użycie procesora wygląda bezpiecznie.

Diagnostyka opóźnień: jak mierzyć czas reakcji instalacji

Redukcja latencji bez pomiaru jest zgadywaniem. Można zmienić bufor, obniżyć rozdzielczość i wyłączyć połowę usług systemowych, a mimo to nie poprawić tego elementu, który naprawdę odpowiada za opóźnienie. Dlatego diagnostykę trzeba zaczynać od podziału instalacji na odcinki.

W warstwie audio przydatny jest tester latencji — narzędzie lub wtyczka wysyłająca impuls i mierząca czas jego powrotu. Niektóre środowiska pracy, w tym Ableton i Reaper, oferują funkcje związane z kompensacją lub pomiarem opóźnienia, a w innych przypadkach można wykorzystać niezależny sygnał testowy i nagranie wejścia oraz wyjścia. Wynik trzeba interpretować ostrożnie: wartość wskazana przez sterownik może nie obejmować czasu działania instrumentu programowego, efektów, miksera, karty graficznej ani wyświetlacza.

W warstwie wizualnej należy obserwować zarówno FPS, jak i czas renderowania pojedynczej klatki. Dwie instalacje mogą mieć podobną średnią liczbę klatek, lecz zupełnie inną stabilność. W TouchDesignerze panel wydajności pozwala sprawdzić, które elementy sieci zużywają najwięcej czasu. W Unity i Unreal dostępne są analogiczne narzędzia profilujące. Najważniejsza jest nie sama liczba w tabeli, lecz znalezienie miejsca, w którym czas zaczyna gwałtownie rosnąć.

W przypadku czujników diagnostyka jest trudniejsza, ponieważ każdy typ urządzenia ma własny sposób raportowania danych. Kamera głębi, LiDAR, kontroler ruchu, markery optyczne i czujnik nacisku mogą mieć różne częstotliwości odczytu, własne filtry wygładzające i wewnętrzne bufory. Filtr redukujący szum może poprawić stabilność śledzenia, ale jednocześnie opóźnić reakcję. Nie ma tu jednej wartości, którą można bezpiecznie zastosować w każdym projekcie.

Najskuteczniejszą metodą jest logowanie czasu na wejściu i wyjściu kolejnych warstw. Dla każdego zdarzenia można zapisać między innymi:

• moment wykrycia bodźca przez czujnik;
• czas odebrania danych przez aplikację;
• moment uruchomienia logiki;
• czas rozpoczęcia i zakończenia renderowania;
• moment wysłania sygnału audio lub obrazu;
• chwilę pojawienia się odpowiedzi na urządzeniu wyjściowym.

Nie zawsze da się zsynchronizować zegary wszystkich urządzeń z laboratoryjną dokładnością, ale nawet przybliżony podział pomaga znaleźć wąskie gardło. Do testu można wykorzystać wspólny bodziec: impuls świetlny rejestrowany przez fotodiodę i kamerę, dźwięk nagrany równocześnie na wejściu i wyjściu albo sygnał sterujący widoczny na ekranie wraz z fizycznym ruchem kontrolera. Ważne, aby mierzyć cały łańcuch, a nie tylko deklarowaną wartość jednego podzespołu.

Pomiar powinien obejmować nie tylko średnią, ale również rozrzut wyników. Jeżeli większość reakcji jest szybka, ale co pewien czas pojawia się znacznie dłuższa zwłoka, użytkownik może zapamiętać właśnie te błędne momenty. W praktyce warto więc sprawdzać wartość typową, najgorsze obserwowane przypadki i to, czy opóźnienie zmienia się wraz z temperaturą oraz czasem działania.

Przydatna jest także metoda zmiany jednego parametru naraz:

1. Zmierzyć instalację w konfiguracji wyjściowej.

2. Zapisać ustawienia bufora, rozdzielczości, częstotliwości próbkowania i trybu zasilania.

3. Zmienić tylko jeden parametr.

4. Powtórzyć ten sam test przez porównywalny czas.

5. Sprawdzić zarówno średni wynik, jak i stabilność reakcji.

6. Dopiero potem przejść do następnej zmiany.

Takie podejście pozwala uniknąć pozornych sukcesów. Jeżeli jednocześnie zmniejszymy rozdzielczość, wyłączymy synchronizację i zmienimy bufor, nie będziemy wiedzieć, która decyzja pomogła, a która tylko przeniosła problem w inne miejsce.

Od czego zacząć w nowej instalacji

Dla nowej instalacji art-tech rozsądny punkt wyjścia wygląda następująco:

1. Określić charakter interakcji. Reakcja na dotyk, rytm, gest całego ciała i powolne przemieszczanie się widza wymagają innych kompromisów. Nie warto narzucać wszystkim scenom tego samego celu czasowego.

2. Rozpisać łańcuch sygnału. Trzeba uwzględnić czujnik, połączenie, aplikację, logikę, renderowanie, tor audio i urządzenie wyjściowe.

3. Ustawić konserwatywny bufor audio. 128 próbek przy 48 kHz może być dobrym początkiem, ale ostateczna decyzja powinna wynikać z testu konkretnego interfejsu i projektu.

4. Dobrać rozdzielczość roboczą do odbioru. W TouchDesignerze warto sprawdzić, czy koszt pracy w natywnej rozdzielczości jest uzasadniony przez warunki oglądania.

5. Wyłączyć niepotrzebne procesy systemowe. Szczególnie te, które mogą uruchamiać się okresowo i powodować chwilowe przeciążenia.

6. Sprawdzić zachowanie po rozgrzaniu komputera. Test powinien trwać wystarczająco długo, aby ujawnić problemy z temperaturą i zarządzaniem energią.

7. Zmierzyć reakcję z prawdziwym użytkownikiem. Wynik narzędzia profilującego nie zastępuje sprawdzenia, czy sprzężenie zwrotne jest przekonujące w przestrzeni wystawy.

Warto zapisywać konfigurację wraz z wynikami. W instalacjach rozwijanych zespołowo często zmienia się komputer, projektor, interfejs audio albo wersję sterownika. Bez notatek łatwo wrócić do ustawień, które działały w pracowni, ale nie sprawdzają się w miejscu ekspozycji.

Częste pułapki

• Przegrzanie laptopa — spadek wydajności może pojawić się dopiero po długiej pracy, dlatego test wykonany tuż po uruchomieniu nie daje pełnego obrazu.
• Zależność od sieci galerii — usługi chmurowe i bezprzewodowa transmisja zwiększają liczbę zmiennych; tam, gdzie to możliwe, instalacja powinna działać lokalnie.
• Zbyt wysoka rozdzielczość projekcyjna — duża powierzchnia nie zawsze wymaga renderowania każdego etapu w natywnym rozmiarze projektora.
• Przeciążony pojedynczy wątek procesora — niskie średnie użycie CPU nie oznacza, że żaden operator lub wtyczka nie blokuje ścieżki przetwarzania.
• Nadmierne wygładzanie danych z czujnika — filtr może uspokoić ruch, ale również opóźnić reakcję.
• Podwójne buforowanie bez pomiaru — dodatkowe kolejki mogą poprawić stabilność obrazu, lecz w określonej konfiguracji zwiększą zwłokę.
• Testowanie tylko jednej ścieżki — instalacja może działać dobrze przy samym obrazie, a tracić synchronizację dopiero po uruchomieniu dźwięku, MIDI i czujników jednocześnie.
• Ocenianie wyłącznie średniego FPS — pojedyncze długie klatki i nieregularne skoki często bardziej psują odbiór niż nieco niższa, ale stała płynność.

Stanowisko: mniej znaczy lepiej, ale mierz zawsze

Opóźnienia w instalacji interaktywnej nie są problemem do rozwiązania jednym ruchem. To łańcuch kompromisów, w którym każde ogniwo ma własny koszt. Mniejszy bufor audio może skrócić reakcję, ale zwiększyć ryzyko błędów. Downscaling odciąża kartę graficzną, lecz ogranicza szczegółowość obrazu. Wyłączenie procesów systemowych poprawia przewidywalność, ale odbiera komputerowi część wygody typowej dla codziennej pracy. Dodatkowy bufor może ustabilizować renderowanie, ale jego wpływ na całą latencję zależy od sprzętu i konfiguracji.

Nie istnieje ustawienie najlepsze dla wszystkich instalacji. Istnieje ustawienie odpowiednie dla konkretnej pracy, konkretnego komputera, konkretnego czujnika i konkretnej przestrzeni. To dlatego wartości podawane w dokumentacji albo poradnikach należy traktować jako punkt startu, nie obietnicę końcowego rezultatu. Stały narzut przypisywany konkretnemu rozwiązaniu również nie jest uniwersalny — trzeba go zmierzyć na docelowym zestawie urządzeń.

Najbardziej praktyczne podejście opiera się na trzech zasadach: pomiar przed optymalizacją, zmiana jednego parametru na raz i ponowny pomiar po zmianie. Do tego dochodzi czwarta: sprawdzanie instalacji w warunkach możliwie bliskich ekspozycji, z docelowym projektorem, głośnikami, czujnikami, temperaturą pracy i obciążeniem sieci.

Dobrze zaprojektowana instalacja nie musi mieć najdroższego sprzętu. Musi natomiast mieć jasno określony łańcuch sygnału i osobę, która wie, gdzie w tym łańcuchu szukać problemu. Czasem rozwiązaniem będzie mniejszy bufor, czasem redukcja rozdzielczości, czasem poprawa chłodzenia, a czasem usunięcie jednej niepotrzebnej operacji wykonywanej na każdej klatce. O tym, która zmiana rzeczywiście pomogła, rozstrzyga nie intuicja, lecz pomiar wykonany na konkretnej instalacji.

Właśnie dlatego skuteczne ograniczanie opóźnień nie polega na polowaniu na jedną magiczną wartość w milisekundach. Chodzi o to, aby reakcja była spójna, przewidywalna i dopasowana do rodzaju interakcji. Gdy widz wykonuje gest, system powinien odpowiedzieć w sposób, który odbiera jako bezpośredni. Jak krótka musi być ta droga, zależy od pracy. Pewne jest tylko to, że bez sprawdzenia całego łańcucha nie da się wiarygodnie ocenić, czy instalacja rzeczywiście działa tak szybko, jak zakładał jej projekt.