Old:Low-latency 2.6 kernel per applicazioni audio realtime: differenze tra le versioni

Da Guide@Debianizzati.Org.
Vai alla navigazione Vai alla ricerca
m (→‎La patch realtime-preemption: piccoli aggiornamenti)
 
(30 versioni intermedie di 7 utenti non mostrate)
Riga 1: Riga 1:
Allora iniziamo, prima di tutto chiariamo un paio di cose, questo emulatore � nato per poter giocare con i nostri giochi "originali" psx e psx-one, per poter giocare con giochi psx sul nostro fidato debian-box necessitiamo di un processore medio/potente e di una scheda accelerata, e naturalmente i nostri giochi preferiti.
{{Old}}
== Introduzione ==
Questa è una breve guida su come configurare il sistema per poter eseguire applicazioni audio realtime.


bene dopo questo preamobolo iniziamo.
Per chi non conoscesse il mondo dell'audio professionale su GNU/Linux consiglio questo magnifico sito introduttivo:
Scarichiamo il pacchetto contenente l'emulatore:
 
* [http://www.emillo.net/audio_midi emillo.net]
 
Ci sono '''due passi''' distinti illustrati nella guida: ''il primo'' è patchare un kernel 2.6 con la patch '''realtime-preemption''' di ''Ingo Molnar'' per ottenere un kernel con la più bassa latenza possibile; ''il secondo'' è invece permettere a normali utenti l'esecuzione di applicazioni in modalità realtime.
 
Il kernel 2.6 ha raggiunto ormai delle prestazioni molto buone per quanto riguarda la latenza (anni luce avanti rispetto al 2.4). Normalmente è dunque sufficiente configurare il sistema per permettere ai normali utenti di eseguire applicazioni realtime (''secondo passo'').
 
Se invece si vuole, non solo ridurre sotto la soglia (indicativa) dei ~ 5 ms la latenza minima ottenibile, ma soprattutto aumentare notevolmente l'affidabilità del sistema nel rispettare le basse latenze bisogna usare la patch realtime-preemption (''primo passo''). È questo il caso, ad esempio, se si vuole lavorare in full-duplex su diverse tracce in realtime, ''senza correre il rischio di xrun'' (ovvero interruzioni del flusso audio). Oppure se si vuole suonare un sintetizzatore software usando la minima latenza possibile.
 
La patch realtime-preemption (per quanto perfettamente usabile) continua ad essere sviluppata incessantemente, e le release sono spesso giornaliere. Il kernel a cui si applica la patch è sempre l'ultimo kernel stabile o, spesso, l'ultimo RC. Nella guida, a puro titolo esemplificativo, mi riferirò ad un kernel e ad una versione di patch specifica, anche se queste versioni diventeranno presto obsolete.
 
{{Warningbox|Se non siete a vostro completo agio a compilare e patchare il kernel questa non è la via che fa per voi. Consiglio, in tal caso, di usare un setup per l'audio professionale pronto per l'uso, come la distribuzione [http://64studio.com/ 64 Studio] (disponibile sia per processori 64 bit che per 32bit). Se volete invece informazioni dettagliate su come compilare il kernel alla ''Debian-way'': [[Debian Kernel Howto]]. }}
 
== Dal kernel stabile all'RC ==
Consiglio di compilare l'ultima versione stabile del kernel, configurandola e testandola fino ad ottenere una configurazione ben funzionante. Come spunto potete usare [[Esempio configurazione kernel|questa configurazione]]. Nel mio caso ho usato il kernel 2.6.13.2 e la [[Debian Kernel Howto|Debian-way]] di compilare il kernel.
 
Una guida completa sulla configurazione e l'ottimizzazione di un [[kernel vanilla]] (e non solo) per applicazioni audio è la seguente:
 
* [http://demudi.agnula.info/wiki/Low-latencyKernelBuildingHowto Low-latency Kernel Building Howto].
 
La patch realtime-preemption più recente si applica solitamente ai kernel RC (Release Candidate). Questo perché Ingo Molnar segue sempre il kernel più recente (quindi usa le RC come base di partenza per la sua patch). Quando viene rilasciato un nuovo kernel stabile Ingo Molnar rilascia pach per il nuovo kernel stabile, ma dopo alcune settimane passa nuovamente a seguire l'ultima RC uscita nel frattempo.
 
Quindi, si hanno due possibilità:
# compilare l'ultimo kernel stabile con l'ultima patch rilasciata per quel kernel
# compilare l'ultimo kernel rc e usare la versione corrente della pacth.
 
Attualmente, ad esempio, l'ultimo kernel stabile, per il quale sia stata rilasciata la patch realtime preemption è il [ftp://ftp.it.kernel.org/pub/linux/kernel/v2.6/linux-2.6.14.tar.bz2 2.6.14] (non i successivi 2.6.14.x). Per tale kernel l'ultima patch disponibile è la [http://people.redhat.com/mingo/realtime-preempt/older/patch-2.6.14-rt22 2.6.14-rt22], come si può vedere [http://people.redhat.com/mingo/realtime-preempt/older/ qui].
 
Se invece si vuole usare l'[http://people.redhat.com/mingo/realtime-preempt/ ultima patch] realtime-preemption (attualmente 2.6.15-rc5-rt2) bisogna usare anche l'[ftp://ftp.it.kernel.org/pub/linux/kernel/v2.6/testing/ ultimo kernel RC].
 
Per passare da un kernel stabile ad un RC basta fare un <code>make oldconfig</code> in modo da configurare solo le nuove voci. Questo metodo "a due passi" permette di separare i problemi dovuti ad un eventuale errore di configurazione del kernel stabile dai problemi potenzialmente introdotti dall'uso di un kernel RC non stabile.
 
== La patch realtime-preemption ==
L'archivio delle patch realtime-premption si trova a [http://people.redhat.com/mingo/realtime-preempt/ questo indirizzo]. La patch realtime-preemption usata di seguito (a puro titolo esemplificativo) è la 2.6.14-rc5-rt5, voi usate la versione più recente disponibile. La patch è un semplice file di testo. Il suo nome è del tipo <code>patch-''<kernel version>''-''<patch version>''</code>. Bisogna applicare la patch all'esatta versione del kernel indicata dal nome. Di seguito viene usata la [http://people.redhat.com/mingo/realtime-preempt/older/patch-2.6.14-rc5-rt5 versione rt5 applicata al kernel 2.6.14-rc5]. Tenete presente che nuove versioni della patch vengono rilasciate giornalmente.
 
Per applicare la patch basta copiarla in <code>/usr/src</code>, entrare della dir del kernel e lanciare il comando, nel mio esempio:
 
<pre>$ cat ../patch-2.6.14-rc3-rt2 | patch -p1 -t</pre>
 
A questo punto nuovamente un <code>make oldconfg</code> ci permetterà di configurare le voci inserite dalla patch. Assicurarsi di scegliere '''Complete Preemption (Real-Time)''' in:


<pre>
<pre>
$ wget http://www.epsxe.com/files/epsxe160lin.zip
Processor type and features  --->
  Preemption Mode (Complete Preemption (Real-Time))
</pre>
</pre>


Se non potete rinuciare all interfaccia grafica, vi consiglio di scaricare anche il front-end:
per il resto ho lasciato tutte le altre nuove voci su NO (la maggior parte di esse serve, infatti, per attivare vari strumenti di debug).
<pre>
 
$ wget http://www.epsxe.com/files/ePSXeCutor1060.zip
Non ci resta che compilare il kernel:
</pre>
 
<pre>$ fakeroot make-kpkg --append-to-version -realtime --revision 0.1 kernel_image</pre>
 
ed installare il pacchetto, per ulteriori informazioni su questo passaggio: [[Debian Kernel Howto]].
 
 
== Modalità realtime e realtime scheduling ==
La modalità realtime è un particolare privilegio di esecuzione che un'applicazione può avere. Questa modalità permette ad una applicazione di avere accesso alla CPU con la massima priorità (rispetto ad ogni altra applicazione in attesa) ogni volta che venga richiesto, impedendo inoltre che un'altra applicazione possa a sua volta interrompere l'esecuzione (a meno che non sia anch'essa realtime).
 
Questo permette di tenere in esecuzione applicazioni a bassa latenza, senza il rischio che altre applicazioni non-realtime possano disturbarle. Si capisce come questa modalità sia importantissima nelle applicazioni audio professionali (ad esempio una sessione di registrazione non verrà mai interrotta anche se molte applicazioni non realtime saturano la CPU!).
 
D'altro canto, questa modalità pone dei seri problemi di sicurezza dato che un'applicazione potrebbe (a causa di un errore o di un comportamento malevolo) occupare la CPU per un tempo indefinito, senza poter essere interrotta, impedendo dunque la normale applicazione degli altri programmi.
 
Normalmente, quindi, solo root ha i privilegi per lanciare applicazioni in modalità realtime. Questo è un problema, dato che (ad esempio) Jack e tutte le applicazioni che vi si connettono dovrebbero essere lanciate da root per poter funzionare in modalità realtime, e questo costituirebbe un ancor più grosso problema di sicurezza.
 
Per risolvere il problema bisogna consentire l'uso della modalità realtime anche a normali utenti ma in maniera "controllata".


bene ora scompattiamo i due archivi in una cartella a nostra scelta (es <tt>/home/utente/psx</tt>):
Il modo più semplice consiste nell'usare gli '''rlimits''', ovvero editare il file <code>/etc/security/limits.conf</code> per consentire ad un utente od ad un gruppo di eseguire applicazioni in modalità realtime. Questo metodo ormai è pienamente supportato da Debian Etch (''stabile'') in poi.


<pre>
Un secondo metodo ormai obsoleto consiste nell'usare un modulo del kernel chiamato <code>realtime-lsm</code>. Questa procedura è più lunga e può creare problemi di sicurezza.
$ mkdir psx
$ cd psx
$ unzip /home/utente/epsxe160lin.zip
$ unzip /homeutente/ePSXeCutor1060.zip
</pre>


ora abbiamo nella directory <tt>/home/utente/psx</tt> l'emulatore e il suo frontend. Ci servono ancora i plugin per grafica, suono e lettura cd:
Entrambi gli approcci possono essere usati sia con kernel vanilla che con kernel realtime-preemption.


<pre>
=== Usare gli rlimits ===
$ wget http://www.pbernert.com/gpupetexgl206.tar.gz
È presente nel kernel un nuovo meccanismo più sicuro per concedere i privilegi di realtime chiamato rlimits. Rlimits sostituisce completamente il vecchio e insicuro modulo <code>realtime-lsm</code>.
$ wget http://www.pbernert.com/cdrpeops104.zip
$ wget http://www.pbernert.com/spupeopsoss109.tar.gz
</pre>


Ora abbiamo nella nostra home i tre plugin in serie: video, cdr, audio.
Gli rlimits sono supportati da PAM dalla versione 0.80, le versioni precedenti richiedono una patch.
Scompattiamo i plugin cd-r e audio nella sub-directory <tt>/home/utente/psx/plugins</tt>:
Fortunatamente la versione di PAM in Debian Etch, pur essendo una 0.79, include la già questa patch. Per la [[oldstable]] Sarge la patch deve essere applicata manualmente (vedi dopo).


<pre>
Quindi l'unica cosa da fare in Debian per abilitare il gruppo '''<code>audio</code>''' all'esecuzione di processi in modalità realtime è aggiungere al file <code>/etc/security/limits.conf</code> le seguenti righe:
$ cd /home/utente/psx/plugins
$ unzip /home/utente/cdrpeops104.zip
$ tar xvfz /home/utente/spupeopsoss109.tar.gz
</pre>


Ora rimane solo da estrarre i plugin per il video;
@audio          -      nice            -10
questo lo estraiamo in un altra directory (dopo vedremo il perch�):
@audio          -      rtprio          99
@audio          -      memlock        250000


<pre>
Ovviamente perché le modifiche abbiano effetto si deve rieseguire il login.
$ cd /home/utente
$ mkdir video
$ cd video
$ tar xvfz /home/utente/video/gpupetexgl206.tar.gz
$ mv gpuPeteXGL2.cfg /home/utente/psx
$ mv cfgPeteXGL2 /home/utente/psx
$ mv libgpuPeteXGL2.so.2.0.6 /home/psx/plugins
</pre>


Ora ci manca solo il bin del bios, questo per� lo dovrete trovare voi su google, in quanto non � legale detenere la suddetta se non si � in possesso di una psx originale.
Potete controllare che gli rlimits siano settati correttamente lanciando jack:


Il nome del file � <tt>'''scph1001.bin'''</tt>
<pre> $ jackd -R -d alsa -S</pre>
e v� messo nella subdirectory <tt>/home/utente/psx/bios</tt>.


Ora proviamo se funziona:
In caso di problemi con la modalità realtime si vedranno messaggi del tipo:


<pre>
cannot use real-time scheduling (FIFO at priority 10) [...]
$ cd /home/utente/psx
(1: Operation not permitted)
$ ./epsxe
</pre>


Se si apre la finestra siamo a cavallo. Bene, ora possiamo configurare il nostro emulatore.
'''Nota''': Per la [[oldstable]] '''Debian Sarge''' si può installare il pacchetto PAM patchato installando <code>libpam-modules</code> da [http://techweb.rfa.org/debrfa/dists/sarge/main/binary-i386/ qui].


Clicchiamo sul men� config e sul sotto men� bios, e impostiamo la dir dove abbiamo estratto in precedenza il bios. Stessa cosa per la voce video.  
=== Il modulo <code>realtime-lsm</code> ===
{{Warningbox|Questa procedura è obsoleta e non è più stata verificata da quando Etch è diventata stabile ed ha incluso il supporto nativo per gli rlimits. È lasciata solo per motivi storici e didattici.}}


Dopo aver selezionato il plugin adatto facciamo click su test:
Il modulo <code>realtime-lsm</code> permette ad un normale utente inserito nel gruppo <code>audio</code> di eseguire applicazioni in modalità realtime. Questo è il vecchio approccio, che verrà man mano sostituito nelle varie distro dall'uso degli rlimits (vedi oltre).
se ci appare una finesta che dice ''plugin work correctly'' siamo a cavallo.


Settare nello stesso modo l'audio, e stessa cosa pure per il cdrom.
Su Debian l'installazione del modulo è molto semplice: basta installare il pacchetto <code>realtime-lsm-source</code> ed usare <code>[[Pagina di manuale di module-assistant|module-assistant]]</code> per compilare e pacchettizzare il modulo.  


Ora passiamo a configurare la tastiera. Click sul menu config e su GamePad--gamepad1. Qui possiamo selezionare i tasti con cui ci troviamo meglio.
In pratica, dopo aver fatto il boot del kernel per il quale si vuole installare il modulo, (e aver installato <code>realtime-lsm-source</code>) basta il seguente comando:


Ora non rimane che testare se tutto funziona:
<pre>$ m-a build realtime-lsm</pre>
click su file---runCDROM, happy game.


In caso di malfunzionamento video o audio, andiamo alla pagina dei plugin e proviamo con altri.
per compilare e creare un pacchetto per il modulo. A questo punto non ci resta che installare il pacchetto <code>realtime-lsm</code> creato.
Quelli qui proposti funzionano sulla maggior parte delle macchine. Andando nella sezione configure dei vari plugin � possibile settare al meglio i suddetti in base alla potenza della macchina su cui viene fatto girare l'emulatore.


Vi consiglio di crearvi un link simbolico in <tt>/bin</tt> cosi da poter lanciare l'emultaore solo scrivendo <tt>epsxe</tt>:
Questo modulo non è stato accettato (ne lo sarà mai) nel tree ufficiale del kernel per i potenziali problemi di sicurezza legati al suo utilizzo. In particolare per il suo corretto funzionamento devono essere attivate le seguenti voci di configurazione del kernel:


<pre>
<pre>
$ su
Security options --->
password di root.
[*] Enable different security model
# cd /bin
<M>  Default Linux Capabilities
# ln -s /home/utente/psx/epsxe epsxe
</pre>
</pre>


==Link==
''(l'ultima voce deve necessariamente essere un modulo!)''
 
Nei recenti kernel binari di Etch le precedenti condizioni non sono soddisfatte, per cui il modulo '''realtime-lsm''' non funzionerà con tali kernel. Inoltre il modulo realtime-lsm è ormai ufficialmente deprecato in Debian Etch.


* http://www.epsxe.com/news.php Home Page dell proggetto ePSXe
In questi casi bisognerà ricompilare il kernel oppure usare l'approccio tramite rlimits.


* http://www.pbernert.com/ plugin
== Conclusioni ==
Con un kernel così ottimizzato si raggiungono prestazioni realtime davvero spinte. Io ad esempio, con una modestissima SB Audigy 1 posso fare partire jack a 32 frame x 2 periodi @ 48000Hz (latenza 1.3 ms!) in modalità solo playback. Qualche xrun avviene ancora a latenze così basse se si eseguono altre operazioni sulla macchina. Per avere la massima affidabilità in full-duplex utilizzo usualmente jack a 128x2 @ 48000Hz.


* http://www.pbernert.com/pluginpetedoc_ita_104.zip FAQ italiane
In bocca al lupo e...


Happy Debian!


Per qualsiasi problema il forum � a vostra disposizione, oppure potete contattarmi per email o messaggio privato.
== Links ==


----
* http://www.emillo.net/home
Autore: debian
* http://www.djcj.org/LAU/guide/index.php
* http://tapas.affenbande.org/?page_id=3
* [http://demudi.agnula.org/wiki/Low-latencyKernelBuildingHowto Low-latency Kernel Building How-to]
* [http://alsa.opensrc.org/RealtimeKernelAndPAM Alsa Wiki: Realtime Kernel And PAM]

Versione attuale delle 16:21, 30 nov 2019

Emblem-important.png Attenzione. Questa guida è obsoleta. Viene mantenuta sul Wiki solo per motivi di natura storica e didattica.


Introduzione

Questa è una breve guida su come configurare il sistema per poter eseguire applicazioni audio realtime.

Per chi non conoscesse il mondo dell'audio professionale su GNU/Linux consiglio questo magnifico sito introduttivo:

Ci sono due passi distinti illustrati nella guida: il primo è patchare un kernel 2.6 con la patch realtime-preemption di Ingo Molnar per ottenere un kernel con la più bassa latenza possibile; il secondo è invece permettere a normali utenti l'esecuzione di applicazioni in modalità realtime.

Il kernel 2.6 ha raggiunto ormai delle prestazioni molto buone per quanto riguarda la latenza (anni luce avanti rispetto al 2.4). Normalmente è dunque sufficiente configurare il sistema per permettere ai normali utenti di eseguire applicazioni realtime (secondo passo).

Se invece si vuole, non solo ridurre sotto la soglia (indicativa) dei ~ 5 ms la latenza minima ottenibile, ma soprattutto aumentare notevolmente l'affidabilità del sistema nel rispettare le basse latenze bisogna usare la patch realtime-preemption (primo passo). È questo il caso, ad esempio, se si vuole lavorare in full-duplex su diverse tracce in realtime, senza correre il rischio di xrun (ovvero interruzioni del flusso audio). Oppure se si vuole suonare un sintetizzatore software usando la minima latenza possibile.

La patch realtime-preemption (per quanto perfettamente usabile) continua ad essere sviluppata incessantemente, e le release sono spesso giornaliere. Il kernel a cui si applica la patch è sempre l'ultimo kernel stabile o, spesso, l'ultimo RC. Nella guida, a puro titolo esemplificativo, mi riferirò ad un kernel e ad una versione di patch specifica, anche se queste versioni diventeranno presto obsolete.

Warning.png ATTENZIONE
Se non siete a vostro completo agio a compilare e patchare il kernel questa non è la via che fa per voi. Consiglio, in tal caso, di usare un setup per l'audio professionale pronto per l'uso, come la distribuzione 64 Studio (disponibile sia per processori 64 bit che per 32bit). Se volete invece informazioni dettagliate su come compilare il kernel alla Debian-way: Debian Kernel Howto.


Dal kernel stabile all'RC

Consiglio di compilare l'ultima versione stabile del kernel, configurandola e testandola fino ad ottenere una configurazione ben funzionante. Come spunto potete usare questa configurazione. Nel mio caso ho usato il kernel 2.6.13.2 e la Debian-way di compilare il kernel.

Una guida completa sulla configurazione e l'ottimizzazione di un kernel vanilla (e non solo) per applicazioni audio è la seguente:

La patch realtime-preemption più recente si applica solitamente ai kernel RC (Release Candidate). Questo perché Ingo Molnar segue sempre il kernel più recente (quindi usa le RC come base di partenza per la sua patch). Quando viene rilasciato un nuovo kernel stabile Ingo Molnar rilascia pach per il nuovo kernel stabile, ma dopo alcune settimane passa nuovamente a seguire l'ultima RC uscita nel frattempo.

Quindi, si hanno due possibilità:

  1. compilare l'ultimo kernel stabile con l'ultima patch rilasciata per quel kernel
  2. compilare l'ultimo kernel rc e usare la versione corrente della pacth.

Attualmente, ad esempio, l'ultimo kernel stabile, per il quale sia stata rilasciata la patch realtime preemption è il 2.6.14 (non i successivi 2.6.14.x). Per tale kernel l'ultima patch disponibile è la 2.6.14-rt22, come si può vedere qui.

Se invece si vuole usare l'ultima patch realtime-preemption (attualmente 2.6.15-rc5-rt2) bisogna usare anche l'ultimo kernel RC.

Per passare da un kernel stabile ad un RC basta fare un make oldconfig in modo da configurare solo le nuove voci. Questo metodo "a due passi" permette di separare i problemi dovuti ad un eventuale errore di configurazione del kernel stabile dai problemi potenzialmente introdotti dall'uso di un kernel RC non stabile.

La patch realtime-preemption

L'archivio delle patch realtime-premption si trova a questo indirizzo. La patch realtime-preemption usata di seguito (a puro titolo esemplificativo) è la 2.6.14-rc5-rt5, voi usate la versione più recente disponibile. La patch è un semplice file di testo. Il suo nome è del tipo patch-<kernel version>-<patch version>. Bisogna applicare la patch all'esatta versione del kernel indicata dal nome. Di seguito viene usata la versione rt5 applicata al kernel 2.6.14-rc5. Tenete presente che nuove versioni della patch vengono rilasciate giornalmente.

Per applicare la patch basta copiarla in /usr/src, entrare della dir del kernel e lanciare il comando, nel mio esempio:

$ cat ../patch-2.6.14-rc3-rt2 | patch -p1 -t

A questo punto nuovamente un make oldconfg ci permetterà di configurare le voci inserite dalla patch. Assicurarsi di scegliere Complete Preemption (Real-Time) in:

Processor type and features  --->
   Preemption Mode (Complete Preemption (Real-Time))

per il resto ho lasciato tutte le altre nuove voci su NO (la maggior parte di esse serve, infatti, per attivare vari strumenti di debug).

Non ci resta che compilare il kernel:

$ fakeroot make-kpkg --append-to-version -realtime --revision 0.1 kernel_image

ed installare il pacchetto, per ulteriori informazioni su questo passaggio: Debian Kernel Howto.


Modalità realtime e realtime scheduling

La modalità realtime è un particolare privilegio di esecuzione che un'applicazione può avere. Questa modalità permette ad una applicazione di avere accesso alla CPU con la massima priorità (rispetto ad ogni altra applicazione in attesa) ogni volta che venga richiesto, impedendo inoltre che un'altra applicazione possa a sua volta interrompere l'esecuzione (a meno che non sia anch'essa realtime).

Questo permette di tenere in esecuzione applicazioni a bassa latenza, senza il rischio che altre applicazioni non-realtime possano disturbarle. Si capisce come questa modalità sia importantissima nelle applicazioni audio professionali (ad esempio una sessione di registrazione non verrà mai interrotta anche se molte applicazioni non realtime saturano la CPU!).

D'altro canto, questa modalità pone dei seri problemi di sicurezza dato che un'applicazione potrebbe (a causa di un errore o di un comportamento malevolo) occupare la CPU per un tempo indefinito, senza poter essere interrotta, impedendo dunque la normale applicazione degli altri programmi.

Normalmente, quindi, solo root ha i privilegi per lanciare applicazioni in modalità realtime. Questo è un problema, dato che (ad esempio) Jack e tutte le applicazioni che vi si connettono dovrebbero essere lanciate da root per poter funzionare in modalità realtime, e questo costituirebbe un ancor più grosso problema di sicurezza.

Per risolvere il problema bisogna consentire l'uso della modalità realtime anche a normali utenti ma in maniera "controllata".

Il modo più semplice consiste nell'usare gli rlimits, ovvero editare il file /etc/security/limits.conf per consentire ad un utente od ad un gruppo di eseguire applicazioni in modalità realtime. Questo metodo ormai è pienamente supportato da Debian Etch (stabile) in poi.

Un secondo metodo ormai obsoleto consiste nell'usare un modulo del kernel chiamato realtime-lsm. Questa procedura è più lunga e può creare problemi di sicurezza.

Entrambi gli approcci possono essere usati sia con kernel vanilla che con kernel realtime-preemption.

Usare gli rlimits

È presente nel kernel un nuovo meccanismo più sicuro per concedere i privilegi di realtime chiamato rlimits. Rlimits sostituisce completamente il vecchio e insicuro modulo realtime-lsm.

Gli rlimits sono supportati da PAM dalla versione 0.80, le versioni precedenti richiedono una patch. Fortunatamente la versione di PAM in Debian Etch, pur essendo una 0.79, include la già questa patch. Per la oldstable Sarge la patch deve essere applicata manualmente (vedi dopo).

Quindi l'unica cosa da fare in Debian per abilitare il gruppo audio all'esecuzione di processi in modalità realtime è aggiungere al file /etc/security/limits.conf le seguenti righe:

@audio          -       nice            -10
@audio          -       rtprio          99
@audio          -       memlock         250000

Ovviamente perché le modifiche abbiano effetto si deve rieseguire il login.

Potete controllare che gli rlimits siano settati correttamente lanciando jack:

 $ jackd -R -d alsa -S

In caso di problemi con la modalità realtime si vedranno messaggi del tipo:

cannot use real-time scheduling (FIFO at priority 10) [...] 
(1: Operation not permitted)

Nota: Per la oldstable Debian Sarge si può installare il pacchetto PAM patchato installando libpam-modules da qui.

Il modulo realtime-lsm

Warning.png ATTENZIONE
Questa procedura è obsoleta e non è più stata verificata da quando Etch è diventata stabile ed ha incluso il supporto nativo per gli rlimits. È lasciata solo per motivi storici e didattici.


Il modulo realtime-lsm permette ad un normale utente inserito nel gruppo audio di eseguire applicazioni in modalità realtime. Questo è il vecchio approccio, che verrà man mano sostituito nelle varie distro dall'uso degli rlimits (vedi oltre).

Su Debian l'installazione del modulo è molto semplice: basta installare il pacchetto realtime-lsm-source ed usare module-assistant per compilare e pacchettizzare il modulo.

In pratica, dopo aver fatto il boot del kernel per il quale si vuole installare il modulo, (e aver installato realtime-lsm-source) basta il seguente comando:

$ m-a build realtime-lsm

per compilare e creare un pacchetto per il modulo. A questo punto non ci resta che installare il pacchetto realtime-lsm creato.

Questo modulo non è stato accettato (ne lo sarà mai) nel tree ufficiale del kernel per i potenziali problemi di sicurezza legati al suo utilizzo. In particolare per il suo corretto funzionamento devono essere attivate le seguenti voci di configurazione del kernel:

Security options --->
[*] Enable different security model
<M>   Default Linux Capabilities

(l'ultima voce deve necessariamente essere un modulo!)

Nei recenti kernel binari di Etch le precedenti condizioni non sono soddisfatte, per cui il modulo realtime-lsm non funzionerà con tali kernel. Inoltre il modulo realtime-lsm è ormai ufficialmente deprecato in Debian Etch.

In questi casi bisognerà ricompilare il kernel oppure usare l'approccio tramite rlimits.

Conclusioni

Con un kernel così ottimizzato si raggiungono prestazioni realtime davvero spinte. Io ad esempio, con una modestissima SB Audigy 1 posso fare partire jack a 32 frame x 2 periodi @ 48000Hz (latenza 1.3 ms!) in modalità solo playback. Qualche xrun avviene ancora a latenze così basse se si eseguono altre operazioni sulla macchina. Per avere la massima affidabilità in full-duplex utilizzo usualmente jack a 128x2 @ 48000Hz.

In bocca al lupo e...

Happy Debian!

Links