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

Vai alla navigazione Vai alla ricerca
completato
m (abbozzata)
 
(completato)
Riga 1: Riga 1:
{{stub}}
 
== Introduzione ==
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.  
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.  


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


[http://www.emillo.net/audio_midi]
* [http://www.emillo.net/audio_midi emillo.net]


In questo settore le patch e i kernel evolvono rapidamente. Non posso che descrivere il processo che ho usato con il kernel e la patch attuale.  
In questo ambiente le patch e i kernel evolvono rapidamente. Non posso che descrivere il processo che ho usato con il kernel e la patch attuale (che a me hanno dato ottimi risultati), sapendo che le versioni di kernel e patch citate 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 si usare il kernel multimediale di DeMuDi. Se voltete poi un setup per l'audio professionale pronto per l'uso installate l'ottima distribuzione DeMudi (� una CDD).}}
{{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 [kernel multimediale di DeMuDi]. Se voltete poi 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]).}}


== Dal kernel stabile all'RC ==
== 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 [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.
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.
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.


La patch realtime-preemption da me usata e la rt2. L'archivio delle patch realtime-prremption si prova qui
== La patch realtime-preemption ==
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.
 
Per applicare la patch basta copiarla in <tt>/usr/src</tt>, 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:
 
<pre>
Processor type and features  --->
  Preemption Mode (Complete Preemption (Real-Time))
</pre>
 
per il resto ho lasciato quasi tutte le altre voci al valore di default.
 
Non ci resta che compilare il kernel:
 
  $ fakeroot make-kpkg --append-to-version -realtime --revision 0.1 kernel_image
 
ed installare il pacchetto.
 
 
== Il modulo realtime-lsm ==
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:
 
  $ m-a build realtime-lsm
 
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.
 
== Conlusioni ==
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!
 
----
 
Autore: [[Utente:TheNoise|~ The Noise]]
1 760

contributi

Menu di navigazione