Questo è un articolo pubblicato nel 2004 che parla di Apple e del suo sistema audio e midi nel passaggio da OS9 a OSX. Un po’ di storia ogni tanto non fa male. È stato perso e per fortuna recuperato. Abbiamo mantenuto la data di pubblicazione originale, ma se ne avete notizia ora (2015) da FB o G+, sappiate che questi o erano in fasce o non erano proprio nati! 🙂
di Stefano Daino, responsabile del settore digital audio della i3 S.r.l. e del software DSPQUattro
Ripubblicato il 6 Ottobre 2015
Apple, ormai da qualche anno, ha introdotto il suo nuovo sistema operativo MacOS X, basato su un kernel di tipo Unix, completamente diverso nello spirito, concepimento, realizzazione dai precedenti sistemi operativi Macintosh. Dopo circa un anno di più o meno timida introduzione, o meglio sperimentazione, nel suo secondo anno di vita MacOS X ha fatto piazza pulita di MacOS 9, che tanto rassomigliava ai suoi predecessori. Badate che questo non è l’ennesima trovata commerciale, poiché le nuove macchine non sono e non saranno capaci di far girare il vecchio MacOS 9 se non che in una modalità, detta “Classic”, che assomiglia molto più ad un emulatore che ad un vero sistema operativo. In altre parole, questo significa che il vecchio software potrebbe girare decisamente più lento, o non girare affatto. Questa transazione è molto più sostanziale rispetto a quella che Apple ebbe il coraggio di fare nel trapasso fra sistemi basati su microprocessori 68k e PowerPC.
Dunque, per amore o per forza, Apple ha forzato la mano ai suoi vecchi e potenziali futuri clienti, costringendo anche le case produttrici di software ad affrontare dei cambiamenti, molte volte decisamente sostanziali. E questo, dal punto di vista degli utenti, significa, senza mezzi termini, costi per aggiornare I propri software al nuovo sistema operativo. La domanda sorge spontanea, ne vale la pena? Questo speciale vuole trovare una risposta, relativamente al settore audio e MIDI, guardando al passato, al presente e cercando di prevedere il futuro, se questo fosse mai possibile.
Un sistema operativo è composto da due principali parti: quella che si vede, e quella che non si vede.
La parte di MacOS X che si vede, ovvero l’interfaccia verso l’utente – grafica e di utilizzo – è veramente notevole. Bisogna anche dire che richiede schede grafiche di prestazioni non indifferenti, semplicemente al fine di disegnare ombre, trasparenze ed altro di dubbia necessità salvo il fatto che dopo è molto difficile tornare indietro. La verità è che lavorare con un computer che offre un’interfaccia grafica spettacolare si manifesta in una sensazione di rilassamento e fluidità operativa che non ha rivali. E che ripaga. Inoltre, nel riprogettare l’interfaccia operativa del sistema, Apple ha utilizzato il meglio dei suoi precedenti sistemi operativi e delle interfacce tipiche dei sistemi basati su un kernel Unix. Per questo, parlando con la maggior parte degli utenti Mac, anche se a un primo approccio si tende a scherzare sull’inutilità delle ombreggiature sotto le finestre del Finder, il look del nuovo sistema MacOS X viene sempre promosso a pieni voti. Inoltre, per gli affezionati di alcune particolarità del vecchio modo di lavorare su MacOS 9, sono già comparse diverse utility che ripianano eventuali nostalgie, tipo il menu Apple configurabile e così via.
E quello che non si vede Ahi, ahi scoprendo questa pentola ci si scotta proprio. Il punto è che MacOS X è diverso dai suoi predecessori non soltanto per il look accattivante ed i pupazzetti della sua interfaccia grafica. “Meno male”, direte. Ma la realtà è che, pur introducendo tutte quelle meraviglie del vero multitasking sulla piattaforma Macintosh, ha contemporaneamente annullato tutti I vantaggi del vecchio, ormai pensionato, MacOS 8/9. Prima fra tutte: la capacità, da parte di un applicativo, di fare quello che si vuole – incluso il poter far collassare il sistema, fino al crash. “A che serve una simile cosa?”, vi chiederete? Beh, nello scrivere un’applicazione che funzioni in tempo reale per fare del digital audio, molto, anzi moltissimo. Ed è per questo che il Mac era così ben visto dalle grosse case produttrici di software musicale. Ma facciamo un passo indietro.
Un po’ di storia: l’audio ed il MIDI sui sistemi Macintosh prima di MacOS X.
L’audio sul Mac ha una storia che parte da parecchio lontano. Apple sviluppò una componente di sistema detta SoundManager fin dai tempi del MacPlus e Mac II. E, incredibile a dirsi, la storia non ha mai subito o giovato di alcuna evoluzione, se non che veramente minimale, da allora fino ai giorni nostri. I motivi sono semplici: il SoundManager faceva perfettamente quello per cui era stato concepito: nulla a che fare con l’audio digitale a cui siamo abituati ora, bensì il gestire un sofisticato sintetizzatore hardware – l’Apple Sound Chip – che era presente sulle piastre madri dei Mac fin dal Mac II. Con una serie di comandi, un’applicazione poteva facilmente chiedere al Mac di generare suoni complessi, e perfino suonare dei file audio, il che era straordinario per un’epoca in cui I campionatori musicali erano appena comparsi. Tecnicamente era una versione più complessa e potente del sintetizzatore tipo quello – di tutto rispetto – di un Commodore 64, ma la concezione e funzionalità erano molto simili. La qualità, per fortuna, era più legata alla realizzazione dell’hardware e non – in minima parte – a una limitazione dell’interfaccia di programmazione. Questo ha portato al fatto che la stessa applicazione, con la stessa interfaccia verso il SoundManager, suonasse sempre meglio con l’evoluzione dei Macintosh, che nel corso degli anni introdusse interfacce audio stereo, a 16 bit e 44.1 kHz. Applicazioni storiche, tipo SoundEdit 16 ed Alchemy e permettetemi di menzionare il mio editor audio D-SoundPRO, senza alcun hardware aggiuntivo erano capaci di suonare con qualità di tutto rispetto, considerando che la CPU girava a poche decine di MHz. La chiave era una sola: non era la CPU a suonare, ma un chip dedicato. La CPU si occupava di mandare dei comandi, niente di più.
Ma c’era un particolare comando del SoundManager che apriva una porta al digital audio, per il quale molti programmatori vennero attirati alla piattaforma Mac: un comando che permetteva, ad un applicativo, di essere interrogato al fine di riempire il buffer audio da suonare. E, ancora più importante, il comando veniva eseguito con una priorità pari a quella del sistema operativo, tecnicamente detto a livello di interrupt. In poche parole, il Mac si trasformava con facilità in una piastra a microprocessore dedicata, la cui unica funzione era quella di servire un applicativo, occupato a suonare, senza che nulla lo possa fermare o distogliere. Badate che questo è sostanziale: senza questa priorità, un semplice inserimento di un floppy disk nel driver avrebbe fermato o mandato fuori sync il vostro sequencer audio.
La possibilità di lavorare a livello di interrupt del Mac fu subito utilizzata per produrre dei sequencer MIDI che avessero un timing professionalmente accettabile. A proposito del MIDI, Apple aveva introdotto, al pari di SoundManager, un driver MIDI, detto MIDI Manger. Ma la sua realizzazione lasciava parecchio a desiderare, in termini di sincronia, pesantezza e pessime interfacce di programmazione. Molto probabilmente Apple non considerava strategico il settore musicale. O forse, come si rumoreggia e come sta tornando alla ribalta in questi ultimi tempi, Apple aveva avuto il permesso di usare il nome “Apple” dall’omonima casa discografica a patto di non occuparsi di musica, e il MIDI rientrava pericolosamente nella categoria musicale. Fatto sta che, per fortuna, ci pensarono le case che volevano entrare nel mercato dei sequencer MIDI a produrre dei driver MIDI per la piattaforma Mac, ovvero Opcode con lOMS e Mark of Unicorn con FreeMIDI. A un certo punto, la diffusione di OMS era così palese che Apple stessa, lavandosi le mani per l’inutilità e fallimento dell’Apple MIDI Driver, dichiarò che OMS sarebbe stato il driver MIDI ufficiale della piattaforma Mac.
Ma torniamo all’audio: il salto ci fu con l’introduzione della piattaforma hardware basata su microprocessori PowerPC. Badate: Apple SoundManager non cambiò di una virgola, a parte il fatto che era più veloce poiché ricompilato per PowerPC. E allora? Il punto è che la CPU sarebbe stata capace di per se di generare stream audio da suonare, senza alcuna necessità di comandare un eventuale sintetizzatore hardware aggiuntivo. Questo, accoppiato con la porta aperta al livello di interrupt che permetteva di avere il completo controllo del sistema, rendeva il Mac la piattaforma ideale per scrivere applicativi integrati audio/MIDI. E nacquero I primi sequencer audio che non richiedevano alcun hardware aggiuntivo.
A questo punto era evidente che l’unica funzione necessaria di SoundManager era quel comando a livello di interrupt di interrogazione per il riempimento del buffer audio per altro sempre presente fin dalla sua introduzione. Tutto il resto sarebbe stato gestito dal sequencer. E fu altrettanto evidente che, intorno a quel comando, sarebbero state molto utili una serie di interfacce per semplificare la programmazione e soprattutto, aprire il Mac all’utilizzo di sofisticate interfacce audio hardware di terze parti – cosa che, quando Apple introdusse SoundManager, era ancora abbastanza futuristica. Come per il MIDI, anche in questo caso, non fu Apple ad occuparsene, bensì una casa software con evidenti interessi nel settore: la Steinberg, con l’introduzione dei driver ASIO.
ASIO integrava egregiamente delle funzionalità che in SoundManager erano in qualche modo nascoste o comunque difficili da gestire: si concentrava a fornire ad un’applicazione la possibilità di decidere cosa suonare, invece di fornire comandi al sintetizzatore come faceva SoundManager. Dall’altro versante, consentiva a case produttrici di hardware di integrare facilmente schede I/O audio sulla piattaforma Mac. Anche per questo, ASIO è diventato uno standard. Non è d’oro tutto quello che luccica, e ASIO non fu da meno: il difetto fu subito evidente. Nel progettarlo Steinberg peccò di egemonia, probabilmente non a caso, e lo fece mono client. Che cosa vuol dire? Semplice, se un applicativo utilizza il driver ASIO, nessun altro applicativo lo potrà fare. In altre parole, se gira Cubase, gli altri applicativi non saranno capaci di emettere alcun suono. A questo pose rimedio l’ennesima casa interessata a che questo non accadesse, la Propellerheads con Rewire. Visto che ASIO non avrebbe permesso al loro prodotto di punta Rebirth di suonare se utilizzato in integrazione a un sequencer audio tipo Cubase, e Rebirth aveva troppo bisogno di questa integrazione, Rewire integrava la gestione dei stream audio fra applicativi invece che fra applicativo ed il sistema. Questo permetteva di fatto di suonare attraverso, invece che in concorrenza, un applicativo ASIO tipo Cubase.
Steinberg dal canto suo si pose il problema, e aprì il proprio prodotto di punta, Cubase, all’utilizzo di software di terze parti di tipo plug-in tramite la definizione dell’interfaccia VST. In questo caso, però, a differenza di Rewire, le limitazioni sono notevoli. In altre parole, il plug-in non è un applicativo parallelo al sequencer audio che lo ospita, bensì una semplice funzione aggiuntiva di modifica sullo stream audio. Questo pone delle evidenti limitazioni funzionali, anche se le case produttrici hanno fatto I salti mortali per produrre plug-in con funzionalità notevolissime, quali completi campionatori software programmabili e così via. E, se mi permettete un commento, è incredibile a dirsi la possibilità da parte di un plug-in di causare un crash dellhost o di sistema. Possibilità chiaramente così tanto temuta dai produttori di host di plug-in, quali il sottoscritto…
Questo excursus lascia volontariamente fuori una serie di interfacce che sono state sviluppate al fine di controllare hardware dedicati – tipo Protools di Digidesign – e che furono progettate al preciso scopo di utilizzare hardware esterni, ma inutilizzabili altrimenti. Questo per introdurre il presente.
Il presente: CoreAudio e CoreMIDI.
Una prefazione doverosa sull’implementazione di quello che poi è adesso CoreAudio e CoreMIDI: prima della versione 10.2 (detta anche Jaguar), l’implementazione audio e MIDI di MacOS X è stata una palese truffa ai danni dei consumatori. Roba da denunciare a “Mi Manda Rai 3”, vi garantisco. Fino al 10.1 compreso, le interfacce e i drivers erano poco più delle versioni di sviluppo, con bugs, mancanze e prestazioni da far rizzare I capelli. Questo è senza mezzi termini confermato dal fatto che la stragrande maggioranza delle applicazioni audio per MacOS X richiedono 10.2 o seguenti per girare. I pochi che non lo dichiarano, non danno alcuna assistenza tecnica agli utenti (oramai pressoché scomparsi) che utilizzano il 10.0 o 10.1. E vi lascio immaginare I commenti che ho sentito quando Apple ha chiesto a tutti quei “beta tester” inconsapevoli una ragionevole cifra per l’aggiornamento dal 10.1 al 10.2, invece di un rimborso spese con tanto di scuse.
Ritornando a noi, la storia che si è raccontata vuole far capire che, nel momento in cui Apple ha affrontato il problema di come MacOS X, così tanto riscritto da capo rispetto al passato, avrebbe dovuto integrare le vecchie funzionalità di SoundManager, le carte sul tavolo erano chiare. I riferimenti erano chiari: per la gestione MIDI sarebbe stata OMS. ASIO era eccellente, anche se migliorabile, e doveva permettere quello per cui era stato creato Rewire. Come nel caso VST, era evidente la necessità, eventualmente ampliata, di una tecnologia che permettesse di sviluppare plug-in.
Ma non è difficile individuare la prima e palese difficoltà che Apple ebbe nell’introduzione dell’audio sotto MacOS X, da cui molto probabilmente tutti problemi audio del nascituro X fino al 10.2: sotto MacOS X è proibito lavorare a livello di interrupt con quelle palesi priorità tipiche del MacOS 8/9. Perchè? La risposta è semplice: sotto un sistema operativo che si rispetti, un applicativo ha sempre una priorità inferiore all’OS, e ne è sempre controllato. Questo è uno dei principi essenziali per garantire che un applicativo non possa, in alcun modo, causare un crash di sistema. Al limite, se l’applicativo esegue unoperazione non valida o entra in un ciclo senza fine, potrà sempre essere “killato” dal sistema operativo, che ne controlla sempre l’esecuzione. Sotto MacOS 8/9, invece, un’operazione non valida o un loop senza fine a livello di interrupt, eseguita magari da un plug-in VST, causava un completo congelamento del sistema senza alcuna possibilità di recupero. In poche parole, sotto MacOS X, viene meno quella caratterisitca del tipo “posso avere la CPU tutta per me stesso” tanto amata dai programmatori di digital audio sul Mac.
Cosa è successo sotto MacOS 10.2 per cui adesso le applicazioni audio possono girare bene? Apple ha messo un po’ d’ordine alle priorità dei singoli task, ed il task CoreAudio è stato promosso, anche se tenuto sotto controllo. In poche parole, il programmatore può essere ragionevolmente sicuro che la propria applicazione audio giri ragionevolmente bene, finché alla CPU rimane un certo tempo di sicurezza per potere uscire da situazioni di collasso pericolose. Certo, questo è sulla carta, anche se bisogna dire che a Cupertino hanno fatto una lavoro eccellente. E bisogna anche dire che le caratteristiche hardware dei Mac hanno raggiunto prestazioni notevoli, il che aiuta infinitamente. Come dire, è più facile avere il tempo per un’applicazione audio se il microprocessore va a velocità dell’ordine dei 1000 MHz invece che dei 100. Lo stesso, d’altra parte, è avvenuto nel mondo dei Windows/PC.
Torniamo a noi
e al MIDI sotto X. Visto che Opcode che aveva progettato e realizzato OMS nel frattempo aveva chiuso i battenti, niente di più semplice per Apple che assumere il progettista capo di OMS e metterlo a capo del gruppo per la realizzazione di CoreMIDI. Niente di più ovvio dunque che CoreMIDI sia una versione evoluta, nativa di MacOS X, di OMS. Permette con facilità di gestire diverse interfacce MIDI multiporta contemporaneamente, e come il suo predecessore offre una utility di sistema per la sua configurazione grafica. Rispetto a OMS è straordinariamente più veloce nel distribuire I dati MIDI alle applicazione che ne facciano richiesta. Questo si traduce immediatamente in latenze incredibilmente più basse nel suonare strumenti virtuali in tempo reale tramite tastiere MIDI esterne. Questo, unito alla capacità di configurare basse latenze anche per il driver audio di cui parleremo di seguito, consente veramente di utilizzare il vostro Mac sotto MacOS X quale sintetizzatore virtuale a se stante anche dal vivo o suonando in gruppo. E mi riferisco allo stesso modello Mac che sotto MacOS 8/9 avrebbe avuto latenze proibitive allo scopo.
Fig1 OMS SetUp sotto macOS 8/9
Fig2 L’Utility “Configurazione MIDI Audio” di MacOS X
Stranamente in CoreMIDI vi sono ancora alcune lacune, o caratteristiche che forse ancora mi sfuggono. Un esempio fra tutti, la capacità di un applicativo che faccia uso del MIDI di sapere quali unità sono collegate al vostro network MIDI, nominandole per nome. A differenza di OMS, che faceva vedere tutti I sintetizzatori collegati alle interfacce MIDI in modo chiaro e trasparente, il CoreMIDI dà visibilità solo delle porte MIDI dell’interfaccia, non delle periferiche collegate. Infatti, un applicativo, che voglia offrire un’interfaccia grafica per utilizzare un certo expander, deve fare i salti mortali per sapere come questo expander si chiama e dove è collegato, perchè l’unica cosa veramente nota e certa è che l’interfaccia MIDI ha, per esempio, 8 porte brutalmente chiamate port 1, 2, 3,4. etc. Ma se il vostro expander si chiama XV5080 o XYZ non è noto in maniera ovvia e diretta. Inoltre, la gestione interna del messaggi di SysEx lunghi non è stata molto ben regolata da una chiara definizione tecnica. Questo ha portato ad una certa confusione nella definizione di come un driver dell’hardware MIDI debba trattare I messaggi di SysEx lunghi, come quelli per il MIDI Sample Dump Standard. Molti hanno seguito le direttive che precedentemente erano dell’OMS. Altri, che l’OMS non lo conoscono, hanno seguito un’altra interpretazione, con la conseguenza che la stessa procedura di MIDI Sample Dump Standard non è sempre compatibile utilizzando interfacce MIDI diverse.
Inoltre, il vecchio OMS forniva una particolare cavo MIDI virtuale chiamato IAC, allo scopo di fornire una facile ed immediata comunicazione di dati MIDI fra diverse applicazioni. Sinceramente, ancora non è molto chiaro come questo avvenga sotto CoreMIDI. Probabilmente il problema è che ancora non vi sono molte applicazioni per porsi seriamente la domanda, e dunque le possibili soluzioni… (*)
(*) sembra che Apple abbia anticipato le preghiere dell’autore, che scriveva l’articolo ai tempi del MacOS 10.2… MacOS 10.3, detto Panther, re-introduce l’utilissimo canale MIDI virtuale IAC così come era nell’OMS. Dunque, un punto a favore di Apple…
Fig3 Il Menu MIDI di un Virtual Instrument in DSP-Quattro sotto MacOS 8/9: notate come nella lista compaiono tutti I modelli dei sintetizzatori collegati al network MIDI.
Fig4 Il Menu MIDI di un Virtual Instrument in DSP-Quattro sotto MacOS X: nella lista compaiono solo i nomi delle porte dell’interfaccia MIDI.
So che il nuovo aggiornamento di sistema MacOS X, il 10.3, detto Panther, introduce delle novità, per altro ancora un po’ misteriose dopo un mese dalla sua introduzione sul mercato. Vedremo presto se le comuni proteste di diversi programmatori hanno avuto effetto.
In ogni caso, CoreMIDI su 10.2, grazie alla sua velocità, basse latenze e facilità di configurazione, viene promosso nel passaggio dal MacOS 8/9 a MacOS X.
Parliamo adesso di CoreAudio, l’evoluzione del SoundManager sotto MacOS X firmata Apple. Bisogna dire che Apple ha imparato molto bene dalle esperienze di ASIO, Rewire e VST sotto MacOS 8/9.
La tecnologia di Apple per la produzione di plug-ins sotto MacOS X rientra sotto la terminologia chiamata AudioUnit. In realtà la definizione AU allarga di molto il concetto di plug-in, che non è limitato ad una funzione di modifica dello stream audio, prevedendo una migliore definizione di musical instruments e plug-in di destinazione, come un file recorder. L’indipendenza di un plug-in AU rispetto all’applicazione che lo ospita è notevole, quasi comparabile a quella di un applicativo indipendente. C’è stato, inoltre, nel protocollo AU, un notevole passo avanti anche per la definizione di plug-ins che possano generare buffer di dimensione diversa rispetto a quelli in ingresso, come dovrebbe avvenire, per esempio, nel caso di un plug-in che voglia fare un TimeStretching, impossibile nel protocollo VST.
Purtroppo c’è una palese guerra politica fra Apple (ovvero, in conseguenza, Emagic), e – dall’altra parte della barricata – Steinberg. La prima ha ostacolato palesemente la diffusione di un protocollo VST anche sotto MacOS X, e, dopo aver introdotto gli AudioUnit, ha ufficialmente ed alquanto polemicamente dichiarato che i prodotti Emagic non supporteranno i plug-ins VST, che nel frattempo Steinberg aveva definito indipendentemente anche sotto MacOS X. Dal canto suo, Steinberg sta palesemente ritardando l’introduzione del supporto AudioUnit nei suoi prodotti per MacOS X. Questo genera un certa confusione e notevole difficoltà fra i sviluppatori, che preferirebbero una maggiore chiarezza a prescindere dalle scelte commerciali. La difficoltà aumenta considerando che, avendolo promesso, Emagic ha messo in giro un convertitore VST->AU che, sulla carta, dovrebbe consentire ad un produttore di un plug-in VST di compilare con facilità un plug-in AU equivalente. In realtà, il tool è carente, e produce un software di qualità pessima, difficilmente utilizzabile. I commenti in giro non servono purtroppo a far sì che il buon senso prevalga sull’evidente interesse di Apple di affossare VST sotto MacOS X. Chissà, forse fra poco tempo vedremo la tecnologia AudioUnit anche sotto Windows allora sì che si vedranno i fuochi d’artificio ma a pagare sarà il povero musicista, che non capirà più cosa gira e dove gira, e i programmatori, che avranno diversi formati dello stesso plug-in da sviluppare e mantenere.
L’introduzione di CoreAudio sotto MacOS X, per fortuna, è stata molto più pacifica. Dal canto suo, Steinberg non aveva nessun interesse a spingere una versione di ASIO sotto MacOS X, e CoreAudio ne eredita egregiamente tutti I vantaggi, risolvendone diversi difetti.
Prima di tutto, CoreAudio è multi client, permette a diverse applicazioni di suonare contemporaneamente (a meno che il driver non lo consenta esplicitamente, come mi risulta faccia il driver di Digidesign, ma qui apriamo altre polemiche su cui è meglio sorvolare). E, incredibile, CoreAudio è anche multi device, ovvero in linea di principio è possibile ricevere ed indirizzare diverse interfacce audio contemporaneamente. In realtà, però, è compito dell’applicazione sincronizzare i flussi di dati, il che pone diversi problemi tecnici. In ogni caso, il non avere una limitazione a priori, è molto interessante.
Inoltre, rispetto all’ASIO, vengono migliorate decisamente le responsabilità dell’applicativo in fase della conversione dei samples audio da e verso il driver specifico. A differenza di ASIO, infatti, un applicativo vede la maggioranza (in verità mi risulta che sia la totalità) delle interfacce da/verso il driver audio in un solo formato, con precisione in floating point a 32 bit. Questo rimanda al driver la conversione da questo comune formato ad un formato di tipo intero, a precisione di 16, 24, 32 bit o altro in funzione delle caratteristiche fisiche dell’interfaccia audio. In altre parole, un applicativo dovrebbe sempre suonare alla migliore qualità audio possibile, e non, come avviene con ASIO, meglio o peggio a seconda di come l’applicativo è capace di effettuare la conversione fra il suo formato floating point e quello del intero del driver ASIO.
CoreAudio permette latenze particolarmente basse. Non che questo non fosse possibile sotto ASIO, ma diciamo che sotto CoreAudio questa caratteristica è molto più pubblicizzata ed i produttori di driver CoreAudio sono spinti a rispettarla. In pratica, nella maggioranza dei casi, l’applicazione può scegliere di lavorare con buffer audio di dimensioni anche minime, tipo 32 o 64 frames. Nel caso, ad esempio, delle interfacce EgoSystem, che consentono frequenze di campionamento di 192 kHz, si raggiungono latenze dell’ordine del msec, a patto di non collassare la CPU e il meccanismo automatico di cache dei dati da parte del sistema operativo, che purtroppo risente molto del lavorare con buffers troppo piccoli.
Fig. 5 Il dialogo per la configurazione del driver CoreAudio di DSP-Quattro.
In figura viene riportato ad esempio il dialogo per la configurazione delle device CoreAudio di DSP-Quattro (www.dsp-quattro.com), un editor audio / host di plug-in VST e AudioUnit. Come potete notare, l’utente ha la completa facoltà di impostare tutti i parametri relativi agli ingressi ed uscite della device audio, quali frequenza di campionamento, bit/sample, formato. C’è da evidenziare ancora una volta che questo si riferisce a come il driver scriverà I dati sullo hardware audio, e non come DSP-Quattro scriverà I dati nel driver CoreAudio, il che avviene sempre con la massima precisione a 32 bits in floating point.
Conclusione
Dopo una fase iniziale di sperimentazione, MacOS X, dalla sua versione 10.2, è capace di gestire l’audio ed il MIDI in maniera egregia. Anche mancando, da parte di un’applicazione, quella caratteristica di assoluto controllo dell’hardware che hanno reso così attraente la piattaforma Apple Macintosh ai programmatori di applicativi audio e MIDI in tempo reale, è garantita in compenso una stabilità del sistema che di sicuro è gradita. Bisogna anche dire che I programmatori Apple hanno fatto un lavoro egregio ereditando e traducendo al meglio tutte quelle caratteristiche che sotto MacOS 8/9 erano sparpagliate fra i diversi ASIO, VST, Rewire, OMS, e compari.
Molta strada bisogna ancora fare, prima fra tutte in una direzione di distensione più politica che tecnica, affinché le nuove tecnologie siano di più chiaro utilizzo ed implementazione, prevaricando sugli interessi di parte che purtroppo ormai Apple/Emagic sta dimostrando. Come comuni mortali e piccole case produttrici, non ci resta che sperare, anche se molto si può fare per dimostrare i comuni interessi.
E, per finire, mi raccomando, non pretendete di utilizzare diverse interfacce MIDI multicanale insieme ad interfacce audio USB solo perchè MacOS X lo permette, e un Hub USB costa poco, per poi stupirvi se notate dei problemi di sincronia?.
morale, non dimenticate di usare il buon senso!
di Stefano Daino
Stefano Daino, responsabile del settore digital audio della i3 S.r.l. e del software DSPQuattro
© MidiWare srl
per gentile concessione