Ugye a jelenlegi felállásban adott a hang keretrendszer - ami a zongi esetében a Jack - és annak a beállítási opciói amik elérhetőek számomra. Ez lényegében három dolgot jelent 1.)a mintavételi frekvenciát 48kHz, 2.)egy puffer méretet 64, és 3.) egy un. period értéket 2. Ezek határozzák meg a Jack által kijelzett latency értéket ami asszem most 2.4 ms lehet. Ami extrán kicsi értéknek tűnik, de hiába mert érzetre nagyon is van különbség a cél hardware (digitális zongora) és a PC-s virtuális zongora között játékélményben az eltérő késleltetés miatt. Ez a kijelzett 2.4 ms csak valami rész érték lehet.
Ubuntu Studioban nincs realtime kernel, helyette un. low latency kernel van. Van egy szkript ami lecsekkolja a latency szempontjából kritikus beállításokat: https://github.com/raboof/realtimeconfigquickscan
Ezekkel a beállításokkal nagyjából stabilnak tekinthető a rendszer, de pl az egyik tesztem a glissando, amikor a kezemet gyorsan végighúzom az egész billentyűzeten és közben a zengető pedált lenyomva tartom (ilyenkor tovább szólnak a hangok) ettől persze kifekszik rendszer és elkezd XRUN-okat dobálni. Vagy egy másik ilyen teszt, hogy szintén lenyomott pedál mellett egy oktáv különbséggel "pörgetek két hangot" (tremolo) - ilyenkor is felszalad az egyszerre szóló hangok száma - de azt nagyjából bírja egészen addig míg a pedált fel nem engedem. Akkor rögtön megjelenik vagy tucat XRUN. Ez még megfejtésre vár számomra, h mi is történik itt pontosan. Valószínűleg az lehet a dolog mögött, hogy a billentyű felengedés esemény NOTEOFF nem csak lekeveri az aktuálisan szóló hangot a definiált burkoló görbe szerinti lecsengéssel, hanem le is játszik egy rövidebb (release) hangot, amit az akusztikus zongorán a damper a húrra való visszatérése vált ki. És a pedál felengedése triggereli ezt az eseményt, ami vázolt tremolo-s esetben sok - egyébként ugyanazon hang - release hangjának az azonnali lejátszását eredményezi, és ezt persze nem bírja teljesíteni és akkor jönnek az XRUN-ok. Amúgy a hangzásban nem venni észre a dolgot. Nyilván ez egy hibás működés következmény lehet - kicsit meglepő is h ezt nem kezeli le LS. De lehet h tévedek ezzel kapcsolatban. Még ki kell debuggolni!
Természetesen a LS beállításai is erős kihatással vannak az alkalmazható latencyre. Ráadásul ezeket fordítási opcióként lehet megadni: ilyenek pl preload sample értéke - azaz h egy hangból mekkora részt töltsön a memóriába az induláskor. Nyilván egy gyors disk rendszer esetében, mint az M.2 PCIe SSD nagyobb a mozgástér kevesebb memória elég neki ill. több hangot tud összeségében kezelni. Ennek akkor van jelentősége, h elkezdjük növelni a felvett hangminták számát a kölünböző kombinációs tényezők szerint. Korábban volt ~16 GB -nyi hangmintám lenyomott zengető pedál esetén, meg volt még egyszer ennyi felengedett pedál esetén. Most hozzá jött az h ennek a pedálnak a "fél" állásában is lett 16 GB -nyi felvétel. És akkor még vannak egyéb hangok is pl. a release hangok, vagy a mechanika hangjai. Minél több hang van, annál több hangnak kell preloadjait betölteni az induláskor. És ezért kell a minél gyorsabb disk rendszer, h a preload mértékét alacsonyan lehessen tartani a szűkös memóriára való tekintettel. De ugyan így fordítási opció a max polifónia azaz az egszsrre szoló hangok száma, vagy max disk streamek száma, vagy a subfragment size. Ezek kihatással lesznek a latencyre.
Még az is eszembe jutott, hogy ha egy PC-ben ennyire problémás ez a buffer-kérdés/ütemezés/késleltetés hát akkor több PC -t fogok használni.Veszek vagy 4 db régebbi PC-t ami viszonylag olcsón beszerezhető és elosztom köztük a feladatokat. Mindegyik kap mondjuk két oktávot és azon hangokért felel, párhuzamosan dolgozhatnak az outputot meg egy olcsóbb mixerben összekeverem. Nyilván a négy házat el kell tudni helyezni úgy hogy ne zúgjanak; meg kell oldani a beállítások menedzselését; illetve hát csengetni kell utánuk a villanyszámlát is. Továbbá kell hozzájuk egy-egy hangkártya is. Ami így nyilvánvalóan az olcsóbb kategóriákból beszerzendő. 16 Bit-es 44.1 KHz -es lowlatency kártya van olcsón szerencsére.