Differenze tra le versioni di "Subsistema Seq: Il Client di Alsa e le sue porte"
| Riga 1: | Riga 1: | ||
| − | + | =ALSA ed i suoi Client= | |
| − | Poiché il ''device'' è genericamente un elemento che assume ogni applicazione come ''fonte'' e come ''contenitore'' del suo flusso di dati; tali applicazioni - riferendosi tutte con il dispositivo di ALSA - assumono la denominazione di ''Client'' | + | Poiché il ''device'' è genericamente un elemento che assume ogni applicazione come ''fonte'' e come ''contenitore'' del suo flusso di dati; tali applicazioni - riferendosi tutte con il dispositivo di ALSA - assumono la denominazione di ''Client'' <SUP>[[[#Note:|Nota 1]]]</sup>. |
| − | In particolare la gestione reale dei dati Midi è esercitata dai programmi dell'utente e dall'hardware, mentre la funzione più generale del sistema ALSA è quella semplicemente di inviare i predetti dati ''nel momento giusto al Client giusto''. In ciò il sistema ALSA si configura esso stesso come un particolare ''sequencer'', in quanto la sua gestione dei dati si sostanzia nella specifica funzione della loro "''temporizzazione''": se un evento ha | + | <BR>Sia i controller dell'hardware che i vari programmi dell'utente non sono altro che "''Client''" di ALSA. Quest'ultimo, a sua volta, assume la caratteristica e le funzioni di loro "''Server''". In tal senso ALSA è come un sistema operativo, che mette in comunicazione il software applicativo con l'hardware, seguendo un modello preciso. Esso coordina i due lati di chi genera gli eventi, e di chi li consuma/esegue; ed entrambi, nella terminologia ALSA, sono appunto semplicemente "''Client'' ". |
| − | <p>Da quanto detto, ogni nostro programma di gestione dei dati Midi dovrà essere pensato e strutturato necessariamente come " | + | <BR>In particolare la gestione reale dei dati Midi è esercitata dai programmi dell'utente e dall'hardware, mentre la funzione più generale del sistema ALSA è quella semplicemente di inviare i predetti dati ''nel momento giusto al Client giusto''. In ciò il sistema ALSA si configura esso stesso come un particolare ''sequencer'', in quanto la sua gestione dei dati si sostanzia nella specifica funzione della loro "''temporizzazione''": se un evento ha inizio in un determinato momento, deve avere termine in un altro preciso momento, così come stabilito dai dati Midi inviati. Questo è precipuamente il compito del sub-sistema ''seq'' di ALSA. |
| + | <p>Da quanto detto, ogni nostro programma di gestione dei dati Midi dovrà essere pensato e strutturato necessariamente come "''Client'' " del sistema ALSA.</p> | ||
| + | =Le porte dei Client= | ||
| + | I ''Client'', come già detto si relazionano con il sistema ALSA (o più precisamente con i suoi ''sub-sistemi'') ed eventualmente con altri Client. <SUP>[[[#Note:|Nota 2]]]</sup> | ||
| + | <BR>Tale relazione si sostanzia come possibile scambio reciproco di dati. Affinché i dati possano uscire ed entrare da tali elementi, è necessario che i ''Client'' abbiano delle ''porte'' attraverso le quali far entrare ed uscire i dati. Inoltre è necessario che tra ''Client'' e ''Server'' si stabilisca una "''connessione'' ". | ||
| + | <p>Di conseguenza ai nostri programmi, dopo essere stati pensati come ''Client'', dovranno essere create le ''porte'' necessarie per consentire loro di scambiare dati con il sub-sistema "''seq'' " di ALSA.</p> | ||
| − | == | + | ===Capacità in ''lettura'' ed in ''scrittura'' delle porte dei ''Client''=== |
| − | + | La modalità di connessione di una porta di un dispositivo con gli altri dispositivi è detta "''Capacità'' " della porta. | |
| − | < | + | <p>Ciascuna porta può essere abilitata (cioè possedere una propria "''capacità'' ") in "Scrittura" o in "Lettura" oppure in entrambe le modalità (DUPLEX). |
| + | <BR>Va precisato, però, che la "''capacità''" di una porta di un ''Client'' di ALSA è una proprietà considerata ''<SPAN Style="text-decoration:underline">dal punto di vista degli altri dispositivi''</span> rispetto al ''Client'' medesimo che possiede la porta con tale capacità. | ||
| + | <BR>Considerata la "''capacità'' " della porta dal punto di vista del ''Client'' di ALSA al quale tale porta appartiene, se essa è in: | ||
| + | "Lettura", significa che la porta consente di inviare (''scrivere'') eventi ad altre porte; | ||
| − | + | "Scrittura" significa che la porta consente di ricevere (''leggere'') eventi da altre porte. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | Al contrario, ovviamente, considerata la "''capacità'' " della porta di un ''Client'' dal punto di vista degli altri ''Client'' di ALSA:</p> | |
| + | <p>* <b>READ</b>, significa che la porta è ''<SPAN Style="text-decoration:underline">leggibile da un altro</span>'' dispositivo. Attraverso questa sua porta con capacità READ il dispositivo, che chiameremo "A", invia dati al dispositivo B, il quale, appunto, "legge" (ossia, "riceve") i dati trasmessi dal dispositivo A. In tal caso il nostro programma sarà un dispositivo con porta avente caratteristica di "''Uscita'' " (OUTPUT);</p> | ||
| + | <p>* <b>WRITE</b>, significa che la porta è ''<SPAN Style="text-decoration:underline">scrivibile da un altro</span>'' dispositivo. Attraverso la sua porta con capacità WRITE il dispositivo A legge, ossia "riceve", i dati scritti, ossia "inviati, dal dispositivo B. In tal caso il nostro programma sarà un dispositivo con porta avente caratteristica di "''Entrata'' " (INPUT).</p> | ||
| + | <p>Ripetiamo che concettualmente la definizione della "''capacità'' " di una porta va sempre considerata ''dal punto di vista dell'altro dispositivo'', e <b>non</b> da quello del dispositivo al quale essa appartiene. | ||
| − | |||
| + | =Note= | ||
[1] Il ''Client'' è un componente (hardware o software) che si serve delle funzionalità e dei servizi di un altro componente (hardware o software), il ''Server''. | [1] Il ''Client'' è un componente (hardware o software) che si serve delle funzionalità e dei servizi di un altro componente (hardware o software), il ''Server''. | ||
| + | <BR>Sui ''Client'' in ALSA vedere: https://www.alsa-project.org/alsa-doc/alsa-lib/seq.html | ||
[2] Un esempio può essere la connessione fra un Client e QSynth: il client-Gambas si connette al client-QSynth, ma usando ALSA. Se mancasse uno dei tre, la cosa non funzionerebbe. Del resto l'uso corrente di ALSA è solo basilare; per esempio ci si potrebbe connettere a più di un dispositivo per inviare e ricevere dati, magari a dispositivi che risiedono su un altro computer. E', dunque, possibile instaurare un rapporto tra ''client'' proprio grazie ad ALSA. Nell'esempio riportato la connessione corretta è Client/Gambas-->ALSA-->Client/QSynth: anche se tale passaggio per ALSA non è rinvenibile da nessuna parte, un evento che va da un client-Gambas a QSynth deve passare da ALSA. | [2] Un esempio può essere la connessione fra un Client e QSynth: il client-Gambas si connette al client-QSynth, ma usando ALSA. Se mancasse uno dei tre, la cosa non funzionerebbe. Del resto l'uso corrente di ALSA è solo basilare; per esempio ci si potrebbe connettere a più di un dispositivo per inviare e ricevere dati, magari a dispositivi che risiedono su un altro computer. E', dunque, possibile instaurare un rapporto tra ''client'' proprio grazie ad ALSA. Nell'esempio riportato la connessione corretta è Client/Gambas-->ALSA-->Client/QSynth: anche se tale passaggio per ALSA non è rinvenibile da nessuna parte, un evento che va da un client-Gambas a QSynth deve passare da ALSA. | ||
Versione delle 04:30, 9 set 2020
Indice
ALSA ed i suoi Client
Poiché il device è genericamente un elemento che assume ogni applicazione come fonte e come contenitore del suo flusso di dati; tali applicazioni - riferendosi tutte con il dispositivo di ALSA - assumono la denominazione di Client [Nota 1].
Sia i controller dell'hardware che i vari programmi dell'utente non sono altro che "Client" di ALSA. Quest'ultimo, a sua volta, assume la caratteristica e le funzioni di loro "Server". In tal senso ALSA è come un sistema operativo, che mette in comunicazione il software applicativo con l'hardware, seguendo un modello preciso. Esso coordina i due lati di chi genera gli eventi, e di chi li consuma/esegue; ed entrambi, nella terminologia ALSA, sono appunto semplicemente "Client ".
In particolare la gestione reale dei dati Midi è esercitata dai programmi dell'utente e dall'hardware, mentre la funzione più generale del sistema ALSA è quella semplicemente di inviare i predetti dati nel momento giusto al Client giusto. In ciò il sistema ALSA si configura esso stesso come un particolare sequencer, in quanto la sua gestione dei dati si sostanzia nella specifica funzione della loro "temporizzazione": se un evento ha inizio in un determinato momento, deve avere termine in un altro preciso momento, così come stabilito dai dati Midi inviati. Questo è precipuamente il compito del sub-sistema seq di ALSA.
Da quanto detto, ogni nostro programma di gestione dei dati Midi dovrà essere pensato e strutturato necessariamente come "Client " del sistema ALSA.
Le porte dei Client
I Client, come già detto si relazionano con il sistema ALSA (o più precisamente con i suoi sub-sistemi) ed eventualmente con altri Client. [Nota 2]
Tale relazione si sostanzia come possibile scambio reciproco di dati. Affinché i dati possano uscire ed entrare da tali elementi, è necessario che i Client abbiano delle porte attraverso le quali far entrare ed uscire i dati. Inoltre è necessario che tra Client e Server si stabilisca una "connessione ".
Di conseguenza ai nostri programmi, dopo essere stati pensati come Client, dovranno essere create le porte necessarie per consentire loro di scambiare dati con il sub-sistema "seq " di ALSA.
Capacità in lettura ed in scrittura delle porte dei Client
La modalità di connessione di una porta di un dispositivo con gli altri dispositivi è detta "Capacità " della porta.
Ciascuna porta può essere abilitata (cioè possedere una propria "capacità ") in "Scrittura" o in "Lettura" oppure in entrambe le modalità (DUPLEX).
Va precisato, però, che la "capacità" di una porta di un Client di ALSA è una proprietà considerata dal punto di vista degli altri dispositivi rispetto al Client medesimo che possiede la porta con tale capacità.
Considerata la "capacità " della porta dal punto di vista del Client di ALSA al quale tale porta appartiene, se essa è in:
"Lettura", significa che la porta consente di inviare (scrivere) eventi ad altre porte;
"Scrittura" significa che la porta consente di ricevere (leggere) eventi da altre porte.
Al contrario, ovviamente, considerata la "capacità " della porta di un Client dal punto di vista degli altri Client di ALSA:
* READ, significa che la porta è leggibile da un altro dispositivo. Attraverso questa sua porta con capacità READ il dispositivo, che chiameremo "A", invia dati al dispositivo B, il quale, appunto, "legge" (ossia, "riceve") i dati trasmessi dal dispositivo A. In tal caso il nostro programma sarà un dispositivo con porta avente caratteristica di "Uscita " (OUTPUT);
* WRITE, significa che la porta è scrivibile da un altro dispositivo. Attraverso la sua porta con capacità WRITE il dispositivo A legge, ossia "riceve", i dati scritti, ossia "inviati, dal dispositivo B. In tal caso il nostro programma sarà un dispositivo con porta avente caratteristica di "Entrata " (INPUT).
Ripetiamo che concettualmente la definizione della "capacità " di una porta va sempre considerata dal punto di vista dell'altro dispositivo, e non da quello del dispositivo al quale essa appartiene.
Note
[1] Il Client è un componente (hardware o software) che si serve delle funzionalità e dei servizi di un altro componente (hardware o software), il Server.
Sui Client in ALSA vedere: https://www.alsa-project.org/alsa-doc/alsa-lib/seq.html
