Old:Low-latency 2.6 kernel per applicazioni audio realtime

Da Guide@Debianizzati.Org.
Versione del 5 ott 2005 alle 13:36 di TheNoise (discussione | contributi) (aggiunti link)
Vai alla navigazione Vai alla ricerca

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.

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.

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

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.

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 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).


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.

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

L'archivio delle patch realtime-premption si trova qui. La patch realtime-preemption da me usata e la rt2. 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. Nel mio caso ho usato la 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 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 /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 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 module-assistant per compilare e pacchettizzare il modulo. Facciamo puntare il link simbolico /usr/src/linux 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!

Links



Autore: ~ The Noise