[Download] ubuntu kernel RT

Allora, ormai siamo vicini! stanotte ho finalmente finito di configurare il kernel. Il fatto che l'altro giorno abbiano dichiarato stabile una nuova versione ha ritardato un attimo questo momento. Siamo alla versione 3.12.13. Il mio PC è appena entrato nella quinta mezz'ora di compilazione, nessun errore al momento.

Fasi mancanti:
-finire compilazione;
-compilare l'install;
-compilare i moduli;
-scrivere file readme e install;
-installarlo e, la parte più difficile e ricca di suspense: avviare usando quel kernel!

Quando starò utilizzando il nuovo kernel lo caricherò qui e inizierò a testarlo: latenza, stabilità,....

ma prima....ora vado a fare colazione!

Link in fondo

RT Kernel - perchè?

L'obiettivo più importante nei processi audio è ottenere una bassa latenza. La latenza è il ritardo tra il momento in cui viene generato un segnale quello in cui viene processato dal sistema. I kernel standard hanno lo svantaggio di essere più lenti (~11ms) che in Windows o in Mac. Più è veloce un sistema - e quindi minore sarà la latenza, più cose possono accadere contemporaneamente nel sistema stesso. ingo Molnar, uno sviluppatore RedHat, e alcuni altri, hanno iniziato un progetto per ridurre la latenza in Linux: Preemption Realtime. Usando hardware audio eccellenti il demone jackd può raggiungere latenze < 1ms, simile al MacOs X, coreaudio.

Note

Questo è un kernel sperimentale.
La patch -rt è sotto sviluppo e subisce continuamente pesanti modifiche. Quindi se sei in un giorno sfortunato, ti troverai con un kernel instabile/inusabile.
Un esempio di kernel stabile è linux-3.12.13 (stabile alla stesura, controlla kernel.org e la pagina web di Ingo per le ultime versioni).

Sulla patch RT-Preempt

Il kernel linux standard soddisfa solamente i requisiti del real-time soft: provvede a basilari operazioni POSIX per il tempo di occupazione dello spazio ma non garantisce termini in hard time. Con la patch di Ingo Molnar sul Preemption realtime (alla quali ci riferiamo con RT-Preempt) e il lavoro sul generic clock event di Thomas Gleixner con il supporto ad alta risoluzione, il kernel è ora in grado di lavorare in hard mode

La patch RT-Preempt ha suscito grande interesse nell'industria. E' ben scritta e i suoi ovvi vantaggi la rendono un'opzione interessante per le applicazioni solide e pesanti, è quindi usata sia nell'audio professionale che nei controlli industriali.

Più la patch diventa usata e sue parti significanti iniziano a far parte del kernel Linux, aumenta il bisogno di maggiori documentazioni.
Questo file da una panoramica sul RT-Preempt e il suo utilizzo.

La patch RT-Preempt converte Linux in un kernel fully preemptible. La magia è creata grazie a:

* Rendere il resto del kernel attraverso la reimplementazione con rtmutexes:
* Le sezioni critiche protette sono ora preemptible. La creazione di sessioni non-preemptible è ancora possibile.
* Vengono implementate le priorità per i mutexe del kernel, degli spinlock e rw_semaphore.
* Le interruzioni degli handler sono convertiti in preemptible: RT-Preempt tratta le piccole interruzioni di handler del kernel, che è rappresentata da una task_struct, come un normale processo. Tuttavia è ancora possibile registrare IRQ.
* E' stato convertito il vecchio timer API Linux in infrastrutture separate per kernel a maggiore risoluzione temporale al più di uno per timeout, arrivando a timer POSIX ad alta risoluzione.

Installazione:

Leggere il file "install"

Download:

Documentation

3.12.13-32bit

3.12.13-64bit

3.12.14-32bit

3.12.14-64bit

3.14.17-32bit

3.14.17-64bit

3.18.13-rt7as91

EDIT: cartella pubblica a cui accedere ai file, documentazione compresa:
https://mega.co.nz/#F!hwkAgA6R!51HWcAy8KLhctpeEmXANRg

Commentate!

Primi dati:

Stabile:

Impostazioni	128	192000	3	2ms	28%
Latenza	552	frame		2.8	ms
Latenza extra	40	frame
Consiglio	20	frame

Impostazioni	256	96000	3	8ms	11%
Latenza	1061	frame		11.0	ms
Latenza extra	37	frame
Consiglio	18	frame

Corretti danno entrambi una latenza pari a 0 ms (in registrazione verificato con Ardour3)

Instabile:

Impostazioni	64	96000	3	2ms	18%
Latenza	485	frame		5.0	ms
Latenza extra	229	frame
Consiglio	114	frame

Impostazioni	128	96000	3	4ms	13.7%
Latenza	550	frame		5.7	ms
Latenza extra	37	frame
Consiglio	18	frame

I risultati instabili presentano anche una latenza reale che oltrepassa il doppio di quella teorica

Ottimo, grazie per l'ottimo lavoro e per i risultati di questi primi test.
Però almeno io personalmente non ho capito benissimo i test, potresti spiegare meglio come li stai effettuando e il significato dei risultati?

P.S: sposto in bacheca così è più visibile   

Per prima cosa ora sto compilando la versione a 64b.
A riguardo dei test sto creando una guida avanzata per jackd dove spiegherò anche questa fase

Aggiunta la versione a 64 bit (3.12.14)
Aggiunta 3.12.14 a 32bit. Non è detto sia migliore della .13

OK scaricata la versione a 64 bit!!

Ora vediamo se riesco a mandare a pallino il pc durante l'installazione ...   

Rael ha scritto:OK scaricata la versione a 64 bit!!

Ora vediamo se riesco a mandare a pallino il pc durante l'installazione ...   

... convinto che ubuntu studio che avevo installato fosse a 64 e invece è a 32 ... per cui mi scarico l'ultima versione a 32 bit e vediamo che succede.

Scaricata e installata la versione a 32 bit.

La prima percezione è che il tuo RT si comporti meglio rispetto al lowlatency, con quasi 40 tracce in Ardour con pochi plugin, sono sceso di un pelo di latenza con queste impostazioni.

con l'altro kernel potevo scendere al massimo a 256 frames con 2 di buffer. (latenza 11,8 contro 8,71)

... meno di così non credo sia possibile senza avere xruns in dose massiccia.

prova ad aumentare la frequenza di campionamento a 48, se non è stabile porta i frame a 256 e la frequenza a 98. A volte cambiando combinazione di impostazioni si più avere la stessa latenza ma con molta stabilità. Secondo me a 8 ci arrivi tranquillamente.
Io con la HDA arrivo a 2, però è integrata e non USB e uso il 3.12.13-rt21 e non il 3.12.14-rt23, che devo ancora provare

Ho provato la .14, non mi soddisfa affatto... la .13 era molto più stabile

Rael ha scritto:Scaricata e installata la versione a 32 bit.

La prima percezione è che il tuo RT si comporti meglio rispetto al lowlatency, con quasi 40 tracce in Ardour con pochi plugin, sono sceso di un pelo di latenza con queste impostazioni.

con l'altro kernel potevo scendere al massimo a 256 frames con 2 di buffer. (latenza 11,8 contro 8,71)

... meno di così non credo sia possibile senza avere xruns in dose massiccia.

non mi soddisfa affatto...dovresti riuscire ad arrivare a 2ms, trovare la stabilità a 4ms...
Rendimi felice, prova nuove impostazioni: se non ci riesci e hai il sistema impostato ok, allora è il kernel che non rende...

.. poi provo a installare la .13 e vediamo come butta   


  

Io con la 13 ho avuto questi risultati:



La coppia di xRun sono stati all'avvio di jack_iodelay.

Ora ho appreso come farti compilare un kernel in 20 minuti con solo 2 righe di comando: ti mando io i file del kernel e di configurazione, copi i file di configurazione e ti faccio compilare il pacchetto a 64b, sentiamoci via PM per procedere.

Come ti ho detto una edirol DEVE riuscire a lavorare a 2ms!!!

Ciao AS91,

ti volevo avvisare che dei link che hai passato, da me il download funziona solo sul sito MEGA .. sull'altro mi scarica i file corrotti.

  

  

Ciao. Devo onestamente dire che...  Caro AS91, ti fumano!!!!!!!!!   

Dunque. Ho scaricato il kernel e l'ho installato seguendo le istruzioni. Semplicissimo e rapidissimo. Quindi ho provato a reimpostare Cadence.
Premetto che come distro io uso l'ultima KX Studio 64 bit installata da Iso scaricata dal sito. Fino ad oggi usavo un Buffer size di 256 con latenza di 5.8. Onestamente ero molto soddisfatto. Rarissimi xrun solo quando "pestavo" parecchio e dopo molto tempo (parlo di ore).

Ora con il tuo kernel sono sceso a Buffer size di 128 con latenza di 2.9 (come si fa a caricare le immagini???) E il sistema sembra funzionare a meraviglia anche così. Comunque ci sono due piccoli nei:

1. Usando Firefox, pare che l'audio (di YouTube per esempio) tenda a rovinarsi. Si sente come se stessero registrando in esterna con il vento sui microfoni (????)

2. Come puoi vedere nell'immagine (no, non puoi vederla in quanto non riesco a caricare la foto dello schermo) Cadence rileva che il Kernel non é ottimale (triangolino giallo con punto esclamativo)

Comunque sia sembra veramente andare una bomba. Immagino che smanettandoci posso ancora abbassare la latenza ma aspetto a fare altri esperimenti in quanto domani devo registrare....

Saluti e super, super complimentoni per il gran bel lavoro....     

Sei tramite ethernet vero? è solo per curiosità perchè dovrei avere disattivato tutti i driver wifi e se me n'è sfuggito uno vorrei saperlo

Quando l'audio esce così è semplicemente perchè la scheda audio non riesce a reggere il carico. Se l'hai fatto con la M-audio dovresti provare a portare la latenza a 2ms in quanto le USB lavorano meglio con latenze multiple di 1ms. Se l'hai fatto con l'integrata non so che dirti: io con la HDA non ho questo problema

Inoltre ricompilerò il 3.12.13 a 64bit in quanto sembra migliore del .14

Il triangolino non è magari dovuto ad una non perfetta impostazione di sistema?Il kernel è con rt-hard preemption, 1000hz, con high-resolution kernel, driver e debug e ACPI disattivati

Questo computer é collegato alla rete via cavo (nessun wifi).

Non capisco un paio di cose:

1. In merito al "triangolino giallo" del kernel, non so quali parametri andare a vedere. Con il kernel precedente di default di KX Studio (se non erro PREEMPT) , non veniva segnalato nulla... Cosa dovrei guardare? Ma ripeto, a prescindere dal famoso triangolino, il sistema sembra andare molto bene!

2. Per quanto riguarda il deterioramento dell'audio, ciò avviene, mi pare di capire, solo con le applicazione che NON usano jack. Il problema sarebbe relativo, potrei abbassare la latenza solo quando devo fare musica e alzarla quando devo afre altro....

Comunque sia, gran bel lavoro!!!

EDIT: Ho provato in vari modi a portare la latenza a 2 ms ma non ci riesco... Ho provato a cambiare il "buffer size" e il "periods buffer" ma senza esito... (in particolare, anche se mi sembra strano) cambiando i "periods buffer" la latenza non cambia...
Ho provato a cambiare la frequenza, portandoloa a 48000, ma così la latenza scende oltre i 2 ms. Nessun Xrun ma l'audio si deteriora rapidamente e comunque forse non é conveniente lavorare con la musica a 48000..

Qualche suggerimento?

saguan67 ha scritto:Non capisco un paio di cose:

1. In merito al "triangolino giallo" del kernel, non so quali parametri andare a vedere. Con il kernel precedente di default di KX Studio (se non erro PREEMPT) , non veniva segnalato nulla... Cosa dovrei guardare? Ma ripeto, a prescindere dal famoso triangolino, il sistema sembra andare molto bene!

Tutti i kernel lavorano col preempt: il preemption è il momento in cui la CPU interrompe un processo per controllare la presenza o no di processi in attesa a maggiore priorità. Ci sono 5 tipi diversi di kernel:

Codice:

1. No Forced Preemption (Server) (PREEMPT_NONE)
  2. Voluntary Kernel Preemption (Desktop) (PREEMPT_VOLUNTARY)
  3. Preemptible Kernel (Low-Latency Desktop) (PREEMPT__LL) (NEW)
  4. Preemptible Kernel (Basic RT) (PREEMPT_RTB) (NEW)
  5. Fully Preemptible Kernel (RT) (PREEMPT_RT_FULL) (NEW)

Quello che ho compilato io è un hard-rt, ovvero il 5. Inoltre, come ho messo nel file "readme" all'interno dell'archivio, e all'inizio di questo post:

Il kernel linux standard soddisfa solamente i requisiti del real-time soft: provvede a basilari operazioni POSIX per il tempo di occupazione dello spazio ma non garantisce termini in hard time. Con la patch di Ingo Molnar sul Preemption realtime (alla quali ci riferiamo con RT-Preempt) e il lavoro sul generic clock event di Thomas Gleixner con il supporto ad alta risoluzione, il kernel è ora in grado di lavorare in hard mode

2. Per quanto riguarda il deterioramento dell'audio, ciò avviene, mi pare di capire, solo con le applicazione che NON usano jack. Il problema sarebbe relativo, potrei abbassare la latenza solo quando devo fare musica e alzarla quando devo afre altro....

EDIT: Ho provato in vari modi a portare la latenza a 2 ms ma non ci riesco... Ho provato a cambiare il "buffer size" e il "periods buffer" ma senza esito... (in particolare, anche se mi sembra strano) cambiando i "periods buffer" la latenza non cambia...
Ho provato a cambiare la frequenza, portandoloa a 48000, ma così la latenza scende oltre i 2 ms. Nessun Xrun ma l'audio si deteriora rapidamente e comunque forse non é conveniente lavorare con la musica a 48000..

Qualche suggerimento?

A riguardo il problema della frequenza di campionamento ti quoto un mio messaggio:

as91 ha scritto:Modo giusto? Io lavoro con 96 o 192 Razz
Per registrare devi avere una frequenza di campionamento superiore perchè nell'elaborazione perdi qualità. Tra 192 e 96 non cambia niente a livello di qualità, le differenze sono su latenza e carico DSP.
Inoltre molti consigliano di usare multipli di 44.1 perchè, secondo loro, non perdi qualità nella conversione in formato wav e mp3. Parere personale: leggenda metropolita: purtroppo non esistono ancora dei convertitori analogici (software) in grado di effettuare queste conversioni in modo soddisfacente. La riprova è che in italia esistono 2 centri che effettuano solo questo tipo di lavoro (a livello digitale), tutti gli studi mediocri mandano i loro lavori a fare mastering li per risolvere i problemi di conversione. Gli studi medio-bassi non lo fanno perchè pensano sia inutile, mentre quelli medio-alti lo fanno in casa secondo la classica via "A/D D/A.

La via più semplice che possiamo usare noi è appunto convertire il suono in analogico e poi ancora in digitale con una seconda macchina che lavori a 44.1kHz se lavori per cd o 48 per dvd.

L'importante è ricordarsi: NON SI PUO' REGISTRARE CON LA STESSA FREQUENZA CON CUI SI VUOLE FARE USCIRE L'AUDIO.
Per un uso di riproduzione questi problemi non sussistono.

Inoltre ti invito a leggere quest'altra mia guida: GUIDA -portare la latenza a 0

Quindi se cerco di installare la versione 3.12.14 a 64 bit solo a me da questo messaggio di errore?

Codice:

Error! Your kernel headers for kernel 3.12.14-as91-rt23 cannot be found.
Please install the linux-headers-3.12.14-as91-rt23 package,
or use the --kernelsourcedir option to tell DKMS where it's located


Ho seguito il text Install passo passo!!

installa prima il file headers e poi il kernel

as91 ha scritto:installa prima il file headers e poi il kernel

Ops... 

Babbo Natale ha scritto:

as91 ha scritto:installa prima il file headers e poi il kernel

Ops... 

niente ops...sei il primo che ha problema col comando combinato

as91 ha scritto:Modo giusto? Io lavoro con 96 o 192  Razz
Per registrare devi avere una frequenza di campionamento superiore perchè nell'elaborazione perdi qualità. Tra 192 e 96 non cambia niente a livello di qualità, le differenze sono su latenza e carico DSP.
Inoltre molti consigliano di usare multipli di 44.1 perchè, secondo loro, non perdi qualità nella conversione in formato wav e mp3. Parere personale: leggenda metropolita: purtroppo non esistono ancora dei convertitori analogici (software) in grado di effettuare queste conversioni in modo soddisfacente.

Cosa intendi per "convertitore analogico software"?

as91 ha scritto:
La riprova è che in italia esistono 2 centri che effettuano solo questo tipo di lavoro (a livello digitale), tutti gli studi mediocri mandano i loro lavori a fare mastering li per risolvere i problemi di conversione. Gli studi medio-bassi non lo fanno perchè pensano sia inutile, mentre quelli medio-alti lo fanno in casa secondo la classica via "A/D D/A.

Uhm... puoi fare degli esempi?

as91 ha scritto:
La via più semplice che possiamo usare noi è appunto convertire il suono in analogico e poi ancora in digitale con una seconda macchina che lavori a 44.1kHz se lavori per cd o 48 per dvd.

Perchè con una "seconda macchina"?

as91 ha scritto:
L'importante è ricordarsi: NON SI PUO' REGISTRARE CON LA STESSA FREQUENZA CON CUI SI VUOLE FARE USCIRE L'AUDIO.
Per un uso di riproduzione questi problemi non sussistono.

Il criterio/regola di Nyqust dice almeno il doppio. Da cui 44.1KHz, anche se sappiamo che neanche Chris Lord Alge non senta niente a 20KHz...

Comunque la questione "campionamento" meriterebbe un thread apposito.

Ciao,
Touch.

touchstyle ha scritto:

as91 ha scritto:Modo giusto? Io lavoro con 96 o 192  Razz
Per registrare devi avere una frequenza di campionamento superiore perchè nell'elaborazione perdi qualità. Tra 192 e 96 non cambia niente a livello di qualità, le differenze sono su latenza e carico DSP.
Inoltre molti consigliano di usare multipli di 44.1 perchè, secondo loro, non perdi qualità nella conversione in formato wav e mp3. Parere personale: leggenda metropolita: purtroppo non esistono ancora dei convertitori analogici (software) in grado di effettuare queste conversioni in modo soddisfacente.

Cosa intendi per "convertitore analogico software"?

Andare nelle opzione e selzionare l'opzione "ricampionamento"

touchstyle ha scritto:

as91 ha scritto:
La riprova è che in italia esistono 2 centri che effettuano solo questo tipo di lavoro (a livello digitale), tutti gli studi mediocri mandano i loro lavori a fare mastering li per risolvere i problemi di conversione. Gli studi medio-bassi non lo fanno perchè pensano sia inutile, mentre quelli medio-alti lo fanno in casa secondo la classica via "A/D D/A.

Uhm... puoi fare degli esempi?

Gli esempi sono che nel primo studio dove ho lavorato non facevano questo mestiere, usciva un materiale di qualità "demo", e nessuno veniva a registrare da noi. Nel secondo studio dove ho lavorato usavamo il metodo descritto sopra, dai corsi (ultimo aggiornamento a gennaio) so che esistono 2 studi specializzati in questo lavoro, fanno solo questo e vivovo solo di questo...

touchstyle ha scritto:

as91 ha scritto:
La via più semplice che possiamo usare noi è appunto convertire il suono in analogico e poi ancora in digitale con una seconda macchina che lavori a 44.1kHz se lavori per cd o 48 per dvd.

Perchè con una "seconda macchina"?

Per non caricare troppo il DSP di un PC casalingo. In realtà coi nuovi processori si può semplicemente creare una seconda istanza jack che lavori a 44.1kHz e registrare collegando fisicamente segnale in ingresso e in uscita. Per rendere questo concetto ad un livello più concreto: immagina un'immagine di 70 dpi, se la ingrandi troppo si vedono i pixel. Quindi la si stampa e si fa la scansione della stampa ad almeno 1800dpi. In digitale non puoi fare un lavoro del genere, anche se magari trovi l'opzione per scalare l'immagine. Prova per credere!  

touchstyle ha scritto:

as91 ha scritto:
L'importante è ricordarsi: NON SI PUO' REGISTRARE CON LA STESSA FREQUENZA CON CUI SI VUOLE FARE USCIRE L'AUDIO.
Per un uso di riproduzione questi problemi non sussistono.

Il criterio/regola di Nyqust dice almeno il doppio. Da cui 44.1KHz, anche se sappiamo che neanche Chris Lord Alge non senta niente a 20KHz...

Conosco bene quel principio, vale per qualsiasi processo di campionamento di segnale, il fatto è, dando un esempio stupido, se registri a -12 db - come dovresti fare per i picchi...nel momento finale durante la normalizzazione perdi molta qualità. Un altro esempio si ha quando usi i preamplificatori e amplificatori digitali: non fanno poi così tanti miracoli come si crede...vale lo stesso esempio dell'immagine di prima, ovviamente in senso lato. Se registri direttamente a 44.1 durante l'elaborazione del segnale perdi definizione e ti trovi con una tracci che in pratica ho una risoluzione (bit di campionamento) inferiore ai 44.1. Registrando a 96kHz non avrai mai questi problemi. 192kHz non apporta nessun vantaggio rispetto ai 96.

touchstyle ha scritto:Comunque la questione "campionamento" meriterebbe un thread apposito.

Ciao,
Touch.

quoto!!