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

Questa è una breve guida su come patchare un kernel 2.6 con la patch realtime-preemption di Ingo Molnar per ottenere un kernel a bassa latenza.  

Il kernel 2.6 ha raggiunto ormai delle prestazioni molto buone per quanto riguarda la latenza. Normalmente non è necessario usare nessuna patch aggiuntiva. Se però si vogliono raggiungere prestazioni estreme (come lavorare in full-duplex su diverse tracce a latenze inferiori a ~ 5 ms) è necessario usare la patch realtime-preemption.

{{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 si usare il [http://demudi.agnula.org/packages/demudi/pool/main/demudi/ kernel multimediale di DeMuDi]. Se volete, invece, un setup per l'audio professionale pronto per l'uso, installate l'ottima [http://demudi.agnula.org/ distribuzione DeMuDi] (è una [http://wiki.debian.net/index.cgi?CustomDebian CDD]).}}

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 [ftp://ftp.it.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.14-rc3.tar.bz2 kernel 2.6.13.2] e la [[Debian Kernel Howto|debian-way]] di compilare il kernel.

Attualmente le patch realtime-preemption si applicano (ufficialmente) ai soli kernel rc (Release Candidate). Quindi si dovrà scaricare e compilare un kernel rc. Nel momento un cui scrivo l'ultimo rc è il 2.6.14-rc3. Se si è precedentemente compilato un kernel stabile basta fare un make oldconfig per configurare 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 non stabile rc. Per questo ho consigliato di testare prima il kernel stabile per verificare l'assenza di problemi.

L'archivio delle patch realtime-premption si trova [http://people.redhat.com/mingo/realtime-preempt/ qui]. La patch realtime-preemption da me usata e la rt2. La patch è un semplice file di testo. Il suo nome è del tipo <tt>patch-''<kernel version>''-''<patch version>''</tt>. Bisogna applicare la patch all'esatta versione del kernel indicata dal nome. Nel mio caso ho usato la [http://people.redhat.com/mingo/realtime-preempt/older/patch-2.6.14-rc2-rt2 versione rt2 applicata al kernel 2.6.14-rc3]. Dopo questa versione sono uscite molto rapidamente una serie di aggiornamenti (attualmente fino a rt8) ma mi è stato consigliato sulla lista [http://www.djcj.org/LAU/guide/index.php LAU] di continuare ad usare l'rt2 (almeno per alcuni giorni fino a quando la situazione non si stabilizza nuovamente). YMMV.

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

per il resto ho lasciato quasi tutte le altre voci al valore di default.

Per usare il server audio jack in realtime da utente normale è inoltre necessario compilare il modulo realtime-lsm. Su debian è semplicissimo, basta installare il pacchetto realtime-lsm-source e usare <tt>[[Pagina di manuale di module-assistant|module-assistant]]</tt> per compilare e pacchettizzare il modulo. Facciamo puntare il link simbolico <tt>/usr/src/linux</tt> alla directory dei sorgenti del kernel patchato ed eseguiamo:

A questo punto non ci resta che installare il pacchetto realtime-lsm creato.

L'uso di questo modulo non richiede alcuna patch al kernel ed è usabilissimo anche con un normale kernel vanilla.  

Questo modulo non è mai stato accettato nel tree ufficilae del kernel per i potenziali problemi di sicurezza legati al fatto di dare i privileggi realtime ai processi dei singoli utenti. E' già presente nel kernel un nuovo meccanismo più sicuro per concedere i privileggi di realtime chiamato rlimits che sostituirà il modulo realtime-lsm. Tuttavia si dovrà aspettare che gli rlimits vengano inclusi nelle distribuzioni dato che è richiesto l'impiego di libc che li supporti. Attualmente, un metodo per usare gli rlimits senza cambaire libc, è quello di patchare PAM. Personalmente non ho ancora provato questa alternativa.

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.