Notes tècniques
Com s'ha mesurat i per què està fet així.
Cada nota explica una part: el mètode, les xifres, les versions i la data de la mesura. La referència de cada projecte és a la seva pàgina; aquestes notes en són el raonament.
Qualificar plugins
Com es jutja la memòria d'un plugin
/notes/how-a-plugins-memory-is-judged
La memòria d'un plugin es mesura per instància, es vigila si creix, es limita amb un límit dur i es jutja contra el pressupost de cada amfitrió, perquè cap plugin no es qualifiqui de bo en un amfitrió al qual faria mal.
Plugins que canvien un registre que el cridat ha de preservar
/notes/plugins-that-change-a-callee-saved-register
Un plugin que torna amb un registre preservat canviat fa fallar l'amfitrió més tard i en un altre lloc. Ara el nucli de l'amfitrió protegeix cada crida a un plugin, n'enregistra el primer canvi i la qualificació només ofereix aquest plugin aïllat.
L'amfitrió de plugins
"Empremtes al primer ús: com plugin-hostd es refia del binari d'un plugin"
/notes/pins-on-first-use
plugin-hostd enregistra el resum dels fitxers d'un plugin i de la disposició dels seus paràmetres la primera vegada que s'afegeix, els comprova en cada addició posterior i ho refusa en veu alta quan canvien; així un amfitrió autònom té empremtes sense que cap controlador les hi enviï.
"Cadenes: plugins en sèrie en un sol worker i el membre que falla, en quarantena"
/notes/chains-plugins-in-series-in-one-worker
Una cadena fa córrer en ordre els plugins d'un canal dins d'un sol procés worker, de manera que es desperten una vegada per cicle i no una cadascun; quan un membre falla, només aquest queda en quarantena i la resta de la cadena continua.
"El planificador d'agrupació: els mínims workers que permeten les empremtes i l'historial"
/notes/the-grouping-planner
Donats els plugins d'un canal en l'ordre del senyal, el planificador posa en un sol worker els plugins consecutius que poden compartir procés i deixa sols els altres, segons les seves empremtes, el seu cost i el que han fet en aquesta màquina; queda desactivat per defecte fins que el banc de proves demostri que guanya.
Zynthian en una Raspberry Pi 5
Per què la majoria dels plugins LV2 d'un Zynthian necessiten grups de ports inferits
/notes/why-lv2-plugins-on-zynthian-need-inferred-port-groups
La meitat dels plugins LV2 instal·lats en un Zynthian tenen més de quatre controls i cap grup de ports i la pantalla tàctil els talla en pantalles de quatre en l'ordre dels ports. Un paquet generat que substitueix la descripció del plugin, mai els seus fitxers, hi pot afegir grups que llegeixen tots els consumidors de Zynthian.
D'un fitxer de plugin a una pàgina a la pantalla
/notes/from-a-plugin-file-to-a-page
Cinc etapes converteixen un fitxer CLAP o LV2 en una fila de menú amb les seves xifres, pàgines de controls i una MOD GUI en un Zynthian. Cada etapa té un sol responsable, escriu un sol artefacte en un lloc fix i les etapes següents llegeixen aquest artefacte i res més.
"plugin-hostd en una Raspberry Pi 5: què s'ha mesurat i com"
/notes/plugin-hostd-on-a-raspberry-pi-5
En una Raspberry Pi 5 amb Zynthian i una interfície d'àudio, una cadena de plugin-hostd té la càrrega DSP més baixa dels quatre amfitrions mesurats (els altres són omx-clap-host, mod-host i jalv), a 48 i a 96 kHz; a més, fa servir més o menys la meitat de memòria que mod-host. Aquesta nota en dona l'aparell, el mètode i totes les taules.
"Instruments en una Pi 5: les veus de Surge XT als nuclis"
/notes/instruments-on-a-pi-5
Un instrument que calcula totes les veus en un sol nucli fixa la polifonia que pot tocar una Pi 5, per desocupats que estiguin els altres nuclis. Surge XT no divideix les veus en tasques, de manera que els nuclis que pot aprofitar venen de fer córrer cada instrument en un worker propi, repartits pels nuclis d'àudio.
"Un worker per cadena o un procés per plugin: els pros i els contres"
/notes/one-worker-per-chain-or-one-process-per-plugin
Agrupar una cadena en un sol worker estalvia la major part de la memòria i bona part de la CPU que gasta un procés per plugin i una fallada continua costant només el plugin que ha fallat; el preu és que cal refiar-se dels plugins que comparteixen procés i això és el que decideix la qualificació.
El nucli de l'amfitrió
"Podria l'amfitrió acceptar VST3? La costura de l'adaptador i el seu cost"
/notes/could-the-host-take-vst3
Un adaptador VST3 és possible en C pla contra l'API C de Steinberg, amb llicències que un amfitrió GPL pot fer servir i una prova va allotjar un efecte VST3 real de cap a cap. Costaria unes 6200 línies i tres setmanes, per a una demanda escassa i per això no es fa; el que ho faria canviar queda escrit.
"Disposicions d'àudio: cada port que declara un plugin i com jutja l'amfitrió si hi cap"
/notes/audio-layouts-and-how-the-host-judges-the-fit
Abans l'amfitrió admetia una parella principal mono o estèreo i refusava tota la resta, cosa que deixava fora 84 dels 975 plugins LV2 que mod-host allotja. Ara la biblioteca descriu cada port d'àudio que declara un plugin i qui fa córrer el plugin jutja si pot portar aquella disposició i la refusa pel nom en lloc de reduir-la.
"Un sol client JACK per a una cadena: què estalvia i què no"
/notes/one-jack-client-for-a-chain
Fer córrer N plugins en sèrie dins d'un sol client JACK, en lloc de N clients enllaçats en sèrie, és idèntic bit a bit i retalla entre un 30 i un 56 % el temps final del cicle a la mediana i un terç o més la CPU de l'amfitrió, sense cap xrun i sense empitjorar la cua; l'estalvi són els despertars, no els plugins.
"Camins d'allotjament comparats: mod-host, omx-clap-host, l'adaptador LV2 i dins del procés"
/notes/hosting-paths-compared
Els mateixos plugins costen el mateix per plugin en tots els camins d'allotjament, amb un microsegon de diferència i cap camí no afegeix latència. Les diferències a tot el graf vénen dels estats de repòs de la CPU i del nombre de nodes, no de com un amfitrió fa córrer un plugin; el que separa els camins és la memòria, l'arrencada i el que s'emporta una fallada.
"Estats de repòs de la CPU i allotjament de plugins: què s'hi guanya retenint cpu_dma_latency"
/notes/cpu-idle-states-and-plugin-hosting
Retenir /dev/cpu_dma_latency a 10 µs, perquè cap nucli no dormi més profund que C1, retalla de tres a cinc vegades el cicle del graf d'àudio en tots els amfitrions mesurats i n'elimina els excessos, per un o quatre watts; retenir-lo a 0 costa seixanta watts per una mica més. Amb la retenció, l'avantatge de mod-host sobre els altres amfitrions desapareix.
"L'adaptador LV2 comparat amb mod-host i jalv: mida i estructura"
/notes/the-lv2-adapter-against-mod-host-and-jalv
L'adaptador LV2 que presenta un plugin LV2 com un plugin CLAP fa les mateixes crides a lilv i en el mateix ordre que mod-host i jalv. El seu codi és més petit i té menys branques que el nucli de mod-host i és 1,4 vegades el de jalv; gairebé tota aquesta diferència són funcions que el contracte CLAP exigeix i que jalv no ofereix.