Differenze tra le versioni di "Alsa e Gambas: Ricezione con un programma esterno di supporto"
| Riga 1: | Riga 1: | ||
Procederemo, ora, a mostrare un secondo metodo, che fa uso di una ''pipe'' da un programma esterno, scritto in linguaggio C, con il quale evitare ogni possibile evidente latenza. Questa soluzione è allo stato attuale l'unico modo corretto di inserire nel ''message loop'' i messaggi Midi che ci interessano. | Procederemo, ora, a mostrare un secondo metodo, che fa uso di una ''pipe'' da un programma esterno, scritto in linguaggio C, con il quale evitare ogni possibile evidente latenza. Questa soluzione è allo stato attuale l'unico modo corretto di inserire nel ''message loop'' i messaggi Midi che ci interessano. | ||
| − | <BR>Tale soluzione si rende necessaria, poiché con ALSA il meccanismo usato solitamente è di controllare gli eventi dal ''device'' Midi nel ''Main Message Loop'', basato sulle funzioni ''poll()'' e ''select()''. ALSA, però, non viene letto come se fosse un ''file'', e quindi uno ''stream'' di Gambas non è in grado di sollevare un evento, tipo ''stream_Read()'', usando la funzione ''poll()'', | + | <BR>Tale soluzione si rende necessaria, poiché con ALSA il meccanismo usato solitamente è di controllare gli eventi dal ''device'' Midi nel ''Main Message Loop'', basato sulle funzioni ''poll()'' e ''select()''. ALSA, però, non viene letto come se fosse un ''file'', e quindi uno ''stream'' di Gambas non è in grado di sollevare un evento, tipo ''stream_Read()'', usando la funzione ''poll()''. Questa funzione, in breve, ci dice se c'è qualche dato da leggere. La procedura, dunque, prevede che dapprima vengono ottenuti da ALSA i descrittori dei file; successivamente viene utilizzata la chiamata alla funzione ''poll()'' per vedere ''se'' c'è quealcosa da leggere. Più precisamente si chiede al sistema di controllare tutti i ''file descriptors'', e poi si va a leggere con la funzione di ALSA: ''snd_seq_event_input(snd_seqt * seq, snd_seq_event_t ** ev)''. Purtroppo, tale procedura non è possibile integrarla nell'''event loop'' di Gambas. Sarebbe davvero risolutivo, se Gambas permettesse di inserire nel ''message loop'' dei ''file descriptor'' arbitrari. Come abbiamo cercato di spiegare, con Gambas sono inutilizzabili i fdescrittori di file che ci passano le funzioni di ALSA, poiché non esiste (...speriamo in futuro !) una funzione per interagire con il ''message loop''. Se Gambas fosse più elastico, darebbe la possibilità di personalizzare il ''message loop'', dato che è cosa buona e giusta inserire appunto nel ''message loop'' i dati ed i valori che vogliamo. Attualmente, purtroppo, ciò può essere fatto soltanto attraverso l'uso di componenti scritti in C++ che usano l'API interna. |
| − | < | + | <BR>I semplici programmi in C, come arecordmidi e aseqdump, per leggere gli eventi per leggere gli eventi dalla predetta funzione di ALSA, eseguono un ciclo. Ciò ha un senso, poiché tali semplici programmi di ricezione di eventi Midi svolgono soltanto una sola applicazione: quella di leggere dati. Ma se un programma GUI deve anche gestire la grafica, il ciclo non va bene. Noi, allora, abbiamo insomma bisogno di un modo efficace per essere avvertiti che c'è qualche dato da leggere. Cosa, questa, che potrebbe essere fatta anche con un ciclo, se in modo sicuro vi fossero dati da leggere. Se, però non c'è niente da eggere, non può essere usato un ciclo, sarebbe una perdita di tempo ed inutile uso della CPU e delle altre risorse di sistema. |
<P>E', quindi, necessario un evento di Gambas.</p> | <P>E', quindi, necessario un evento di Gambas.</p> | ||
Versione delle 16:43, 15 set 2011
Procederemo, ora, a mostrare un secondo metodo, che fa uso di una pipe da un programma esterno, scritto in linguaggio C, con il quale evitare ogni possibile evidente latenza. Questa soluzione è allo stato attuale l'unico modo corretto di inserire nel message loop i messaggi Midi che ci interessano.
Tale soluzione si rende necessaria, poiché con ALSA il meccanismo usato solitamente è di controllare gli eventi dal device Midi nel Main Message Loop, basato sulle funzioni poll() e select(). ALSA, però, non viene letto come se fosse un file, e quindi uno stream di Gambas non è in grado di sollevare un evento, tipo stream_Read(), usando la funzione poll(). Questa funzione, in breve, ci dice se c'è qualche dato da leggere. La procedura, dunque, prevede che dapprima vengono ottenuti da ALSA i descrittori dei file; successivamente viene utilizzata la chiamata alla funzione poll() per vedere se c'è quealcosa da leggere. Più precisamente si chiede al sistema di controllare tutti i file descriptors, e poi si va a leggere con la funzione di ALSA: snd_seq_event_input(snd_seqt * seq, snd_seq_event_t ** ev). Purtroppo, tale procedura non è possibile integrarla nell'event loop di Gambas. Sarebbe davvero risolutivo, se Gambas permettesse di inserire nel message loop dei file descriptor arbitrari. Come abbiamo cercato di spiegare, con Gambas sono inutilizzabili i fdescrittori di file che ci passano le funzioni di ALSA, poiché non esiste (...speriamo in futuro !) una funzione per interagire con il message loop. Se Gambas fosse più elastico, darebbe la possibilità di personalizzare il message loop, dato che è cosa buona e giusta inserire appunto nel message loop i dati ed i valori che vogliamo. Attualmente, purtroppo, ciò può essere fatto soltanto attraverso l'uso di componenti scritti in C++ che usano l'API interna.
I semplici programmi in C, come arecordmidi e aseqdump, per leggere gli eventi per leggere gli eventi dalla predetta funzione di ALSA, eseguono un ciclo. Ciò ha un senso, poiché tali semplici programmi di ricezione di eventi Midi svolgono soltanto una sola applicazione: quella di leggere dati. Ma se un programma GUI deve anche gestire la grafica, il ciclo non va bene. Noi, allora, abbiamo insomma bisogno di un modo efficace per essere avvertiti che c'è qualche dato da leggere. Cosa, questa, che potrebbe essere fatta anche con un ciclo, se in modo sicuro vi fossero dati da leggere. Se, però non c'è niente da eggere, non può essere usato un ciclo, sarebbe una perdita di tempo ed inutile uso della CPU e delle altre risorse di sistema.
E', quindi, necessario un evento di Gambas.
La soluzione di un programma esterno di supporto
Per risolvere il problema relativo all'input degli eventi da ALSA, è possibile pensare ad una soluzione esterna combinata: si tratterebbe di scrivere un breve programma C, cosa che quindi permetterebbe di avere accesso alle piene funzionalità del sistema. Poi da Gambas si farebbe un Exec a quel programma, per poterne leggere lo standard output con un watch. Il programma di supporto in C normalmente dormirebbe; qualora, però, dovesse trovare eventi da ALSA, li manderebbe fuori. Il programma principale di Gambas potrebbe intercettare e leggere tali dati in output dal programma C con un evento del tipo process_Read.
< Pagina in costruzione >
