LA SOLUZIONE DEFINITIVA (o quasi) del problema della latenza

Stasera ho finalmente finito di leggere il manuale di ardour3. Cosa scopro? questo paragrafo. L'ho tradotto per chi non avesse voglia di leggerlo in inglese. Magari nei prossimi giorni continuo la traduzione in quanto l'ho trovata molto pratica: si vede che è scritta da qualcuno che utilizza il programma.

_________________________________________________________________________________________________________

SINCRONIZZAZIONE

LATENZA E COMPENSAZIONE DELLA LATENZA

La latenza è la risposta del sistema ad uno stimolo dato. Ci sono vari fattori che contribuiscono alla latenza totale del sistema. Per riuscire ad ottenere una perfetta sincronizzare temporale tutte fonti di latenza devono essere tenute di conto ed essere compensate.

Fonti di latenza

Propagazione del suono tramite l'aria

Siccome il suono è un'onda meccanica diffusa in un fluido, viaggia relativamente lenta, a circa 340m/s. Di conseguenza, la tua chitarra acustica, o il tuo piano avranno una latenza di circa 1/2ms, a causa del tempo di propagazione del suono tra lo strumento e il tuo orecchio.

Conversione Digitale/Analogico, Analogico/Digitale

I segnali elettrici viaggiano veramente veloci (molto vicini alla velocità della luce), quindi il loro tempo di propagazione è trascurabile. Al contrario la conversione tra un segnale analogico ed uno digitale richiede un tempo relativamente lungo per essere effettuato, di conseguenza il loro contributo alla latenza totale dovrebbe essere considerato su sistemi non a bassa latenza. Solitamente il ritardo di conversione è sotto a 1 ms.

Elaborazione del segnale digitale

Un computer è solitamente un processore, non un processore di audio digitale. Questo significa che i nostri pacchetti audio devono attraversare vari passaggi lungo il loro percorso da fuori il computer e ritorno, contendendo il processo con altre parti del sistema in lista per le stesse risorse (CPU time, busbandwidth, etc.)

La catena della latenza


Figura: Catena della latenza.
I numeri sono un esempio per un tipico PC. Con hardware professionale ed un sistema ottimizzato il numero totale di giri che causano latenza è solitamente ridotto. Il punto focale è che la latenza è una sommatoria di vari fattori indipendenti.

La latenza dei processi è solitamente divisa tra latenza in entrata (il tempo necessario per digitalizzare l'audio per renderlo utilizzabile dal processore, solitamente un periodo per pacchetto audio), e latenza in uscita (il tempo richiesto [per convertire in analogico l'audio).] In pratica, ci interessa la combinazione dei due. Viene chiamata latenza di andata e ritorno: il tempo necessario per catturare un certo evento audio, processarlo e riprodurlo.

É importante fare notare che la latenza del processo in jackd è una combinazione di impostazioni. Può essere ridotta entro i limiti imposti dall'hardware (dispositivi audio, CPU e velocità del bus) e dei driver audio. Latenza basse incrementano il carico di sistema poiché è necessario processare l'audio in pacchetti più piccoli i quali arrivano con una velocità maggiore. Minore è la latenza, più facilmente il sistema fallirà nel compiere i processi nel tempo che ha a disposizione e i temuti xRun (abbreviazione di buffer overload o under-run) faranno la loro apparizione molto spesso, lasciando la loro simpatica scia di click, pop e crack.

La latenza dell' I/O digitale è solitamente trascurabile per schede integrate o dispositivi PCI, ma per interfaccie USB o FireWire il bus clocking e buffer posso impiegarci qualche millisecondo.

Casi in cui è necessaria una bassa latenza

Una bassa latenza non è sempre necessaria. Ha spesso degli inconvenienti: il più evidente è l'aumento del consumo di potenza in quanto la CPU ha bisogno di processare molti, piccoli pacchetti di dati audio, è costantemente attiva e non può entrare in risparmio energetico (pensa al rumore delle ventole). Siccome ogni applicazione che è parte della catena di segnale deve lavorare per ogni ciclo, i sistemi a bassa latenza satureranno frequentemente i cambi di contesto [La commutazione di contesto o context switch è un particolare stato del sistema operativo durante il quale avviene il cambiamento del processo correntemente in esecuzione su una delle CPU.] tra le applicazioni, ciò fa incorrere in un significante sovraccarico. Ciò porta ad un notevole carico di sistema e una più alta possibilità di xRun.

Per alcune applicazioni la bassa latenza è essenziale:

suonare strumenti virtuali: un grande ritardo tra la pressione di un tasto e la riproduzione del suono manderà fuori tempo la maggior parte dei musicisti (ad eccezione di chi suona gli organi in chiesa che sono abituati a compensare alte latenze).

Il monitoring di software audio: se un cantante si ascolta attraverso due differenti fonti sonore (il suo orecchio interno e le cuffie), anche la più bassa latenza può essere veramente fastidiosa e risultare come un suono metallico e fastidioso.

Effetti live: una bassa latenza è essenziale quando si utilizza il PC come un effetto rack come un compressore o un EQ. Per i riverberi una latenza poco più alta potrebbe essere tollerata, a meno che il suono diretto non viene comunque fatto passare per il PC.

Mixing live: molti ingegneri del suono utilizzano un PC per fare i mix live. Di base si tratta di una combinazione dei precedenti: monitor sul palco, effetti, processori ed EQ per il publico.

In molti altri casi, come la riproduzione, registrare, overdubbing, mixing e mastering, etc, la latenza non è importante in quanto può essere facilmente compensabile.
Per spiegare questa dichiarazione: durante il mising e il mastering non ti importa se ci sono  10 o 100ms tra l'istante che tu premi play e il suono che viene riprodotto dalle casse. Lo stesso è vero quando tu registri con un conteggio iniziale.

Compensazione della latenza

Quando registri è importante che il suono che si sta riproducendo sia allineato internamente col suono che si sta registrando.

Qui è dove il processo di compensazione della latenza ha luogo. Ci sono due modi per compensare la latenza in una DAW, read-ahead [leggi davanti] e write-behind [scrivere dietro]. La DAW inizia a suonare un pochino prima (relativamente alla barra di playhead), di conseguenza quando il suono arriva alle casse un pochino in ritardo, è esattamente allineato con la traccia che si sta registrando. Siccome noi sappiamo che il play-back ha latenza, l'audio in entrata può essere ritardato della stessa quantità per riallineare le cose.

Come si può vedere, il secondo approccio è soggetto a vari problemi di attuazione in materia di timecode e la transport synchronization. Ardour usa il read-ahead per compensare la altenza. Il tempo indicato dall'orologio di Ardour corrisponde al segnale audio che tu senti nelle casse (e non a dove Ardour legge i file dal disco).

Come nota, questa è una delle regioni per la quale molti progetti partono dal timecode »01:00:00:00«. Quando viene compensata la latenza in uscita la DAW deve per forza leggere i dati da prima che la sessione inizi, in questo modo l'audio arriva arriva in tempo all'output quando il timecode è a »01:00:00:00«. Ardour3 gestisce bene il caso di »0:00:00:00« ma non tutti i sistemi/software/hardware che tu intendi utilizzare riescono a fare lo stesso.

Compensazione della latenza e sincronizzazione del clock


Per riuscire ad ottenere una certa accurata sincronizzazione del timecode, la latenza inserita nelle impostazioni audio deve essere conosciuta e compensata.

Per compensare la latenza jackd, e le applicazioni jackd devono sapere esattamente quanto un segnale deve essere read-ahead o ritardato:


Figura: compensazione della latenza di jackd
Nella figura sopra, il client A e il B devono essere in grado di rispondere a queste due domane:
Quanto tempo è passato da quando i dati letti dalla porta Ai o Bi sono arrivati all'ingesso di jackd (capture)?
Quanto tempo è passerà da quando i dati scritti dalla porta Ao o Bo arriveranno all'uscita di jackd (playback)?
Jackd presenta una API che permette alle applicazioni di determinare la risposta a queste domande. Tuttavia jackd non è in grado di sapere la latenza che viene aggiunta dal PC, dal sistema operativo e dalla scheda audio. Questi valori possono essere specificati dai comandi -I e -O di jackd e variare da sistema a sistema ma costanti su ognuno. Su un PC normale l'unica via per conoscere la latenza totale è misurarla.

Calibrare la latenza di jackd

Il guru del Linux DSP Fons Adriaensen ha scritto un programma chiamato “jack_delay” per misurare accuratamente la latenza di andata e ritorno di una catena audio chiusa, con una certa accuratezza. Jackd da solo include una variante di questo programma chiamata “jack-iodelay”.

Jack-iodelay ti permette di misurare la latenza totale del sistema, al netto della latenza conosciuta di jackd e suggerisce per i parametri jackd di audio-backend.

Jack-[io]delay lavora emettendo un certo impulso audio, catturandolo dopo averlo fatto passare attraverso l'intera catena, e misurando la differenza di fase. Può così stimare con grande accuratezza il tempo che viene impiegato.

Puoi chiudere il loop in vari modi:

mettendo una cassa vicino al microfono. Questo viene fatto raramente in quanto la latenza nell'aria è ben conosciuta e non è necessario misurarla.

Connettendo l'output della propria scheda audio con l'input usando un cavo di patch [un semplice jack maschio-maschio]. Questo può essere sia un collegamento analogico sia digitale, dipende dalla natura del'I/O che usi. Un loop digitale non andrà incontro alla latenza dovuta alla conversione AD/DA.
Una volta che hai chiuso il loop tu devi:
1. Lanciare jackd con la configurazione che vuoi testare.
2. Lanciare jack_delay da riga di comando.
3. Effettuare le appropriate connessioni attraverso le porte jack in modo che il loop sia chiuso.
4. Regolare il volume in entrata e in uscita nel mixer.


EDIT: ho dovuto editare varie volte perchè non mi salvava i BBCode....

Ho trovato la guida completa qu => http://apps.linuxaudio.org/wiki/jack_latency_tests

Ora la leggo e finisco di tradurla

Ho saltato le parti già tradotte precedentemente

___________________________________________________________________________________________________________


Demistificare la latenza

Latenza è ormai una di quelle parole d'ordine che sono spesso fraintese dai profani o che sono indiscriminatamente sbandierate in giro come prova incontrovertibile di evidenti vantaggi delle proprie capacità contro quelle di altri. Dopo tutto, è solo un numero che puoi comparare coi tuoi amici.

Una volta ho visto un ragazzo in un forum audio parlare di come lui otteneva minore latenza se lanciava jack da riga di comando, e pensava veramente che la latenza fosse misurata dall'indicatore di carico DSP di qjackCtl, di conseguenza buffer più grandi implicavano minore latenza. Era sicuramente un bravo ragazzo che cercava di aiutare, ma era di per se un pochino confuso.

Quindi, lasciando da parte le parole d'ordine, le montature e le leggende urbane, che cos'è di per se la latenza? La latenza è come tu chiami il tempo di reazione di un sistema a certi stimoli.

Nel mondo dell'acustica la latenza è il tempo che passa tra un'azione che produce suono e la percezione da un ascoltatore.

Un caso veramente chiaro di latenza è il tempo che ci impieghi a sentire il suono di un tuono dopo che hai visto il lampo di una tempesta lontana (anche la visione è soggetta a latenza, siccome la luce non viaggia ad una velocità infinita, ma la latenza visiva è trascurabile rispetto all'uditiva.)

[…]

Alla fine non conta quanto è grande ma come la sai usare.

Più piccola, migliore?

TODO

[...]

Misurare la latenza con jack_delay (Calibrare la latenza di jackd)

[…]

Se vuoi misurare la latenza di una scheda audio economica, o integrata che ha solo line-out e mic-in non puoi semplicemente connettere le due porte con un cavo patch: entrambe le porte possono essere meccanicamente compatibili, ma elettricamente non sono progettate per lavorare assieme, quindi cercare di connetterle direttamente potrebbe danneggiare la tua scheda audio [NDT: io lo faccio da anni e non ho mai avuto problemi]. Se sei curioso puoi costruirti un pad: http://web.archive.org/web/20060410075235/http://www.tkk.fi/Misc/Electronics/circuits/line_to_mic.html [tradurrò il link] con una coppia di resistori per adattare le impedenze.

[...]

Una volta che hai chiuso il loop tu devi:
1. Lanciare jackd con la configurazione che vuoi testare.
2. Lanciare jack_iodelay da riga di comando.
3. Effettuare le appropriate connessioni attraverso le porte jack in modo che il loop sia chiuso.
4. Regolare il volume in entrata e in uscita nel mixer.

Se tutto è andato secondo i piani, jack_delay dovrebbe iniziare a stampare messaggi che indicano la latenza del loop misurata sia in millisecondi che in frame audio (ci sono tanti frame per secondo quanti la frequenza di campionamento).

Codice:

$ jack_delay
capture latency  = 1024
playback_latency = 2048
Signal below threshold...
Signal below threshold...
Signal below threshold...
  3104.419 frames     64.675 ms ?? Inv
  3104.416 frames     64.675 ms ?? Inv
  3104.415 frames     64.675 ms ?? Inv
  3104.417 frames     64.675 ms ?? Inv

[Il mio jack_delay da un output del tipo:

Codice:

3106.619 frames     64.721 ms total roundtrip latency
   extra loopback latency: 34 frames
   use 17 for the backend arguments -I and -O

segnalando la latenza totale in frame, latenza totale in secondi, la latenza non generata da jakcd e consiglia che impostazioni utilizzare in frame, che corrisponde alla metà della latenza non dovuta a jackd]

Sistemare la latenza

TODO

[...]

Enigma della latenza di jack

Jack riporta la altenza delle porte (esegui jack-lsp -l). Tuttavia il valore riportato è determinato dalla configurazione (es.: -p1024 -n3) e non rappresenta la latenza reale. La latenza totale dipende da molti altri fattori (PCI, 1394 [penso si riferisca all'IEEE], USB, chipset), gli strati intermedi (DMA IRQ) e sicuramente la stessa interferenza audio.

Misurare la latenza

[…]

Sebbene il circuito completo del segnale audio che crea latenza sia complesso, noi ci aspettiamo che la latenza supplementare sia (più o meno) un valore costante.

Il diagramma sottostante mostra tutte la misurazioni di latenza per una Edirol UA-25 USB e una HDA-Intel PCI.
Nota: non tutte le configurazioni sono possibili: per esmpio la Edirol non è in grado di lavorare al di sotto dei 64 frame/secondi, mentre la HDA deve rimanere sotto ai 1024.

I test sono stati effettuati su Debian/squeeze usando jackdmp 1,9,6.




Interpretazione e analisi

Guardiamo da più vicino: il diagramma mostra sotto la differenza tra la latenza nominale (presa da jackd) e la latenza misurata per entrambe le schede. [secondo me hanno confuso i diagrammi.....]






Il piccolo residuo di latenza addizionale non dovuta a jack per l'HDA è costante (~44 frame - .9ms). Le anomali e≤ 32 frame/periodo per l'HDA possono essere spiegate dal bus overhead e dalla scheda audio. Tuttavia i risultati per la USB sono inaspettati.

Ci sono due cose che gli autori di questo articolo non capiscono (e potrebbe essere un bug di jackd):
1. Sembra che per la scheda USB jack aggiunga segretamente della latenza, ma al più di 1024 frame. Questo fenomeno non è presente per la scheda HDA
2. La latenza riportata da jackd è incoerente.
Guardando da più vicino queste due questioni:

(1) tracciare la latenza non dipendente da jackd per l'USB dopo aver sottratto un ulteriore valore di periodo – nella maggior parte dei casi 1024 frame produce una distribuzione ragionevole:


(2) comprendere l'incoerenza della latenza riportata da jackd necessita un indagine nel codice di jackd stesso. Provare a riprodurre questo comportamento con jack-1 potrebbe anche far luce sulla questione. Potrebbe anche semplicemente essere una interpretazione sbagliata dei valori riportati. Le informazioni raccolte qui sono un primo passo: per chiarire i problemi agli autori.
Usando n2 per entrambe le schede porta jackd a riportare durante l'avvio:

Codice:

ALSA: use 2 periods for capture
ALSA: use 2 periods for playback

e n3 riporta:

Codice:

ALSA: use 3 periods for capture
ALSA: use 3 periods for playback

mentre jack_lsp -l (o jack_port_get_latency) dice diversamente. Per -n3 -p1024:

Codice:

system:capture_1
      port latency = 1024 frames
 system:playback_1
      port latency = 2048 frames

“3 periodi per registrare, 3 periodi per riprodurre” dovrebbe portare alla stessa latenza per entrambi input e output. Di conseguenza uno dei due valori riportati è incorretto.

La misurazione della latenza di Alsa non può dire qual'è.

Dati greggi

Codice:

#UA-25, Linux 2.6.33.7-rt29 i386, jackdmp 1.9.6
#JACK-cfg, measured lat [frames], measured lat [ms], nominal latency for record [frames], nominal latency for playback [frames], periods per cycle
#JACK-cfg: frames per period * periods per cycle / sample-rate / S: --sync
#
# values of '-1' mean that this mode is not supported
#
4096*3/48kHz   ,17688.747, 368.516,  4096,12288, 3
4096*3/48kHz/S ,13592.747, 283.182,  4096, 8192, 3
4096*2/48kHz   ,13592.747, 283.182,  4096, 8192, 2
4096*2/48kHz/S , 9496.747, 197.849,  4096, 4096, 2
2048*3/48kHz   , 9401.749, 195.870,  2048, 6144, 3
2048*3/48kHz/S , 7401.747, 154.203,  2048, 4096, 3
2048*2/48kHz   , 7401.747, 154.203,  2048, 4096, 2
2048*2/48kHz/S , 5353.747, 111.536,  2048, 2048, 2
1024*3/48kHz   , 5257.748, 109.536,  1024, 3072, 3
1024*3/48kHz/S , 4281.748,  89.203,  1024, 2048, 3
1024*2/48kHz   , 4281.749,  89.203,  1024, 2048, 2
1024*2/48kHz/S , 3257.746,  67.870,  1024, 1024, 2
 512*3/48kHz   , 2728.747,  56.849,   512, 1536, 3
 512*3/48kHz/S , 2216.747,  46.182,   512, 1024, 3
 512*2/48kHz   , 2216.748,  46.182,   512, 1024, 2
 512*2/48kHz/S , 1704.748,  35.516,   512,  512, 2
 256*3/48kHz   , 1464.747,  30.516,   256,  768, 3
 256*3/48kHz/S , 1208.748,  25.182,   256,  512, 3
 256*2/48kHz   , 1208.747,  25.182,   256,  512, 2
 256*2/48kHz/S ,  952.747,  19.849,   256,  256, 2
 128*3/48kHz   ,  808.748,  16.849,   128,  384, 3
 128*3/48kHz/S ,  680.747,  14.182,   128,  256, 3
 128*2/48kHz   ,  681.748,  14.203,   128,  256, 2
 128*2/48kHz/S ,  553.748,  11.536,   128,  128, 2
  64*3/48kHz   ,  505.748,  10.536,    64,  192, 3
  64*3/48kHz/S ,  441.747,   9.203,    64,  128, 3
  64*2/48kHz   ,  441.748,   9.203,    64,  128, 2
  64*2/48kHz/S ,  377.747,   7.870,    64,   64, 2
  32*3/48kHz   ,    -1   ,   -1   ,    32,   96, 3
  32*3/48kHz/S ,    -1   ,   -1   ,    32,   64, 3
  32*2/48kHz   ,    -1   ,   -1   ,    32,   64, 2
  32*2/48kHz/S ,    -1   ,   -1   ,    32,   32, 2
  16*3/48kHz   ,    -1   ,   -1   ,    16,   48, 3
  16*3/48kHz/S ,    -1   ,   -1   ,    16,   32, 3
  16*2/48kHz   ,    -1   ,   -1   ,    16,   32, 2
  16*2/48kHz/S ,    -1   ,   -1   ,    16,   16, 2  

Codice:

#HDA 1458:a002, Linux 2.6.33.7-rt29 amd64, jackdmp 1.9.6
#JACK-cfg, measured lat [frames], measured lat [ms], nominal latency for record [frames], nominal latency for playback [frames], periods per cycle
#JACK-cfg: frames per period * periods per cycle / sample-rate / S: --sync
#
# values of '-1' mean that this mode is not supported
#
#2048*2 -> ALSA: cannot configure playback channel
#1024*3 -> ALSA: cannot configure playback channel
#
4096*3/48kHz   ,   -1   ,  -1   ,  4096,12288, 3
4096*3/48kHz/S ,   -1   ,  -1   ,  4096, 8192, 3
4096*2/48kHz   ,   -1   ,  -1   ,  4096, 8192, 2
4096*2/48kHz/S ,   -1   ,  -1   ,  4096, 4096, 2
2048*3/48kHz   ,   -1   ,  -1   ,  2048, 6144, 3
2048*3/48kHz/S ,   -1   ,  -1   ,  2048, 4096, 3
2048*2/48kHz   ,   -1   ,  -1   ,  2048, 4096, 2
2048*2/48kHz/S ,   -1   ,  -1   ,  2048, 2048, 2
1024*3/48kHz   ,   -1   ,  -1   ,  1024, 3072, 3
1024*3/48kHz/S ,   -1   ,  -1   ,  1024, 2048, 3
1024*2/48kHz   ,3115.933, 64.915,  1024, 2048, 2
1024*2/48kHz/S ,2091.965, 43.583,  1024, 1024, 2
 512*3/48kHz   ,2091.739, 43.578,   512, 1536, 3
 512*3/48kHz/S ,1579.792, 32.912,   512, 1024, 3
 512*2/48kHz   ,1579.729, 32.911,   512, 1024, 2
 512*2/48kHz/S ,1067.693, 22.244,   512,  512, 2
 256*3/48kHz   ,1067.631, 22.242,   256,  768, 3
 256*3/48kHz/S , 811.610, 16.909,   256,  512, 3
 256*2/48kHz   , 811.640, 16.909,   256,  512, 2
 256*2/48kHz/S , 555.678, 11.577,   256,  256, 2
 128*3/48kHz   , 556.381, 11.591,   128,  384, 3
 128*3/48kHz/S , 428.372,  8.924,   128,  256, 3
 128*2/48kHz   , 426.775,  8.891,   128,  256, 2
 128*2/48kHz/S , 298.726,  6.223,   128,  128, 2
  64*3/48kHz   , 299.280,  6.235,    64,  192, 3
  64*3/48kHz/S , 235.297,  4.902,    64,  128, 3
  64*2/48kHz   , 235.833,  4.913,    64,  128, 2
  64*2/48kHz/S , 170.797,  3.558,    64,   64, 2
  32*3/48kHz   , 267.078,  5.564,    32,   96, 3
  32*3/48kHz/S , 235.163,  4.899,    32,   64, 3
  32*2/48kHz   , 202.842,  4.226,    32,   64, 2
  32*2/48kHz/S , 170.943,  3.561,    32,   32, 2
  16*3/48kHz   , 155.007,  3.229,    16,   48, 3
  16*3/48kHz/S , 138.963,  2.895,    16,   32, 3
  16*2/48kHz   , 124.041,  2.584,    16,   32, 2
  16*2/48kHz/S , 108.056,  2.251,    16,   16, 2

Ringraziamenti

Molti grazie a Paul Davis e Stephane Letz per jackd e Fons Adriaensen per jack_delay.
Questo articolo è stato scritto da Robin Gareus e Luis Garrido e può essere diffuso nei termini del GFDL.

Fonte: http://apps.linuxaudio.org/wiki/jack_latency_tests

Grandissimo as91!!

Con calma me la leggo tutta, quasta traduzione meriterebbe di finire su linuxaudio.it.

Ti andrebbe di caricarla?

Ciao e complimenti

Mitico !
a breve arriva un'altra traduzione

l'originale viene da linuxaudio.org. la sistemo bene e poi la carico. Inoltre se qualcuno mi aiutasse potremmo tradurre il manuale di ardour che questa volta, per il 3, è veramente ricco di informazioni.

Inoltre sto cercando di mettermi in contatto con i due autori dell'articolo per cercare di collaborare con loro nella ricerca e comunque rimanere aggiornato sui vari sviluppi.

EDIT: quando lo leggete segnalatemi vari errori che trovate: alle 5 di mattina non avevo più neanche la voglia di fare il controllo ortografico.........

Ottimo, grazie per la traduzione, ti invito anch'io a metterla su linuxaudio.
Io tempo fa (ai tempi di Ardour2) provai a contattare Paul Davis per proporgli una collaborazione per la traduzione in italiano del manuale, ma mi rispose dicendo che il manuale all'epoca era parecchio incompleto e non valeva la pena farlo. Ho provato a ricontattarlo all'indomani dell'uscita di Ardour3 ma non mi rispose: probabilmente la cosa migliore è farla in ogni caso   

Se ti va apri un post relativo alla traduzione nella sezione di Ardour per fare un po' di reclutamento di personale!

post aperto, comunque io ho scritto a Robin Gareus e Luis Garrido

el_Felix ha scritto:Io tempo fa (ai tempi di Ardour2) provai a contattare Paul Davis per proporgli una collaborazione per la traduzione in italiano del manuale, ma mi rispose dicendo che il manuale all'epoca era parecchio incompleto e non valeva la pena farlo. Ho provato a ricontattarlo all'indomani dell'uscita di Ardour3 ma non mi rispose: probabilmente la cosa migliore è farla in ogni caso

Mi ha risposto Luis con una lunga mail, tra cui si legge:

I was not aware of any translations, but that's very cool! The Italian
linux community rocks.

e in cui mi ha informato di alcuni tools già compresi in arodour3, che mancavano nella versione 2 (di cui un po' è rammaricato perchè erano progetti che lui stava portando avanti). Mi ha indicato un paio di articoli che ora leggerò e al più presto condividerò quelle informazioni con tutti voi!