questa pagina è in fase di stesura e aggiornamento

Il termine DAW – Digital Audio Workstation – è utilizzato per definire sia il programma di editing e produzione musicale, come ad esempio Logic o Reaper, sia il computer sul quale il programma gira, ed è questo l’argomento di questo post. Con il mio laboratorio MirComputers assembliamo questo tipo di macchine, sia con windows sia con mac; alcune di queste considerazioni saranno valide per entrambi i sistemi, altre specifiche per windows. Il mio intento non è darvi la pappa pronta ma darvi alcune indicazioni su cosa potrebbe esser contro-intuitivo.

Ricordiamo comunque che questa non è un alternativa al lavoro di un esperto se il vostro intento è risparmiare ; se lavorate, quante volte avrete sentito nel vostro campo persone dirvi “mio cuggino lo fa con meno”, magari la band che si vuole mixare registrare da sola, il fonico che si fa i master in casa, per risultati terribili? Il fai da te ha senso se volete imparare, avete tempo di starci dietro e volete il controllo in futuro sulla manutenzione.
La nostra esperienza vi assicura di spendere meglio il vostro budget e a parità di componenti otterremo prestazioni migliori con un assemblaggio e tuning corretti.
Vi basti un piccolo viaggio nel canale youtube di Falco75 dove raccogliamo qualche esperienza di computer che ci vengono portati da sistemare perchè fatti con assemblaggio “casalingo”.

Il grande dibattito mac windows, cercando di farla breve

I sistemi mac sono più diffusi nel mondo audio per una serie di motivi più o meno tecnici. Realizzando pochi prodotti e partendo da una fascia medio-alta (molto sovraprezzata) si mantiene un idea che “comprare mac va bene” rispetto alla grande quantità di configuazioni windows anche di infima qualità. La ridotta scelta di componenti HW e il controllo integrato con il SW permettono ad apple di garantire driver estremamente stabili e permette a chi sviluppa software di fare testing e tuning più mirati ed estesi su poche macchine senza dover supportare migliaia di diversi componenti tra cpu, schede video, controller USB e schede wifi ecc.

Il sottosistema audio mac CoreAudio è potentissimo e supporta moltissime più funzioni – e schede – integrate direttamente nel sistema operativo.

E pur venendo io da 15 anni di linux e windows, mi trovo molto più a mio agio con macos a livello di usabilità, in generale l’esperienza d’uso è infinitamente più “scorrevole”. A chi mi dice che è soggettivo, inizio a farvi vedere i 4 o 5 diversi pannelli di controllo di windows dove si possono modificare in maniera diversa IP e DNS – ancora oggi in windows 11 è tutto un incubo di stratificazione di interfacce per fare la stessa cosa.

L’esperienza macos è in un certo senso simile a quella del gaming console, una riduzione della complessità alla base HW facilita il lavoro; ma sotto alla scocca c’è comunque un sistema unix completo con zsh, con la possibilità per dire di installare package manager come brew, e fino a Catalina era ancora modificabile l’intero filesystem in maniera molto più profonda di windows permettendo per esempio di “sradicare” quasi qualsiasi componene apple per un utilizo barebone leggerissimo.

Dalla catena di segnale al processing audio

Il concetto di catena di segnale è fondamentale da aver presente: suoniamo una nota di un qualsiasi strumento, questa passerà poi per vari stadi di elaborazione come possiamo immaginare una chitarra con la pedaliera; questi stadi di elaborazione sono disposti in serie e il suono cambierà a seconda dell’ordine in cui vengono messi. Facendo un mix/master di una traccia ovviamente ci saranno tantissime catene di segnale, e queste sarebbero elaborazioni parallele – ma molto raramente saranno indipendenti, in quanto molte di queste saranno interconnesse magari utilizzando mandate, bus, sidechain. E per elaborare questo tipo di catene, si deve ancora una volta rispettare l’ordine e non si potrà sfruttare il parallelismo della CPU.
Anche avendo tantissime tracce, tutta l’elaborazione si trova ad aspettare la catena più lunga, creando un utilizzo dei core che si vede spesso nei grafici dei programmi come un “albero di natale”.

La buffer size

Il processing audio digitale si basa sull’elaborazione di piccoli pacchetti di dati che vengono poi trasformati in segnale analogico e riprodotti. Più piccoli sono questi pacchetti, più immediata sarà l’uscita del suono rispetto a quando premiamo ad esempio i tasti MIDI, più veloce dovrà lavorare la CPU. Questo parametro si chiama buffer size e solitamente permettono di scegliere da 32 a 1024.

Perchè il peso di elaborazione cambia? Vi farò un esempio; pensate a costruire una casa di 3 piani, avendo il tempo di relizzarli insieme tantissimi lavori verranno ottimizzati in contemporanea e realizzati una volta sola, ma se pensate di dover fare un piano alla volta, senza poter iniziare il nuovo prima di aver finito quello prima e dovendo ogni volta ripulire tutto il sito di lavoro dovendo ricominciare da capo 3 volte. Nel primo caso i mezzi pesanti saranno fondamentali per portare tutto il materiale una volta sola, mentre nel secondo l’agilità di mezzi più piccoli e un lavoro manuale sono più efficaci.

Entra quindi in ballo questo problema: il concetto di “velocità” non è univoco, in quanto potrebbe significare sia un tempo di risposta, quanto mi ci vuole per iniziare qualcosa, sia il tempo di completamento del dato lavoro.

Conseguenza pratica

Le prestazioni che sono richieste al computer per elaborare al meglio l’audio – sopratutto a basse latenze – non sono immediatamente riconoscibili con il numero di core o il loro IPC

Sarà invece importante considerare molto le latenze come quella della RAM e interne tra i vari core. Questi valori non sono quasi mai testati – eccezione Anandtech – ma per fortuna corrispondono anche ai parametri che determinano le prestazioni di una cpu per gaming!

Chi ricorda ad esempio le  cpu x299 o i primi Ryzen 1700x, che pur avendo 8 core con punteggi nei test incredibili non riuscivano a ottenere gli stessi frame nei giochi dei semplici 4 core 6700k ? Questo perchè erano cpu con enormi problemi di latenze interne dovuti a scelte di design fatte per risparmiare su progettazione e produzione (per aumentare le yelds riducendo i difetti critici): la mesh per x299 e i core complex per ryzen. Problemi ad esempio non presenti nelle cpu x99 single ringbus (fino a 8 core per haswell-e e 10 core per broadwell-e) e nelle serie “consumer”chipset Z/B/H come ad esempio 4790k, 10850k e ora i5 12400/12500/12600 non K.

Vi faccio un esempio pratico di esperienza personale; ho iniziato ad interessarmi alle daw per quello che poi sarebbe diventata lamia società hybris audio realizzando un sistema doppio computer master hackintosh con logic e slave windows collegati tramite vienna ensemble pro per produrre orchestra; entrambi erano i7 6700, master 16gb ram e slave ben 64. Volendo condensare il sistema abbiamo provato una macchina unica hackintosh con uno xeon 2678 v3 e 128gb di ddr3 , che però si è rivelata non solo incapace di gestire il lavoro delle due precedenti insieme pur avendo più del doppio di potenza CPU e di RAM totali, ma anche di prendere il posto di una delle due singolarmente! Pensando il problema fosse semplicemente la frequenza abbiamo comprato un costosissimo i9-7960X e anche questo non reggeva nessuno dei due ruoli singolarmente – nemmeno slave con windows !!

Era il singolo ringbus ad alta frequenza a dare al semplice 6700 le prestazioni superiori per il nostro lavoro, e parliamo di template orchestrali da 200 e passa tracce con automazioni midi e varie istanze di altiverb per gruppi separati, mentre lo slave gestiva 2tb di orchestra EastWest Platinum (ora siamo arrivati a quasi 4).

TBC

REFERENZE ( in inglese )

come funziona l’audio buffer (video) https://www.youtube.com/watch?v=GUsLLEkswzE

latenze intercore per x99, x299 e ryzen https://www.reddit.com/r/intel/comments/6ieva3/amd_ryzen_vs_x99_vs_x299_intercore_latency/

dual ringbus xeon (x99) https://www.anandtech.com/show/8423/intel-xeon-e5-version-3-up-to-18-haswell-ep-cores-/4