Le basi di una workstation audio open source by mario marino

Le basi di una workstation audio open source di Mario Marino [http://marinomario.wordpress.com] Febbraio 2008

Introduzione Il presente documento è un estratto dal seminario tenuto presso l'Università degli Studi di Padova Venerdi 8 Febbraio 2008, in occasione della rassegna di musica elettronica "Nufest" edizione 2008. Parleremo qui degli elementi costitutivi principali di una stazione multimediale interamente basata su software libero e su sistema operativo GNU/Linux. Tale sistema operativo, pur non essendo nato per assolvere a funzionalità di questo tipo, ha vissuto negli ultimi tempi un notevole sforzo di sviluppo che gli ha consentito un recupero, almeno parziale, del gap che ancora esiste rispetto alle funzionalità multimediali dei sistemi proprietari. Gli argomenti che tratteremo presuppongono delle conoscenze di base degli aspetti tecnici dell’audio digitale e del sistema operativo GNU/Linux.

Le basi di una workstation audio open source di Mario Marino [http://marinomario.wordpress.com] Febbraio 2008

1. Panoramica sulle principali distribuzioni Linux adatte alla produzione musicale ubuntustudio (http://ubuntustudio.org): solo installabile, il punto di riferimento per praticità e riconoscimento periferiche. Molto completa anche la dotazione sotware per l'audio (manca SuperCollider) ● 64studio (http://www.64studio.com): esiste sia la versione installabile che quella Live. Molto solida in quanto si tratta di una pura Debian adattata all'audio. L'unica nativamente predisposta per i processori 64bit ma un po' più ostica da usare della precedente e meno ricca di software preinstallato (pecca che si fa sentire soprattutto nella versione Live) ● pure:dyne (https://devel.goto10.org/puredyne): bellissima distro LIVE derivata dalla storica dynebolic, completissima in quanto a dotazione software (c'è anche Super Collider!), anche se purtroppo abbiamo riscontrato qualche pecca nel riconoscimento delle periferiche audio. ● jacklab (http://www.jacklab.org): basata su SUSE si trova sia Live che installabile. Da usare solo su macchine recenti in quanto molto pesante da caricare, ma molto solida, completa e ben fatta a livello estetico. Da provare. ●

2. Il kernel REAL-TIME PREEMPT: la base di un sistema dedicato all'audio La costruzione della nostra DAW (digital audio workstation) parte da nucleo di base: il kernel. Il kernel di Linux è l'elemento centrale del SO, quello strato di software che si trova tra le periferiche hardware (la scheda audio) e le applicazioni (un sequencer come Rosegarden per esempio) e consente alle prime di 'dialogare' con le seconde. La principale differenza tecnica tra Windows e Linux è che quest'ultimo è costruito in modo modulare e 'aperto', quindi interamente configurabile. La configurazione del kernel diviene quindi il momento centrale per qualsisi tipo di progetto che coinvolge il nostro SO. Mentre la fama del Pinguino in ambito ad es. Server è ben documentata e sono sicuramente numericamente di più nel mondo i Server Linux di quelli targati Microsoft (basti pensare ad Apache), in ambito audio/multimedia il divario a favore dei sistemi proprietari è ancora netto ma si sta restringendo e, come vedremo, impostare una workstation per fare musica affidata anche solo parzialmente al SO open source è un'ottima idea anche per realizzazioni professionali.

Le basi di una workstation audio open source di Mario Marino [http://marinomario.wordpress.com] Febbraio 2008 Ciò che connota un sistema configurato per l'audio da uno non adatto è dunque il kernel. Esso dovrà essere configurato con tutti i settaggi e i moduli necessari per l'audio (ALSA in particolare). Ma prima ancora della configurazione dovrà essere effettuata un operazione detta 'patching'. Esiste una patch infatti (una 'pezza', ovvero un 'aggiustamento' del codice principale) creata da Ingo Molnar da aggiungere al sorgente del kernel per adeguare il funzionamento del sistema a compiti RealTime. In sostanza viene così assegnata la priorità (preempt) agli interrupt che vengono dalle periferiche (in particolare quella audio) in modo che scavalchino gli altri processi contemporanei (Thread). Un kernel di questo tipo viene anche detto low-latency, per evidenziare il problema della latenza, centrale nell'esperienza di qualsiasi musicista che usi un PC. In pratica, l'interrupt che arriva dai device audio (schede audio, controller) deve essere eseguito subito. La più semplice delle verifiche che si possono fare per sapere se il nostro sistema dispone di un kernel RT è verificare l'output del comando 'uname -a'. Dovrebbe risultare qualcosa del tipo: Linux 2.6.22-14-rt #1 SMP PREEMPT RT Tue Dec 18 10:01:34 UTC 2007 i686 GNU/Linu (in grassetto gli elementi che contraddistinguono un kernel low-latency) In caso contrario dovremo procurarci una delle distribuzioni Linux suggerite al punto 1, oppure per i più temerari, procedere con la ricompilazione del kernel (vedi riferimenti web sotto). Tuttavia anche se la nostra distribuzione è dotata di kernel low-latency, ricompilare il kernel è vantaggioso in quanto consente di adattare il nucleo del SO al nostro hardware in modo da avere un sistema più snello e prestante di quello fornito dalla versione di default precompilata che carica molti moduli per noi inutili. Riferimenti web: ● http://rt.wiki.kernel.org (qui si trova una guida completa per l'installazione manuale) ● http://lowlatency.linuxaudio.org/

3. ALSA ALSA (Advanced Linux Sound Architecture) è l'emento centrale del kernel per ciò che concerne l'audio e sostituisce a partire dalla versione 2.6 il vecchio sistema OSS ormai deprecato (anche se ancora supportato). Come spesso avviene nel mondo informatico, un software complesso come un SO viene suddiviso in strati software differenti a seconda delle funzionalità. ALSA si colloca in parte all'interno del kernel (driver per le schede audio, PCM, MIDI) e in parte tra il kernel (che come detto gestisce i dispositivi) e le applicazioni (nel nostro caso i programmi audio), fornendo un articolato insieme di strumenti per la regolazione e la configurazione del suono. Oltre alle librerie, all'esterno del kernel troviamo i plugin, come il fondamentale Dmix (o la sua versione full duplex: asym), che si incarica di gestire più flussi audio in ingresso (e uscita) provenienti da diverse applicazioni (e device). Ma il grosso salto in avanti rispetto al vecchio OSS è costituito proprio dalle librerie (alsalib) collocate fra il kernel e le applicazioni che forniscono un alto livello di funzionalità comuni a tutte le applicazioni native ALSA, colmando il gap tra le funzionalità richieste dalle applicazioni e quelle offerte dall'hardware. Esse provvedono alle funzionalità audio, come ad es. conversione tra formati audio, sample rate, numero di canali, ecc.. Tutto questo unito ad un codice separato per il livello utente e quello kernel, offre una gestione migliorata di un sistema con più schede. Ogni device (che può anche essere virtuale) ha assegnati due flussi PCM uno in entrata e uno in uscita (il sistema sarà full duplex laddove l'hw lo consenta).

Le basi di una workstation audio open source di Mario Marino [http://marinomario.wordpress.com] Febbraio 2008

ALSA comprende una grande quantità di driver per schede audio sia consumer che professionali. Mentre Windows necessita sempre di driver esterni che si accompagnano alla periferica installata (ma ha il vantaggio di avere i driver per la totalità delle schede esistenti per ovvi motivi commerciali), ALSA supporta il 90% delle schede audio in commercio ma non la totalità di esse o, per quelle supportate, non la totalità delle loro funzioni. Per una completa panoramica della compatibilità tra ALSA, e quindi Linux, e le schede audio in commercio vedi: http://www.alsa-project.org

Configurare l'audio sotto Linux: Dopo l'installazione di Linux nella maggior parte dei casi è già tutto funzionante. In caso contrario procederemo come segue. Distinguiamo 2 passi: 1. per prima cosa verifichiamo che sia installato il driver per la nostra scheda, ovvero che il nostro kernel abbia il modulo ALSA giusto compilato e installato. Nei kernel precompilati (cioè se avete installato Linux e avete mantenuto il kernel così com'era) vengono inseriti una gran quantità di moduli ed è molto probabile che ci sia anche quello per la scheda montata. Iniziamo verificando che il sistema di riconoscimento automatico delle periferiche collegate (hotplug) veda correttamente il nostro hardware: il file virtuale /proc/asound/cards fornisce un elenco generato dinamicamente delle periferiche audio collegate, sia PCI che USB. Prendiamo nota e facciamo delle verifiche con i seguenti comandi: # lsmod | grep snd # modprobe -l | grep snd il primo fornisce la lista dei moduli audio caricati all'avvio, il secondo quella dei moduli audio compilati presenti nel kernel. Se esiste il modulo relativo alla nostra scheda basterà caricarlo con un semplice 'modprobe <nome modulo>'. E la scheda sarà immediatamente attiva. In caso contrario non resta che ricompilare il kernel, o solo il modulo che ci interessa (cosa non banale visto che l'ottimo moduleassistant di debian non funziona con il kernel real-time).

2. Ora la configurazione. Innanzitutto inseriamo il nostro utente nella lista di quelli che hanno accesso al sistema audio della macchina (si può fare direttamente da GNOME o KDE in Sistema->Amministrazione-->Utenti e gruppi->utilizzo dei dispositivi audio). Poi se abbiamo più d'una scheda audio, col comando 'asoundconf set-default-card <nome scheda>' si sceglie quale sarà quella predefinita (card0). Ma nulla uscirà ancora se non alziamo il volume. Con il comando alsamixer attiviamo un controllo che agisce sui volumi in ingresso e in uscita del device predefinito. Volendo spingerci oltre in configurazioni più avanzate (gestione di più device, device virtuali, OSS..) dovremo agire a mano editando il file .asoundrc presente nella home directory dell'utente, vedi: http://alsa.opensrc.org/index.php/.asoundrc

riferimenti web: http://www.alsa-project.org http://alsa.opensrc.org/

Le basi di una workstation audio open source di Mario Marino [http://marinomario.wordpress.com] Febbraio 2008

4. JACK: il server audio e MIDI In principio il servizio offerto dal server audio di una linuxbox dedicata alla musica doveva appoggiarsi necessariamente agli strumenti di default dell'ambiente X scelto, come ad es. aRTS (KDE), Esound (GNOME) o PulseAudio. Tale server ha il compito fondamentale di instradare verso ALSA tutte le applicazioni che usano l'audio. Il problema nasce quando si richiede alta disponibilità di banda per più applicazioni a bassa latenza, come nel caso di una stazione dedicata alla produzione di musica (in cui è necessario evitare il noto problema dell'audio che va a “scatti”), in tal caso i server predefiniti delle distribuzioni non vanno più bene ed entra in gioco JACK. ll nostro server audio è strettamente connesso ad ALSA e lavora in combinazione con esso. Il modulo Qjckctl consente di interagire comodamente via interfaccia grafica e mette a disposizione dell'utente un patch-panel (tasto 'connect') diviso in due parti AUDIO e MIDI, grazie al quale è possibile connettere le diverse applicazioni disponibili come in un vero e proprio studio di registrazione virtuale. A sinistra abbiamo le uscite e a destra gli ingressi, i fili di collegamento appaiono con una semplice manovra di drag and drop. alsa_pcm è l'ultimo anello della catena dal quale il segnale parte, se stiamo registrando una sorgente esterna (a sinistra) e al quale arriva, se stiamo generando il suono ad es. da Pure Data (finestra destra).Il tasto 'Message' offre una gran quantità di informazioni molto utili, mentre 'setup' ci consente di impostare ALSA come sistema audio e l'interfaccia da usare in base alla configurazione vista a proposito di ALSA. Nonché di intervenire su vari parametri tra cui 'Realtime' da selezionare e mantenere a '0' (massima priorità). Le applicazioni audio "JACK-compliant”, consentono, nel menù delle preferenze di decidere se mandare il segnale a JACK o direttamente a ALSA, bypassando il server audio. La gran parte delle applicazioni audio esistenti sono compatibili con Jack, persino Amarok e Skype. Nel caso impiegassimo il sistema come registratore multitraccia (Ardour) dobbiamo garantirci sufficente banda passante da e verso l'hard disk o su due comandi chrt per attribuire prorità ai device

in questione (HD e soundcard) e hdparm per abilitare nell'HD l'accesso a 32 bit (-c 1), L'UDMA (-d1 -x66) e il trasferimento multisector (-m16). Meglio se il disco è SATA.

Come ogni apparato server, Jack richiede la modalità privilegiata per funzionare correttamente (cioè dovrà essere avviato da root), mentre i programmi che lo usano dovranno essere lanciati da utente non privilegiato, come richiede un uso corretto di Linux. Ci sono vari metodi possibili tra i quali installare il modulo del kernel denominato realtime-lsm, oppure usare PAM (Pluggable Authentication Module). In tal modo non dovremmo più lanciare Jack da root.

Tuttavia chi usa una delle distribuzioni ad hoc suggerite all'inizio non dovrà preoccuparsi di questo, né delle particolari configurazioni (del kernel e non solo) necessarie se dobbiamo installare JACK da zero, in quanto troverà già un sistema configurato per l'audio con Jack pronto per essere usato.

Le basi di una workstation audio open source di Mario Marino [http://marinomario.wordpress.com] Febbraio 2008 Se abbiamo bisogno di un sequencer/riproduttore virtuale di MIDI che traduce da MIDI a PCM (o altri formati) in modo diretto (realtime). Possiamo usare Timidity, avremo cosĂŹ un supporto in riproduzione di file MIDI per le schede che non sono dotate di questo chip (o in caso che tale chip non sia supportato). Il programma puoâ&#x20AC;&#x2122; essre usato come player standalone di midi ma anche come server tra le varie applicazioni.

In questâ&#x20AC;&#x2122; ultimo caso viene creato un device virtuale che il nostro sistema vede come porta MIDI vera e propria. In questo modo, possiamo utilizzare tutte le applicazioni che si appoggiano direttamente al MIDI. Riferimenti web: http://jackaudio.org/ http://www.oneopensource.it/ http://relug.linux.it/wiki/ http://timidity.sourceforge.net/

Le basi di una workstation audio open source di Mario Marino [http://marinomario.wordpress.com] Febbraio 2008

5. Interazioni tra software: OSC Come avveniva ai tempi dell'elettronica analogica, nei quali è nato lo standard MIDI per sincronizzare diversi moduli audio tra loro, anche in ambito DAW ci si è trovati di fronte ad un'esigenza simile. Con la differenza che le apparecchiature hardware sono nel nostro caso moduli software. Per la loro interazione sono nate nuove tecniche tra cui il Rewire, nel caso di due applicazioni da sincronizzare sulla stessa macchina (implementata solo su software proprietario), il progetto LASH per Linux e l'OSC (Open Sound Control), che è una sorta di evoluzione del MIDI. Quest'ultimo usa l'interfaccia Ethernet e l'ampia banda che essa mette a disposizione per connettere in locale (ma non solo!) due PC. OSC è un protocollo di comunicazione fra moderni multimedia device dotati di interfaccia ethernet (PC, sintetizzatori,..). Esso fornisce tutto ciò di cui c'è bisogno per un pieno controllo del suono in real-time. In particolare, combinato con programmi ad architettura di tipo client-server (ad esempio Super Collider) questo protocollo apre nuovi orizzonti di sperimentazione audio. E' supportato da una gran quantità di applicativi audio ma purtroppo non da tutti i principali. Riferimenti web: http://opensoundcontrol.org http://savannah.nongnu.org/projects/lash

6. Plugin e Virtual instruments: LADSPA VST (Virtual Studio Tecnology) è un noto standard per la portabilità di filtri ed effetti che consente una interazione tra moduli molto potente e raffinata. Essa sfrutta le infinite potenzialità dei software di potersi combinare senza quasi limiti di flessibilità (se non quelli fisici del proprio PC) consentendo di poter dotare la propria piattaforma audio di un'enorme quantità di estensioni. Tali plugin, che normalmente emulano un sintetizzatore reale o un particolare effetto o strumento di cui abbiamo bisogno, lavorano inserendosi in un software principale (un sequencer tipo Ardour) che gli consente di girare in perfetta combinazione tra loro.

LADSPA (Linux Audio Developers Simple Plugin API) è uno standard analogo a VST, ma rilasciato sotto licenza GNU/GPL. Analogamente ai plugin VST esistono una gran quantità di loro corrispondenti open source che funzionano con questa tecnologia. Ma non solo. Esiste una particolare tecnica, FST, in grado di far girare anche i VST (o almeno gran parte di essi) con tutti quei software sotto Linux che implementano LADSPA (Audacity, Ardour..) WINE , indispensabile per far funzionare FST, è la piattaforma Linux di emulazione del funzionamento di windows e del modo particolare con cui i programmi interagiscono con tale SO. Per poter continuare ad usare quel software proprietario di cui non riusciamo proprio a fare a meno o per quello che (ancora e sempre meno) non può proprio essere fatto con software libero. Portaudio è un progetto che lavora per un futuro in cui le applicazioni audio potranno essere progettate con omogeneità per facilitarne l'utilizzo e cross-platform, ovvero utilizzabili su tutti i principali SO. Riferimenti web: http://www.ladspa.org/ http://audacityteam.org/vst/ http://axeldamage.wordpress.com/ http://www.opensound.com http://www.portaudio.com/

Le basi di una workstation audio open source di Mario Marino [http://marinomario.wordpress.com] Febbraio 2008

7. Gli applicativi principali per produrre musica AUDACITY (http://audacity.sourceforge.net/): editor audio di riferimento per l'open source, supporta LADSPA ● ARDOUR (http://ardour.org/): lo stato dell'arte per Linux come sequencer/reg. multitraccia) ● HYDROGEN (http://www.hydrogen-music.org/): drum machine professionale ● PURE DATA (http://puredata.info/): Pure Data è un linguaggio di programmazione visuale per la computer music in tempo reale, basato sul paradigma di calcolo 'dataflow'. nella scarna interfaccia grafica ogni rettangolo rappresenta una funzione che puo' essere o predefinita (Externals), o una patch costruita come file separato. In quest modo si ottiene un elevato livello di modularità della struttura che risulterà estremamente flessibile in fase di programmazione. Ogni modulo potrà essere unito ad un altro in base ai canali di In/Out presenti con dei fili generati con drag and drop, in modo da formare una struttura in cui l'ordine di esecuzione è depth-first, cioè ogni ramo è esplorato fino alle foglie prima di procedere con gli altri rami. Ogni programma, chiamato patch, ha una sua finestra principale e ne può richiamare molte altre al suo interno. ● Le due modalità di intervento sono run e edit, con quest'ultima si costruiscono le patch, in modalità run le si eseguono ad esempio in una performance live (con Ctrl-E si passa dall'una all'altra). ●

Le librerie sono importanti per arricchire di funzionalità predefinite i propri progetti. A questo proposito segnaliamo che le versioni di questo software preinstallate nelle distribuzioni Linux dedicate all'audio non dispongono di tutte le librerie disponibili. Consigliamo l'installazione della versione extended di PD che è completa di tutto cio' che serve anche per lavorare con i video (libreria GEM) ed è scaricabile dal sito ufficiale.

SUPER COLLIDER (http://supercollider.sourceforge.net/) Potente software open source nato sotto mac OS che presenta molte analogie con pure data, anche se molto diverso nel modo in cui si interfaccia con l'utente. Con SC si lavora esclusivamente attraverso riga di comando (in Linux tramite l'editor Emacs) e, cosa che lo differenzia da altri progetti simili come Csound, in tempo reale. Ovvero, ci troviamo di fronte ad uno strumento che consente di avere sotto controllo non solo, come avviene nei live electronics, alcuni dei numerosissimi parametri sui quali si può intervenire dal vivo su software tipo Ableton Live (attravarso le manopole di un controller interveniamo via MIDI sull'inviluppo di un synth o un filtro di risonanza..), nel nostro caso generiamo dal vivo direttamente l'algoritmo che produce il suono (live coding). Agiamo alla radice numerica del suono, laddove esso si produce. Si tratta di un vero e proprio linguaggio di programmazione ad oggetti, nel quale quindi ogni entità possibile è un oggetto e tutte (proprio tutte) le entità possono essere controllate dall’utente secondo un unico principio: tutte avranno attributi e metodi, a tutte sarà possibile inviare dei messaggi poiché presenteranno all’utente una certa interfaccia , in un sistema in cui: ●

Le basi di una workstation audio open source di Mario Marino [http://marinomario.wordpress.com] Febbraio 2008

oggetto e metodo concernono la definizione dell’oggetto dall’interno ● messaggio e ricevente concernono la comunicazione con l’oggetto dall’esterno La struttura del programma ricalca la tipica architettura client/server, vi è una separazione strutturale tra il server che ha il ruolo della sintesi sonora vera e propria (scsynth), e il client che interpreta il linguaggio elaborato dall'utente (sclang). Questa caratteristica, in abbinamento con il protocollo OSC visto al punto 6, apre possibilità nuove di sperimentazione in ambito di performance live: l'artista può agire in un luogo fisicamente separato rispetto a quello in cui i suoni vengono realmente generati, in una stanza diversa, nel caso di connessione via LAN. O addirittura, nel caso in cui provvedessimo a connettere client e server via internet, dall'altra parte del mondo. ●

http://marinomario.wordpress.com/