www.audiofaidate.org

Il manuale di Sox dice che quando si fa upsampling se il livello originale è vicino al clip allora si incorre nella distorsione.
Su alcuni CD in effetti misuccedeva.
Ho aggiunto gain -3 prima di rate come mi suggerisce Paolo e il problema non si ripresenta

Ok, a titolo di esempio l'ho messo nell'ultimo script che ho postato. la riga di comando di sox è questa:

Grande lavoro, Unix!
ti posto qui sotto una serie di considerazioni di bibo, il cMP-man italiano:

"Ho dato un'occhiata al link...
Mettere in piedi un sistema simile per la riproduzione audio non e' complicatissimo.
Ma Clementine Music Player potrebbe andare gia' bene???

Sorgono pero' due problematiche: usabilita' e interfacciamento.

Usabilita':

* La gestione della libreria/database e' un aspetto essenziale - tipo JRiver, MusiCHI Suite,...
* Possibilita' di essere remotato, anche con un client tipo Android
* Facililita' di utilizzo sia nella libreria che nel player

Interfacciamento:

* Massima possibilita' d'interfacciamento con DAC attraverso schede int., FW e USB

A mio avviso questo e' un aspetto dolente. Le possibilita' di driver ALSA sono limitate, anche se ormai le schede S/PDIF contano poco.
Come stiamo messi sotto Linux con il riconoscimento automatico di periferiche USB Audio 2.0?"

Io mi riservo di intervenire non appena metto le mani nella marmellata, sperando che l'esistenza si scordi di me per qualche mese!
In compenso ho terminato il tweak dei russi su cMP2, con la cancellazione di enormi quantità di file, exe e chiavi di registro, con risultati incredibili!!
Dobbiamo lavorare ancora molto, la strada è lunga ma il digitale è uno strumento fantastico per ascoltare la musica.

audiodan ha scritto:Mettere in piedi un sistema simile per la riproduzione audio non e' complicatissimo.
Ma Clementine Music Player potrebbe andare gia' bene???

scusa ma... non capisco. Volete un sistema che segua la filosofia del "cMP²" (utilizzo dell'hardware ridotto al minimo indispensabile, preload in memoria per evitare accessi al disco, ecc) oppure una bella GUI piena di funzionalità più o meno (in)utili, grafica, lucette e bottoncini?

Per la seconda cosa va benissimo anche una Ubuntu desktop standard, tanto con "clementine" quanto anche con i suoi eccellenti player di default ("banshee" a partire dalla 11.04 oppure "rhythmbox" nelle versioni precedenti), con l'unica accortezza di configurare adeguatamente "PulseAudio" per fare l'upsampling desiderato (e.g. SRC-sync-best a 192K) oppure toglierlo di mezzo del tutto (disinstallando il pacchetto "pulseaudio") ed utilizzare direttamente ALSA (da configurare adeguatamente per mezzo del file ~/.asoundrc, che è quello che ho fatto sul tuo sistema).

In effetti, da oltre due anni a questa parte io uso normalmente proprio una configurazione del genere (niente pulseaudio o simili, upsampling con alsa o sox configurato via ~/.asoundrc, un player qualsiasi) e suona benissimo.

Ma una cosa simile non si può certo definire un sistema "simil-cMP²". Se poi all'ascolto ci siano o meno differenze percepibili tra le due opzioni non lo so' (non ho ancora avuto il tempo e la voglia per fare delle prove di ascolto approfondite in tal senso e d'altronde il mio hardware non segue in alcun modo i dettami di un sistema cMP², per cui la cosa non avrebbe neanche troppo senso).

In effetti, uno degli scopi principali del semplice setup di test proposto è proprio quello di verificare se/quanta differenza ci sia tra le varie opzioni minimaliste qui proposte nonché (soprattutto) tra queste ed un sistema "normale" (Linux desktop con un player qualsiasi). Last but not least, tra le diverse possibilità Linux-based ed il cMP² originale (ovviamente il tutto a parità di configurazione per quanto riguarda upsampling e hardware).

audiodan ha scritto:Sorgono pero' due problematiche: usabilita' e interfacciamento.

Usabilita':

* La gestione della libreria/database e' un aspetto essenziale - tipo JRiver, MusiCHI Suite,...
* Possibilita' di essere remotato, anche con un client tipo Android
* Facililita' di utilizzo sia nella libreria che nel player

come detto in precedenza, a questo si penserà in un secondo momento.

Prima si tratta di stabilire se/cosa/quanto le varie attività di sistema influiscano sulla qualità della riproduzione (il fatto che eventualmente ciò sia vero con sistemi windows NON significa necessariamente che lo stesso sia vero anche con Linux, che ha una architettura e caratteristiche completamente diverse).

Un'altra possibilità da esplorare, che secondo me può dare risultati ottimali senza dover creare nulla di nuovo (è già tutto sostanzialmente bello e pronto) è quella di usare MPD, che è perfetto allo scopo.

Un modo semplice per farlo è quello di provare ad utilizzare "Voyage MPD", che è un sistema già ottimizzato allo scopo. Istruzioni dettagliate sono già disponibili in rete.

Unica cosa che forse non è scritta nelle istruzioni di Voyage è come utilizzare sox per l'upsampling in luogo del resampler interno di MPD (che se non ricordo male usa "libsamplerate" con le sue varie opzioni, tra cui c'è anche l'algoritmo "SRC"). Per farlo (non ho ancora provato), direi che si tratta di configurare MPD per NON fare il resampling ma uscire invece attraverso una "pipe" che esegue sox (con le opzioni opportune).

In una ottica "xMP²", utilizzando (almeno) due sistemi separati (connessi via rete) si può anche implementare un sistema che dovrebbe essere sostanzialmente equivalente al "lMP-extreme.sh", senza però averne la scomodità ne i problemi.

L'architettura del sistema potrebbe essere grosso modo questa: Procedendo all'indietro, lo "stream receiver" ha la sola funzione di ricevere uno stream audio (già convertito alla risoluzione finale desiderata) e convertirlo nel segnale audio analogico.

Se si utilizza una interfaccia USB asincrona, lo stream receiver potrebbe essere costituito direttamente da tale interfaccia, nel qual caso il link indicato con (2) sarebbe quindi il link USB.

In alternativa, se ad es. si utilizza una scheda audio interna, lo "stream receiver" può essere un piccolo sistema dedicato (in cui è montata la scheda audio) ed il link (2) sarà su ethernet (LAN).

Il carico di CPU e le richieste di memoria di un tale sistema dedicato sono ridotte praticamente a zero. In sostanza tutto quello che deve fare è gestire un piccolo buffer FIFO. Si tratta quindi di un sistema embedded (e praticamente diskless, tranne eventualmente per una piccola memoria a stato solido, anche USB, da cui caricare il sistema e che non viene più utilizzata dopo l'avvio). Non serve neanche che abbia monitor o altre interfacce utente. Può essere realizzato anche utilizzando schede a bassissimo consumo pensate per sistemi embedded (non necessariamente con architettura Intel/PC-compatibile). Va bene qualsiasi cosa sia in grado di far girare un Linux minimale con i driver ALSA ed un qualche sistema per ricevere i dati via rete (forse anche un server custom minimalista fatto banalmente con "netcat" oppure uno dei vari sound server capaci di comunicare via rete, incluso lo stesso "pulseaudio").

A "monte" dello "stream receiver" c'è il sistema principale. Questo si occupa di accedere ai files audio, gestire in qualche modo l'interfaccia utente (nonché archivi, playlist e quant'altro) e preparare adeguatamente lo stream che sarà inviato allo "stream receiver" (già convertito con sox o altro alla risoluzione -fissa- desiderata in uscita).

Il sistema principale potrebbe essere realizzato con un server MPD, così da poter essere installato anche in luoghi diversi da quello dov'è l'impianto audio e permettere l'uso dei più disparati client remoti (MPD dispone di numerosi client che girano sui più disparati dispositivi inclusi palmari, smartphone, ecc oltre che ovviamente su computer di ogni genere e tipo).

In alternativa però può anche essere un normale sistema desktop configurato in modo da redirigere la propria uscita audio su un opportuno stream indirizzato al "receiver". In tal caso, la gestione di librerie, playlist, interfaccia utente e quant'altro sarà affidata ad uno qualunque degli innumerevoli player disponibili (ogni utente è libero di scegliere quello che preferisce).

In entrambi i casi il file server (l'archivio con la musica) può essere ospitato in un ulteriore sistema separato (e.g. un NAS) oppure più semplicemente i dischi con la musica possono essere connessi direttamente alla macchina principale.

Ma, torno a ripetere, parlare adesso di tutto ciò è a dir poco prematuro.

Provate prima il sistema minimale descritto in precedenza (nelle sue varie varianti) ed un sistema standard e valutatene potenzialità ed eventuali differenze da un punto di vista della qualità audio. A quel punto - possibilmente dopo aver raccolto un numero significativo di esperienze con sistemi audio diversi - potremo cominciare a ragionare su come procedere oltre. Discuterne prima non ha alcun senso.

audiodan ha scritto: Interfacciamento:

* Massima possibilita' d'interfacciamento con DAC attraverso schede int., FW e USB

da questo punto di vista il problema al solito sta' nella disponibilità dei produttori di hardware di supportare Linux, partecipando direttamente allo sviluppo dei driver o almeno mettendo a disposizione degli sviluppatori l'hardware e le specifiche tecniche necessarie. Cosa che purtroppo ben pochi fanno. La maggior parte dei driver sono stati sviluppati in proprio, in molti casi senza alcun supporto da parte dei produttori (dovendo ricorrere a tecniche di reverse-engineering).

Per quanto riguarda il FireWire, ci sono problemi ancora maggiori dovuti a clausole legali che in molti casi rendono impossibile lo sviluppo di driver open-source. In pratica, se volete usare Linux, scordatevi delle interfacce audio FW. Tranne qualche eccezione (potete verificare sul sito del progetto ALSA), in generale molte delle schede audio FW NON sono supportate ne mai lo saranno. Per fortuna, con l'avvento dello standard UAC2, ai nostri fini la cosa è diventata pressoché irrilevante.

audiodan ha scritto:Come stiamo messi sotto Linux con il riconoscimento automatico di periferiche USB Audio 2.0?"

ottimamente per tutte quelle che seguono il nuovo standard UAC2, che è supportato nativamente da tutti i kernel recenti (ad es. con una Ubuntu 11.04 le colleghi e funzionano, senza dover fare nulla). In generale male per quelle che invece utilizzano protocolli proprietari (come ad es. le m2tech), a meno che il produttore non fornisca il supporto necessario (*).

(*) NON è questo il caso di m2tech: Manunta ha più volte promesso che avrebbe rilasciato anche i driver per Linux, ma è dalla presentazione in anteprima della prima hiFace che numerosi utenti Linux stanno aspettando invano. Ed a quanto pare finora si è anche rifiutato di fornire le specifiche tecniche necessarie ad una eventuale implementazione indipendente da parte degli sviluppatori di ALSA. Trattandosi di un prodotto di nicchia, che oltretutto ha numerose alternative, tra cui anche la ottima (ed economica) "Audio-Widget", è altamente improbabile che qualcuno si prenda la briga di farne il reverse-engineering per poterla supportare (in altre parole: NON comprate interfacce m2tech!).

Edit. Aggiornamento: finalmente il driver Linux è stato rilasciato, per giunta Open-Source (inoltre, per i nuovi prodotti m2tech ha abbandonato il suo protocollo proprietario in favore dello standard UAC2). Decadono quindi tutte le remore e le controindicazioni che erano state espresse qui sopra.

Qualora il produttore non lo specifichi espressamente, per capire se una interfaccia funziona o meno con Linux ci si può riferire al supporto per Mac: se la scheda funziona nativamente (anche senza alcun driver aggiuntivo) sulle ultime versioni di MacOS/X, allora segue lo standard UAC2 e funziona nativamente anche con Linux.

questo se nello script lascio invece con plughw invece di hw
questo con plughw non dà problemi nemmeno se utilizzo -b 32. Qualche post sopra Paolo mi diceva che sul s/pdif non è possibileavere risoluzione a 32bit

Dov'è l'errore?

Tip:
suonando più di un file la risoluzione è sempre 16bit, non importa cosa è scritto nello script

vince ha scritto:questo se nello script lascio

Codice: Seleziona tutto

schedtool -a 0,1 -R -p 10 -e \
    sox -S -V --single-threaded --combine sequence "${playlist[@]}" \
    -t alsa -b 24 hw:0,1 \
    gain -3 rate -v -I -a 96000

Codice: Seleziona tutto

sox WARN alsa: can't encode 24-bit Signed Integer PCM

Output File    : 'hw:0,1' (alsa)
Channels       : 2
Sample Rate    : 96000
Precision      : 16-bit
Duration       : 00:05:01.49 = 28943360 samples ~ 22612 CDDA sectors
Sample Encoding: 32-bit Signed Integer PCM
Endian Type    : little

è un WARNing: ti dice che il tuo device non accetta dati codificati S24_LE, per cui sox usa invece automaticamente un formato a 32bit (S32_LE).

vince ha scritto:con plughw non dà problemi nemmeno se utilizzo -b 32. Qualche post sopra Paolo mi diceva che sul s/pdif non è possibileavere risoluzione a 32bit

Dov'è l'errore?

nessun errore: la differenza tra "plughw" ed "hw" sta' proprio nel fatto che "plug-" adatta (converte) automaticamente il formato in ingresso al "più vicino" formato supportato dall'hardware. In pratica, quello che prima faceva sox (dandoti il warning) in questo caso lo fa' automaticamente ALSA (senza dire nulla, perché l'interfaccia "plug-" serve proprio a quello).

Da quanto riporti, sembrerebbe che la tua scheda audio accetta solo formati a 16 o 32 bit, che poi probabilmente riconverte internamente (e "silenziosamente") a 24 bit prima di inviarli sull'uscita s/pdif.

Ma hai aggiornato il sistema? hai il nuovo sox? se adesso provi ad usare -b 32 direttamente su "hw:" (senza plug-) che ti dice?

vince ha scritto:suonando più di un file la risoluzione è sempre 16bit, non importa cosa è scritto nello script

questo non mi torna. Intendi dire più files con risoluzioni diverse, cioè un mix di files a 16 e 24 bit? Per "risoluzione" cosa intendi, "Precision" o "Encoding"?

N.B.: "Encoding" si riferisce al formato della codifica utilizzata, "Precision" ti dice invece quanti bit sono effettivamente utilizzati dal tuo stream.

UnixMan ha scritto:Ma hai aggiornato il sistema?

aggiornato Ubuntu 11.04

UnixMan ha scritto:hai il nuovo sox?

credo di si, dpkg -s sox mi dice
...
Version: 14.3.1-2ubuntu1
...

UnixMan ha scritto:se adesso provi ad usare -b 32 direttamente su "hw

questo:

UnixMan ha scritto: vince ha scritto:suonando più di un file la risoluzione è sempre 16bit, non importa cosa è scritto nello script


questo non mi torna. Intendi dire più files con risoluzioni diverse, cioè un mix di files a 16 e 24 bit? Per "risoluzione" cosa intendi, "Precision" o "Encoding"?

se do il comando
mymp.sh *.flac
cioè gli passo più di un file per volta (tutti flac a 16bit), ottengo invece che 32 come prima
Io la differenza tra Precision ed Encoding non l'ho ancora chiara e adesso vado a leggere qualcosa, ma non sono convinto che funzioni a dovere.
In definitiva il mio output che risoluzione ha? Posso arrivare a 24bit?
aplay-l diche che
card 0: NVidia [HDA NVidia], device 1: ALC662 rev1 Digital [ALC662 rev1 Digital]
se faccio una ricerca per ALC662 trovo che
The ALC662 supports 16/20/24-bit S/PDIF output function and a sampling rate of up to 96kHz

vince ha scritto:credo di si, dpkg -s sox mi dice
...
Version: 14.3.1-2ubuntu1

ok, è lo stesso che ho io. Vedo però che è uscita la versione 14.3.2, che a quanto pare risolve qualche bachetto: http://sox.git.sourceforge.net/git/gitw ... e53d6af46a

potrebbe valere la pena provare quello nuovo. Prova a vedere se lo trovi nei backports o in qualche ppa. Oppure, volendo puoi anche provare a farti il "backport" tu stesso.

N.B.: quanto segue è a puro scopo didattico: NON è assolutamente necessario farlo. Anche la versione di sox fornita di default dal sistema va' benissimo.

Tra l'altro, a brevissimo sarà rilasciata la Ubuntu 11.10, che fornisce proprio quella versione di sox... quindi volendo basta aspettare e poi aggiornare.

Istruzioni per fare il backport dei pacchetti di sox:

Aggiungi il repository dei sorgenti (deb-src ...) della prossima versione di Ubuntu (11.10 AKA "Oneiric Ocelot"; per sox ti serve la sezione "universe") e poi dai i seguenti comandi: se tutto fila liscio, questo ultimo comando ti installa tutte le dipendenze (tutti i pacchetti) necessari a fare il "build" del pacchetto (cioè a ricompilarlo dai sorgenti). Purtroppo, trattandosi del pacchetto di una distribuzione successiva alla tua, è abbastanza improbabile che tutto fili liscio.

In tal caso, dalla directory in cui ti trovi (/var/tmp/build/sox-14.3.2/) apri il file ./debian/control e modifica la lista delle "Build-Depends" eliminando tutte le indicazioni di versione laddove specificate e lasciando quindi solo i nomi dei pacchetti (le indicazioni di versione sono quelle tra parentesi tonde; N.B.: non lasciare spazi tra il nome del pacchetto e la virgola che eventualmente segue!). Dopo di che fai un "cut&paste" di quella lista ed installa tutti i pacchetti elencati (ovviamente insieme alle relative dipendenze, inclusi i "recommended"). Ad es., su Debian "Squeeze" dovresti dare il comando: (su Ubuntu potrebbe esserci qualche differenza su nome e numero dei pacchetti da installare).

A questo punto dovrebbe essere tutto pronto... assicurati di essere nella directory "radice" dei sorgenti del pacchetto (/var/tmp/build/sox-14.3.2/) e quindi avvia la compilazione: se tutto va' bene, dopo aver macinato un (bel) po', ti dovrebbe creare (dentro la directory parent, cioè in /var/tmp/build/) i files .deb relativi a tutti i pacchetti di sox. Se è così, non hai che da installarli: casomai ti dovesse dare degli errori per dipendenze mancanti, installa anche i pacchetti relativi (con aptitude). Et voilà, il gioco è fatto.

vince ha scritto:

UnixMan ha scritto:se adesso provi ad usare -b 32 direttamente su "hw

questo:

Codice: Seleziona tutto

Output File    : 'hw:0,1' (alsa)
Channels       : 2
Sample Rate    : 96000
Precision      : 16-bit
Duration       : 00:02:44.41 = 15783680 samples ~ 12331 CDDA sectors
Sample Encoding: 32-bit Signed Integer PCM

ok, quindi funziona.

vince ha scritto: se do il comando
mymp.sh *.flac
cioè gli passo più di un file per volta (tutti flac a 16bit), ottengo

Codice: Seleziona tutto

Sample Encoding: 16-bit FLAC

invece che 32 come prima

occhio: dove?

sox (con -V) ti fornisce separatamente le informazioni relative a tutti i file di ingresso (singolarmente, uno per volta se sono più di uno) ed al file (device) di uscita. Le informazioni relative a questo (cioè all'output) vengono presentate una sola volta (all'inizio, poi scorrono via). Sono ad es. queste: (nota che all'inizio dice per l'appunto "Output File : ... "). Non è che per caso tu guardavi al gruppo di info relative ad uno dei files di input anziché a quello di output?

vince ha scritto:Io la differenza tra Precision ed Encoding non l'ho ancora chiara e adesso vado a leggere qualcosa, ma non sono convinto che funzioni a dovere.

"precision" è il numero di bit effettivi: se usi materiale da CD (16/44.1), sempre 16 bit sono, a prescindere da come li codifichi.

"encoding" è il formato in cui sono rappresentati i campioni. Tipicamente può essere 16, 24 o 32 bit.

(nei device di uscita è raro veder usate codifiche a 24 bit: di norma si usano word da 16 o da 32bit).

Se e.g. ti dice che hai precision=16 ed encoding=32, vuol dire che stai usando parole da 32bit per rappresentare dei dati che in realtà di bit ne occupano solo 16 (ovvero hai 16 bit utilizzati ed il resto sono zeri).

Naturalmente, se encoding > precision potresti avere a disposizione un certo "headroom" che può essere utile per le elaborazioni, mentre se encoding=precision di spazio extra non ne hai e quindi qualsiasi operazione che comporti un overflow (o underflow) produrrà inevitabilmente una immediata perdita di informazione.

Se non vado errato (da verificare), l'informazione relativa alla "precision" che ti viene mostrata (relativamente al file di output) dovrebbe essere comunque precedente alle operazioni finali (nel nostro caso gain, rate e dither) ed è quindi sempre uguale a quella dello stream in ingresso.

vince ha scritto: In definitiva il mio output che risoluzione ha? Posso arrivare a 24bit?
aplay-l diche che
card 0: NVidia [HDA NVidia], device 1: ALC662 rev1 Digital [ALC662 rev1 Digital]
se faccio una ricerca per ALC662 trovo che
The ALC662 supports 16/20/24-bit S/PDIF output function and a sampling rate of up to 96kHz

direi di si. Ad occhio e croce, come accade per molte altre schede, anche la tua in ingresso supporta solo stream codificati a (encoding=) 16 oppure 32 bit. In un caso (16bit) li usa tutti così come sono mentre nel caso di stream a 32 bit di questi ne usa solo 24 (e butta gli altri, che si aspetta essere tutti zero).

N.B.: ovviamente, se parti da materiale a 16 bit la risoluzione effettiva resta comunque quella, non è che sox se la possa inventare...

Notizia-bomba: (Voyage MPD) «Fa paura. A mio parere un ulteriore passo avanti rispetto a Cmp2 sia dal punto di vista sonico (e non è un risultato da poco) sia dell'usabilità.»

UnixMan ha scritto:Notizia-bomba: (Voyage MPD) «Fa paura. A mio parere un ulteriore passo avanti rispetto a Cmp2 sia dal punto di vista sonico (e non è un risultato da poco) sia dell'usabilità.»

Wow! Sono diventato famoso!


Piacere, Michele, nonché il Miclaud di nexthardware e forum vari, nonché compaesano del mitico Echo. Mi fa piacere trovare questo gruppo di persone interessate (e anche assai competenti) al mondo di Linux applicato all'audio Hifi. Noto che c'è anche il prode Wasky, in giro a far danni!

UnixMan, sto leggendo con grande interesse i tuoi post! Sto attendendo con ansia una piattaforma Alix1d con la quale fare qualche esperimento malefico, e presto la metterò a confronto con il mio voyage su piattaforma Intel I3... non vedo l'ora! Maledetta neve che rallenta tutto...

Piacere di fare la vostra conoscenza

Ciao Michele, benvenuto su audiofaidate!

...e tienici informati sugli sviluppi!

Miclaud ha scritto:

UnixMan ha scritto:Notizia-bomba: (Voyage MPD) «Fa paura. A mio parere un ulteriore passo avanti rispetto a Cmp2 sia dal punto di vista sonico (e non è un risultato da poco) sia dell'usabilità.»

Wow! Sono diventato famoso!


Piacere, Michele, nonché il Miclaud di nexthardware e forum vari, nonché compaesano del mitico Echo. Mi fa piacere trovare questo gruppo di persone interessate (e anche assai competenti) al mondo di Linux applicato all'audio Hifi. Noto che c'è anche il prode Wasky, in giro a far danni!

UnixMan, sto leggendo con grande interesse i tuoi post! Sto attendendo con ansia una piattaforma Alix1d con la quale fare qualche esperimento malefico, e presto la metterò a confronto con il mio voyage su piattaforma Intel I3... non vedo l'ora! Maledetta neve che rallenta tutto...

Piacere di fare la vostra conoscenza

ciao benvenuto!!!!
....la alix1d mi intriga, se me lo dicevi prima ordinavo anche io

Echo ha scritto:
ciao benvenuto!!!!
....la alix1d mi intriga, se me lo dicevi prima ordinavo anche io

E' stato un acquisto di impulso

E comunque in questo modo potrò fare da "cavia"
Comincia a pensare su due alimentazioni lineari come si deve, una 12v per la mobo (consumo max 1.2A, in media 0.4) e una 3.3v per un'ipotetica Esi Juli@ (questa però va valutata in caso di modifiche alla Juli@, cmq il consumo max dovrebbe stare sui 0.13A).

Ti ho dato abbastanza compiti?

Ci vediamo quando il caos della neve sarà finito. Ho comprato la Alix 10 giorni fa e sono andato oggi a ritirarla di persona alla DHL... i corrieri sono comprensibilmente nel panico più totale!

UnixMan ha scritto: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.

Segue...

In generale tutto quanto detto mi sembra molto Windows Legacy ...

Sinceramente il mio approccio a questi "problemi" sarebbero molto diversi, intanto usare hardware tranquillo, un bel celeron di quelli che hanno il dissipatore alto 1 cm con un chipset intel ben supportato e senza troppi fronzoli, in quanto trovo inutile cercare di tranquillizzare un 8 core con una scheda grafica che monta un radiatore di rame grosso quanto un termosifone.

Seconda cosa gia' sperimentata da GM, gettare nell'immondizia l'alimentatore switching e costruire un'alimentatore completamente analogico, lui ha fatto complicati alimentatori basati su un trasformatore che lui definisce come "filtro ad amplificazione magnetica" (se qualcuno ne sa' piu' di me meglio, perche' su internet non si trova niente e le uniche cose che ho visto sono su un suo libro stampato alla fine degli anni 40).

Terza cosa trovo assolutamente inutile buttarsi su distribuzioni quali gentoo come letto nel post sotto, ricompilare tutto non porta a nessun miglioramento significativo per quanto ne dicano i sostenitori, e' sufficiente una distro abbastanza modulare per essere alleggerita facilmente dall'inutile, e se anche viene caricato qualche pacchetto un piu' non fa niente, sono una manciata di mega sul disco, con un buon editor per init basta disattivare tutti i servizi che non servono, quello che non e' caricato in memoria non da fastidio.

Ciao Paolo

ottimo post come al solito... conoscessi Unix/Linux come te sarei un ricco sistemista!!

Ho provato il tuo script (e tutte le sue varianti: ram e no ram, con e senza upsampling etc) sul mio sistema con la ESI Juli@ (non modificata) + Buffalo II DAC a trasformatori, e funziona ma onestamente non sento differenze con quanto facevo prima. Il che conferma la tua visione.

Prima suonavo i files usando Totem Movie Player che è l'unico player che fa esattamente quello che mi serve: vedo la playlist a destra, la Cover embedded nei flac a dimensione naturale, alsa configurato senza upsampling . Se non ho capito male Totem usa GStreamer.

L'unico motivo per il quale una persona puo' sentire la differenza tra diversi algorithmi di upsampling e quando il DAC lo fa *sbagliando* introducendo *compressione* di range dinamico soprattutto a bassi livelli... in quel caso conviene far fare l'upsampling a monte. Onestamente con le nuovi classi di DAC Delta-Sigma e tutto il software che gira elaborato e rielaborato, fritto e rifritto... non riesco proprio a credere come si possa sbagliare così clamorosamente.

Tornando al tuo player secondo te da Gnome sarebbe possibile fare in modo che cliccando su una cartella con il tasto destro, si apre il menu dal quale posso mandare in esecuzione il tuo script su tutti i files flac e wav?... sarebbe grandioso.

ciao
Piero

pico ha scritto:Ciao Paolo

ottimo post come al solito... conoscessi Unix/Linux come te sarei un ricco sistemista!!

Oppure a scrostare virus da macchine windows end user, in italia saper fare ormai non serve a niente.

pico ha scritto:Tornando al tuo player secondo te da Gnome sarebbe possibile fare in modo che cliccando su una cartella con il tasto destro, si apre il menu dal quale posso mandare in esecuzione il tuo script su tutti i files flac e wav?... sarebbe grandioso.

Con kde si fa tranquillamente.

GizMo ha scritto: Oppure a scrostare virus da macchine windows end user, in italia saper fare ormai non serve a niente.

... infatti immaginavo qualche figa città del nord europa!

A Londra un mio amico sistemista (secondo me nemmeno bravissimo ) prendeva 60 mila sterline all'anno lorde (circa 40 mila nette dalle quali pagare solo la previdenza integrativa). Adesso si è messo in proprio come free-consultatant, è specializzato in SQL e Oracle e prende 500 sterline al giorno... attualmente dichiara intorno ai 120 mila pounds lordi all'anno!

Ci sentiamo
Pietro

GizMo ha scritto:

pico ha scritto:Tornando al tuo player secondo te da Gnome sarebbe possibile fare in modo che cliccando su una cartella con il tasto destro, si apre il menu dal quale posso mandare in esecuzione il tuo script su tutti i files flac e wav?... sarebbe grandioso.

Con kde si fa tranquillamente.

ok ma io uso Gnome... non sonoriuscito a trovare niente online.

Piero

pico ha scritto:Tornando al tuo player secondo te da Gnome sarebbe possibile fare in modo che cliccando su una cartella con il tasto destro, si apre il menu dal quale posso mandare in esecuzione il tuo script su tutti i files flac e wav?... sarebbe grandioso.

non uso Gnome per cui non ti so' dire di preciso, ma penso proprio di si. Prova a cercare con Google come si fa a gestire le associazioni tra tipi di file ed azioni collegate, ad es.:

http://www.google.com/search?q=gnome+fi ... ssociation

Occhio alla versione di Gnome, il modo in cui le associazioni sono gestite potrebbe essere cambiato da una versione all'altra (specie tra le "major", i.e. tra Gnome 2.x e Gnome 3.x).


P.S.:

pico ha scritto:conoscessi Unix/Linux come te sarei un ricco sistemista!!

è quello che faccio... (ma sono tutt'altro che ricco).