Con Daniele (audiodan) si discuteva della possibilità di implementare tecniche e strategie simili a quelle implementate dal "cMP²" utilizzando però software open-source su piattaforma Linux in luogo del sistema originale, che viceversa è tanto "chiuso" quanto indissolubilmente legato a windows XP.
La scelta di una (qualsiasi) piattaforma proprietaria e "chiusa" pone infatti non pochi limiti e problemi. A cominciare dal fatto che rende l'intero sistema una "black-box" che è praticamente del tutto "inconoscibile" o quasi, non potendosi di fatto conoscere i dettagli del funzionamento interno di OS, drivers, ecc.
Ulteriore problema è la rapida obsolescenza. Il sistema CICS/cMP² è nato con XP e con ogni probabilità morirà con esso, essendo praticamente impossibile adattarlo a versioni successive di windows (nella migliore delle ipotesi, ammesso che ciò sia tecnicamente possibile con i nuovi sistemi, occorrerebbe rifare tutto da capo. Senza alcuna certezza di riuscire a replicare i risultati della versione attuale). Dato che XP è già stato definitivamente abbandonato e non è più supportato, il problema è tutt'altro che ipotetico. Prevedibilmente, nel giro di poco tempo la mancanza di driver aggiornati renderà impossibile installare XP (e quindi cMP²) su nuovi hardware.
Di qui la necessità di cominciare a cercare possibili alternative, nonché l'opportunità che queste siano basate su software interamente Open-Source.
Lo scopo di questa introduzione è cercare di capire quale debba essere la "filosofia" da seguire per realizzare una architettura software alternativa che possa sostituire quella originale del cMP² mantenendone o se possibile migliorandone ulteriormente le prestazioni ottenibili all'ascolto. In un passo successivo si potrà poi valutare la possibilità di migliorare anche funzionalità, praticità, comodità d'uso, ecc, ove però ciò sia fattibile senza compromettere le prestazioni audio. Ma per il momento quest'ultimo è un aspetto del tutto secondario.
Ma facciamo un attimo un passo indietro. Cos'è questo fantomatico "cMP²"? In rete si trovano fiumi di documentazione, descrizioni, esperienze e discussioni infinite. Qualche esempio:
http://www.cicsmemoryplayer.com (il sito "ufficiale" dell'autore)
http://www.diyaudio.com/forums/pc-based ... -cmp2.html
http://www.diyaudio.com/forums/digital- ... -mods.html
http://www.nexthardware.com/forum/cmp-c ... ndice.html
Tra queste anche vari thread aperti da Daniele per descrivere le sue esperienze:
http://www.audiofaidate.org/forum/viewtopic.php?t=8447
http://www.audiofaidate.org/forum/viewtopic.php?t=8529
http://www.diyaudio.com/forums/pc-based ... audio.html
ecc.
Devo premettere che personalmente non ho avuto ne il tempo ne la voglia di sorbirmi la lettura di una simile mole di informazioni, caratterizzate oltretutto (come purtroppo oggi è ormai tipico, su Internet e non solo) da un pessimo "rapporto S/N". Di conseguenza la mia conoscenza di tale sistema è decisamente limitata e parziale. Quindi correggetemi se dovessi prendere degli abbagli.
(se qualcuno fosse a conoscenza di un documento in cui siano raccolte/riassunte in modo molto sintetico tutte le informazioni importanti e significative farebbe cosa gradita segnalandolo).
Una cosa che comunque non si può evitare di sottolineare subito è che il tutto (invero come molte altre cose in campo audio) è molto empirico e basato su ipotesi e "teorie" eterodosse che, oltre ad essere in gran parte prive di fondamenti e/o verifiche sperimentali che possano definirsi scientifici, per alcuni aspetti risultano a dir poco controverse.
In particolare ad es. i discorsi sulla minimizzazione della latenza (latency), che mi è parso di cogliere in vari interventi, da un punto di vista generale risultano addirittura contrari ad ogni logica tecnico/scientifica. Ammesso (e non concesso) che le strategie adottate in tal senso abbiano effettivamente portato ad un qualsiasi miglioramento reale, personalmente ritengo più verosimile che ciò sia imputabile a qualche "effetto collaterale" (probabilmente legato al sistema specifico e difficilmente generalizzabile) degli specifici accorgimenti implementati piuttosto che alla riduzione della latenza di per se stessa.
Ciò premesso, se non ho capito male, in sostanza l'idea di base del cMP² (se vogliamo ovvia e banale) è quella di ridurre quanto più possibile qualsiasi possibile fonte di "disturbo" che possa, in un modo o nell'altro, avere un qualsiasi effetto diretto od indiretto sul suono.
In particolare, si tenta di ridurre al massimo il rumore EM irradiato e condotto verso le parti più sensibili, quali in particolare la scheda audio ed il relativo clock. Questo non tanto (non solo) per eventuali problemi "diretti" di inquinamento del segnale analogico quanto (soprattutto) per problemi "indiretti" dovuti all'introduzione di jitter nel clock di conversione che tale rumore può provocare.
Nel cMP² ciò viene fatto agendo su due fronti:
Da una parte si cerca come ovvio di "isolare" quanto più possibile le parti sensibili da ogni possibile fonte di rumore, ad es. separando le varie alimentazioni, ecc.
Dall'altra si cerca invece di agire all'origine del problema, cercando di minimizzare "alla fonte" la quantità di rumore EM generato.
La strategia adottata per perseguire questo risultato è principalmente quella della riduzione dei consumi elettrici, della riduzione di tutte le attività dei vari sistemi al minimo indispensabile e dell'eliminazione di tutto ciò che è superfluo, secondo la logica:
meno consumi => correnti più basse => meno rumore
e
meno attività superflue => meno rumore inutile
Ciò viene realizzato agendo a tutti i livelli: hardware, "firmware" (BIOS) e software.
Vista in tale ottica l'idea non è poi così banale e non è affatto priva di senso. Tutt'altro.
Ma non divaghiamo oltre.
Da un punto di vista del software, che è quello che ci interessa in questa sede, la realizzazione di quanto sopra implica quindi che gli obbiettivi da perseguire sono:
- uso di risorse (memoria e cicli di CPU) ridotto al minimo indispensabile per svolgere la sola funzione desiderata: riprodurre musica.
- riduzione al minimo indispensabile di tutte le attività collaterali, di sistema e del kernel (context-switch, interrupt, attività dello scheduler, ecc).
- utilizzo delle sole periferiche indispensabili ed ove possibile disattivazione completa di qualsiasi periferica superflua che non sia stato possibile rimuovere completamente a livello hardware.
, la prova con audio la faccio appena posso. 
