www.audiofaidate.org

Parte I: Introduzione e premesse

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.

Segue...

Parte II: identificazione e verifica delle strategie

Prima di poter progettare una infrastruttura dedicata, quanto più possibile semplice e pratica da installare, configurare ed utilizzare, è necessario capire come tradurre i vaghi e generici obbiettivi identificati in precedenza in qualcosa di più concreto.

Un primo passo da fare in questa direzione penso sia quello di cercare di esplorare i limiti, partendo da un sistema ridotto all'osso, tanto minimale quanto "estremo", in cui tutti i concetti e le idee espresse in precedenza siano portate fino alle estreme conseguenze.

Un sistema siffatto ovviamente non può che essere estremamente spoglio, scomodo, con funzionalità ridotte a meno dell'essenziale. Assolutamente improponibile per un uso normale. Ma al tempo stesso perfetto per fare esperimenti in quanto fornisce un riferimento di partenza che riduce al minimo il (comunque enorme) numero di variabili in gioco.

Una volta che tale sistema sia stato ottimizzato e se ne siano stabilite le potenzialità si potrà poi cominciare a fare esperimenti per capire, un pezzettino alla volta, cosa si può fare sul sistema per renderlo più comodo, funzionale e "friendly" senza avere impatti negativi sul suono e cosa invece no.

Vediamo quindi come potrebbe essere realizzato un simile sistema "estremo".

Quello che ci serve è ben poco: il kernel, una shell, librerie e tools di base, l'infrastruttura user-space di ALSA, flac e sox (con i relativi plugin). Pochi MB di roba in tutto!

Una cosa del genere si potrebbe realizzare anche partendo da zero o, un po' più comodamente, sulla base di una distribuzione esistente. Probabilmente le più indicate allo scopo potrebbero essere "Arch", "Gentoo" o - forse ancora meglio - "Linux From Scratch". Ma la cosa rischierebbe di diventare piuttosto complicata per i non esperti.

La soluzione più semplice è allora quella di installare una distribuzione standard, ad es. la solita Ubuntu (ma praticamente qualsiasi altra va bene), avviandola in "single user mode" per i nostri esperimenti "estremi".

La modalità "single user", talvolta indicata anche come modalità di "ripristino" o "recovery" nel menù di avvio ("boot manager", oggi di solito GRUB) è un particolare modo di avviare il sistema (di norma utilizzato solo per particolari operazioni sul sistema, per lo più "di emergenza") che carica il kernel e prepara un ambiente minimale, senza avviare servizi o altro. Di solito si limita a montare i file system essenziali ed avviare una shell ("prompt dei comandi") in modalità testo come utente root.

Non c'è grafica, login, console virtuali... nulla. In genere neanche la rete. Solo qualcosa che a qualcuno potrebbe ricordare il vecchio "DOS" (ma solo a prima vista: persino così ridotto all'osso il sistema mantiene quasi tutte le sue potenzialità, multitasking compreso).

Questo sarà la base del nostro sistema minimale di test. In questo modo si ha già una infrastruttura completa e facile da usare per l'installazione del sistema e dei vari tools aggiuntivi (flac, sox, ecc). Dopo di che in qualsiasi momento basta un reboot per passare dal familiare ambiente desktop al sistema minimale e viceversa (in realtà, volendo non serve neanche un reboot completo: basta usare "telinit" per passare dal runlevel standard - di solito 2 su Debian e derivate, 5 su RH e parenti - al runlevel 1 e viceversa

).

OK, basta chiacchiere. Veniamo al sodo. Nei prossimi post le istruzioni dettagliate, passo per passo, su come cominciare a fare i primi test...

Operazioni preliminari

N.B.: non vi spaventate: la descrizione sarà lunga, ma solo perché è pensata anche per chi non abbia mai visto una linea di comando in vita sua. Tutte le operazioni sono descritte passo-passo in ogni dettaglio. Chiunque dovrebbe essere in grado di seguirle. Gli utenti più esperti mi scuseranno per la banalità.

Per prima cosa, se non ne avete già uno, installate il sistema. Conviene che sia una versione aggiornata. Di qui in avanti darò per scontato che si tratti di una Ubuntu 11.04 (ma anche per versioni e/o distribuzioni diverse purché non troppo vecchie non dovrebbe cambiare molto).

Con il sistema avviato normalmente, installate i pacchetti dei software che andremo ad utilizzare: flac, sox, "pmount" (che utilizzeremo per semplificare la gestione di eventuali HDD esterni od USB stick, ecc), mc (il "Midnight Commander", che può sempre tornare utile), ecc.

Per farlo assicuratevi di essere connessi alla rete, aprite un terminale (menù accessori->terminale) e quindi date i comandi:

Codice: Seleziona tutto

sudo apt-get update

Codice: Seleziona tutto

sudo apt-get install aptitude

(orrore e raccapriccio, l'ultima Ubuntu non installa più aptitude per default!)

Codice: Seleziona tutto

sudo aptitude install flac sox libsox-fmt-all pmount mc

e seguite le istruzioni. In alternativa, se preferite, potete fare la stessa cosa anche utilizzando l'apposita interfaccia grafica ("installazione applicazioni" o "gestione pacchetti" o qualcosa del genere, non ricordo. Al momento sono sulla mia Debian e non ho una Ubuntu sotto mano).

Fatto ciò, verificate di avere il comando "man" installato: ho scoperto con orrore e raccapriccio che alcune recenti distribuzioni "desktop-oriented" non lo installano più di default!

Dal terminale di cui sopra, provate a dare il comando:

Codice: Seleziona tutto

man sox

dovrebbe uscirvi il manuale di sox. Se invece vi dice "man: command not foud" (o qualcosa del genere in italiano se -orrore- avete configurato il sistema con la localizzazione italiana), installatelo:

Codice: Seleziona tutto

sudo aptitude install manpages man-db

a questo punto potete riavviare il PC, selezionando poi la "modalità di ripristino" (recovery, single user mode o comunque sia chiamata) dal menù del boot manager.

Vedrete partire il kernel, poi potrebbe esservi richiesto di inserire la password ed infine vi ritroverete davanti il prompt della shell.

Non ricordo se in tale shell vengano caricate le normali impostazioni di default. Nel dubbio, fatelo voi, dando il comando:

Codice: Seleziona tutto

. /etc/profile

(il comando è proprio ".", cioè "source", che dice alla shell di caricare il file indicato come argomento del comando, dopo lo spazio).

Ora verificate che i file system siano stati montati:

Codice: Seleziona tutto

df -h

dovrebe tornarvi una lista tipo questa:

Codice: Seleziona tutto

Filesystem            Size  Used Avail Use% Mounted on
/dev/sda2              19G   12G  6.7G  65% /
tmpfs                1004M   12K 1004M   1% /lib/init/rw
udev                  999M  288K  999M   1% /dev
tmpfs                1004M  112K 1004M   1% /dev/shm
/dev/sda4             880G  815G   66G  93% /home

potete anche controllare ad es. il contenuto delle home directory:

Codice: Seleziona tutto

ls -lahF /home/

Codice: Seleziona tutto

ls -lahF /home/username

(dove ovviamente "username" è il nome che avete utilizzato per il vostro utente).

se per caso i file system standard non dovessero essere stati montati, fatelo voi:

Codice: Seleziona tutto

mount -av

(questo comando monta automaticamente tutti i file system elencati nel file /etc/fstab)

A questo punto, se la vostra musica è su uno dei file system montati di default siete pronti per cominciare. Se invece si trova su un HDD esterno o una "pennetta" USB, vi manca ancora un passo. Collegate il vostro HDD esterno (o la pennetta) e date il comando:

Codice: Seleziona tutto

dmesg

vi scorrerà davanti un lungo elenco di messaggi del kernel. Tra questi, alla fine, ci dovrebbero essere quelli che riguardano il dispositivo che avete appena inserito. Qualcosa del genere:

Codice: Seleziona tutto

[69397.680038] usb 1-6: new high speed USB device number 5 using ehci_hcd
[69397.814516] usb 1-6: New USB device found, idVendor=0951, idProduct=1603
[69397.814522] usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[69397.814527] usb 1-6: Product: DataTraveler 2.0
[69397.814531] usb 1-6: Manufacturer: Kingston
[69397.814534] usb 1-6: SerialNumber: 200801250000000000000463
[69397.815467] scsi9 : usb-storage 1-6:1.0
[69398.816796] scsi 9:0:0:0: Direct-Access     Kingston DataTraveler 2.0 1.00 PQ: 0 ANSI: 2
[69398.856552] sd 9:0:0:0: Attached scsi generic sg2 type 0
[69398.857004] sd 9:0:0:0: [sdb] 15769600 512-byte logical blocks: (8.07 GB/7.51 GiB)
[69398.857647] sd 9:0:0:0: [sdb] Write Protect is off
[69398.857652] sd 9:0:0:0: [sdb] Mode Sense: 23 00 00 00
[69398.858280] sd 9:0:0:0: [sdb] No Caching mode page present
[69398.858287] sd 9:0:0:0: [sdb] Assuming drive cache: write through
[69398.864357] sd 9:0:0:0: [sdb] No Caching mode page present
[69398.864364] sd 9:0:0:0: [sdb] Assuming drive cache: write through
[69398.980322]  sdb: sdb1
[69398.982430] sd 9:0:0:0: [sdb] No Caching mode page present
[69398.982434] sd 9:0:0:0: [sdb] Assuming drive cache: write through
[69398.982437] sd 9:0:0:0: [sdb] Attached SCSI removable disk

quello che vi interessa sapere è il nome dei dispositivi (device files) che sono stati assegnati al vostro disco ed alle relative partizioni. In questo esempio, "sdb" (raw device del disco completo) ed "sdb1" (prima partizione primaria).

Tanto per saperlo, "sd" sta per "SCSI disk" (per ragioni storiche; oggi tutti i dischi sono identificati così), la lettera che segue (a, b, c, d, ecc) è un identificatore progressivo del disco mentre il numero successivo indica la partizione (se n<4 si tratta di una partizione primaria, da 5 in poi è una p. logica all'interno di quella primaria di tipo "estesa").

A questo punto, per poter utilizzare la vostra unità esterna dovete "montare" il file system. Niente di più facile. Date il comando:

Codice: Seleziona tutto

pmount -r /dev/sdb1

dove ovviamente in luogo di sdb1 dovete mettere il nome del device che avete appena scoperto con il comando precedente. Se il vostro disco esterno ha più di una partizione, ripetete il comando per tutte le partizioni cui avete bisogno di accedere.

Ciasun file system sarà "montato" in una directory con nome uguale a quello del device che sarà automaticamente creata (e poi rimossa quando smonterete il file system) sotto /media, ad es. /media/sdb1.

N.B.: ad evitarvi qualsiasi rischio di cancellare e/o modificare accidentalmente il contenuto del disco esterno, nel comando precedente ho aggiunto l'opzione "-r" (read-only), che monta il relativo file system in sola lettura. Se per qualche motivo avete bisogno di accedere anche in scrittura, omettete quella opzione.

Quando avete terminato di usare il disco, PRIMA di scollegarlo o spegnerlo dovete sempre "smontare" il relativo file system, con il comando:

Codice: Seleziona tutto

pumount /dev/sdb1

oppure:

Codice: Seleziona tutto

pumount /media/sdb1

(potete cioè specificare indifferentemente il device od il "mount-point"). Ovviamente, al solito al posto di sdb1 ci va' il nome del device che avete montato prima.

OK, ci siamo quasi. Non ci resta che individuare la scheda audio:

Codice: Seleziona tutto

aplay -l

dovrebbe rispondere con qualcosa del genere:

Codice: Seleziona tutto

**** List of PLAYBACK Hardware Devices ****
card 0: Intel [HDA Intel], device 0: STAC92xx Analog [STAC92xx Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: Intel [HDA Intel], device 1: STAC92xx Digital [STAC92xx Digital]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: Juli [ESI Juli@], device 0: ICE1724 [ICE1724]
  Subdevices: 0/1
  Subdevice #0: subdevice #0
card 1: Juli [ESI Juli@], device 1: ICE1724 IEC958 [ICE1724 IEC958]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

da cui si deduce che, se ad es. volessimo utilizzare l'uscita analogica della mia Juli@, dovremmo utilizzare il device ALSA "hw:1,0" (cioè card 1, device 0) oppure "plughw:1,0" casomai servisse una conversione automatica di formato.

Per controllare la scheda audio, il comando da usare è "alsamixer" (tasto "Esc" per uscire). Se, come nel mio caso, c'è più di una scheda audio e quella che ci interessa controllare non è la prima, aggiungeremo l'opzione "-c" (card) seguita dal numero della scheda ottenuto prima. Ad esempio:

Codice: Seleziona tutto

alsamixer -c1

per maggiori informazioni sull'uso di alsamixer, date il comando:

Codice: Seleziona tutto

man alsamixer

(premete "q" per uscire)

Fin qui le operazioni preliminari. Ora, prima di cominciare finalmente a far suonare qualcosa, qualche indicazione generale di base per i meno esperti.

Per navigare il file-system ("spostarvi" da una cartella ad un'altra), il comando è "cd" (change directory). Potete procedere un passo alla volta oppure specificare direttamente il percorso (path) completo. E naturalmente potete utilizzare percorsi "assoluti" (che partono dalla radice, "/") oppure relativi (che partono dalla directory corrente).

Ad es.:

cd MyMusic

vi porta nella cartella "MyMusic" che si trova all'interno della directory corrente;

cd /media/sdb1/music

vi porta direttamente alla cartella "music" che si trova dentro "sdb1", che a sua volta è contenuta in "media" che infine è contenuta all'interno della "radice";

cd pippo/pluto

vi porta nella directory pluto che è contenuta in quella pippo che è contenuta nella directory corrente.

ecc.

La sintassi è simile a quella di DOS/Windows ma, a differenza di questi, il carattere (separatore) che indica le directories (cartelle) non è il backslash, "\" ma lo slash "/" (perché mai per il DOS abbiano scelto i usare "\" quando praticamente tutti prima di loro già usavano "/" è un mistero...).

Altra differenza importante da tenere a mente per chi è abituato a DOS/Windows è che Unix è CASE SENSITIVE, in tutto e per tutto: maiuscole e minuscole contano, ovunque!

Ad esempio, /media/sdb1/music è una cartella DIVERSA da /media/sdb1/Music (e, in un file system Unix, possono esistere entrambe contemporaneamente!).

Esistono alcune scorciatoie:

cd (senza nessun path specificato) riporta direttamente alla home directory dell'utente
cd - porta alla directory precedente (che non è necessariamente la parent)
cd .. porta alla directory superiore (parent) (come in DOS/windows)
cd / (ovviamente) porta alla directory radice (root)

nel dubbio, il comando "pwd" vi restituisce la "Present Working Directory", cioè la cartella "in cui" vi trovate.

Per ottenere la lista dei files contenuti in una cartella, il comando è "ls" (abbreviazione di "List fileS", eq. del comando "dir" di DOS/Windows).

Potete darlo senza opzioni ne argomenti per ottenere una lista breve (su più colonne) dei files contenuti nella directory corrente oppure specificare come argomento il percorso (relativo od assoluto) della cartella di cui volete conoscere il contenuto. Potete inoltre utilizzare varie opzioni per modificare il formato di visualizzazione, nonché per abilitare la visualizzazione dei files "nascosti" (in Unix tutti e soli quelli il cui nome comincia per ".").

per maggiori info, come ormai dovreste aver capito, al solito date il comando:

Codice: Seleziona tutto

man ls

Segue...

Ancora qualche ultimo consiglio prima di cominciare a fare sul serio.

La shell di default di Linux (bash) supporta varie, comodissime agevolazioni per velocizzare l'inserimento dei comandi, che è bene conoscere ed utilizzare.

Per prima cosa, la linea di comando è editabile: potete spostarvi avanti ed indietro (senza cancellare) con i tasti freccia e modificare a piacimento il comando.

È possibile utilizzare i tasti "Home" (inizio) ed "End" (fine) oppure le combinazioni Ctrl-a e Ctrl-e per spostarsi all'inizio ed alla fine della riga.

La combinazione Ctrl-k esegue la funzione "cut" (taglia) dalla posizione del cursore fino alla fine della riga (quindi, se il cursore è ad inizio riga, viene cancellata e memorizzata l'intera riga). La combinazione Ctrl-y esegue invece il "paste" (incolla), sempre a partire dalla attuale posizione del cursore.

Tutti i comandi che date sono registrati nella "history" e possono essere richiamati (tutti, non solo l'ultimo) in ordine inverso premendo una o più volte il tasto freccia in sù. Una volta richiamati, i vecchi comandi possono essere modificati a piacimento prima di eseguirli. Il comando "history" vi mostra la lista di tutti i comandi memorizzati fino a quel momento.

Esiste inoltre una comoda funzione di ricerca nella history dei comandi: premendo la combinazione "Ctrl-r" seguita da una stringa (una parte qualsiasi di un comando precedente) il sistema richiama dalla history i comandi precedenti che contengono quella stringa. Al solito è possibile editare il comando prima di eseguirlo, oppure annullare tutto premendo il tasto "Esc".

In tutti i casi, i comandi sono eseguiti solo quando premete il taso "Invio" (indicato anche come "Enter" o "Return", a seconda delle tastiere). Questo può essere premuto con il medesimo effetto a prescindere dalla posizione del cursore. Non è necessario spostarsi a fine riga prima di eseguire il comando.

Un'altra funzione utilissima e comodissima, che vi raccomando di usare sempre (anche perché aiuta ad evitare noiosi errori) è il completamento automatico dei comandi e dei parametri. Una sorta di "T9" intelligente.

Se state scrivendo un comando e premete il tasto "Tab" (tabulatore), il sistema cercherà di completare automaticamente per voi il comando. Ad esempio, se scrivete "alsam" e premete "Tab", il sistema lo completerà in "alsamixer". Nel caso ci sia più di un comando che comincia con i caratteri che avete inserito, premendo più volte "Tab" il sistema vi mostrerà tutte le possibilità. Se ad es. scrivete "als", al primo colpo di Tab il sistema aggiungerà una "a"; se a questo punto premete ancora Tab, due volte in rapida successione, vedrete la lista dei possibili comandi che cominciano per "alsa".

N.B.: occhio a non dare comandi a casaccio! Unix/Linux si aspetta che voi sappiate esattamente ciò che state facendo e non fa' mai assolutamente NULLA per impedirvi di fare stupidaggini!

Se invece anche premendo più volte Tab non succede nulla, significa che non esiste nessun comando che comincia con quello che avete scritto.

Funzione ancora più comoda ed utile dell'auto-completamento riguarda gli "argomenti" dei comandi, in particolare files e directories.

Se ad esempio volete vedere la lista dei files contenuti in una cartella il cui percorso comprende cartelle dai nomi lunghi e complessi, ad es.:

ls "/media/sdb1/musica/autori preferiti/Ludwig W. Beethoven/Sinfonia N.9 diretta da blah blah blah/"

anziché scrivere tutto a mano (con il grosso rischio di sbagliare...) conviene fare come segue. Cominciate a scrivere :

ls /me<Tab> -> ls /media/

("<Tab>" significa premo il tasto Tab; "->" indica ciò che mi appare in risposta)

a questo punto aggiungo "sdb1/m" e premo di nuovo Tab; se dentro /media/sdb1/ non ci sono altre dir che cominciano per 'm', mi appare subito:

ls /media/sdb1/musica/

ora aggiungo 'a' e premo ancora Tab -> viene fuori:

ls /media/sdb1/musica/autori\ preferiti/

e così via.

Detto così sembra lungo ma, in pratica, con questo sistema, premendo pochi tasti si possono scrivere "percorsi" lunghissimi e complessi in un attimo. E soprattutto senza correre il rischio di sbagliare.

Oh, da notare la gestione degli spazi (e di altri caratteri speciali) all'interno dei nomi di files e directories!

In Unix, il carattere "\" (backslash) è spesso usato come carattere di "escape", che fa perdere il significato speciale al carattere che segue. Quindi, per inserire un carattere che ha un significato speciale per la shell (spazi, parentesi, ":", ";" ",", "&", "%", ecc) evitando che questo venga interpretato come tale questo va preceduto da un "\". Compreso il "\" stesso (se ne mettono due, "\\").

Un altro modo (in genere più comodo) per ottenere lo stesso risultato è quello di "quotare" (scrivere tra apici) la stringa che contiene gli spazi e/o i caratteri speciali, così come ho fatto all'inizio di questo esempio.

Segue...

Dimenticavo: al solito, per maggiori info c'è sempre "man". In questo caso:

Codice: Seleziona tutto

man bash

Arrivati a questo punto, possiamo finalmente cominciare a far suonare qualcosa!

Primo test veloce: spostatevi in una cartella che contiene dei files con la musica:

cd /media/sdXn/mia/dir/con/file/musicali/

e date il comando:

Codice: Seleziona tutto

AUDIODEV=hw:0,1 play -V *.flac

Ovviamente, in luogo di "hw:0,1" mettere il device ALSA corrispondente alla vostra scheda che avevate individuato in precedenza (con il comando alsa -l).

Con un po' di fortuna, se non avete fatto errori a questo punto dovreste cominciare a sentir suonare il sistema!

Usate Ctrl-c per saltare al file successivo; due volte di seguito per uscire.

(al solito, per maggiori dettagli date "man play" -- che, come scoprirete, in realtà non è che un "alter ego" di sox).

Con il comando precedente non avete fatto altro che decomprimere il file audio ed inviarlo alla scheda audio. Se la scheda audio è in grado di accettarne il formato nativo, i dati sono copiati "as-is", senza essere processati in alcun modo ("bit-perfect").

Ma siamo ancora lontani dall'obbiettivo che ci eravamo prefissi.

Cominciamo con aggiungere l'upsampling in software. Facile, basta usare questo comando in luogo del precedente:

Codice: Seleziona tutto

sox --single-threaded --combine sequence -V3 *.flac -t alsa hw:1,0 rate -v -I -a 192000

(al solito, sostituite il vostro device in luogo di "hw:1,0").

Qui potete già sbizzarrirvi a giocare con le (innumerevoli...) opzioni di sox per trovare il setting che vi piace di più.

Ma, un attimo... non avevamo detto "Memory Player"? e di minimizzare le operazioni effettuate dal sistema durante il playback?

ok, facciamo un altro passo avanti. Facile anche questo (ma qui la faccenda diventa veramente poco pratica). Anziché leggere il file direttamente dal disco ove si trova, prima di riprodurlo lo copiamo su un RAM-disk (un disco virtuale in memoria).

Questo è quel che si dice (veramente) un "memory player": mentre suona legge solo dalla RAM, in linea di principio il disco lo si potrebbe perfino "smontare" (pumount) e staccare fisicamente (non che cambi qualcosa).

Visto che ci siamo, nel copiare i files tanto vale anche decomprimerli, così ci risparmiamo anche un po' di CPU durante il playback.

Il RAM-disk ce l'abbiamo già: nei sistemi Linux recenti ce n'è uno montato di default sotto /dev/shm/ ("shm" sta per "SHared Memory"). In caso di dubbi, potete verificarlo con il comando:

Codice: Seleziona tutto

mount | grep shm

che dovrebbe ritornare qualcosa del genere:

Codice: Seleziona tutto

tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)

Quindi, anche stavolta niente altro che una semplice linea di comando da copiare ed eseguire:

Codice: Seleziona tutto

rm -vf /dev/shm/*.wav ; flac -d --output-prefix=/dev/shm/  *.flac && sox --single-threaded --combine sequence -V3 /dev/shm/*.wav  -t alsa hw:1,0 rate -v -I -a 192000

beh, in effetti stavolta sono tre comandi in uno:

Codice: Seleziona tutto

rm -v /dev/shm/*.wav

che cancella tutti i ile .wav che siano eventualmente rimasti nel RAM-disk;

Codice: Seleziona tutto

flac -d --output-prefix=/dev/shm/  *.flac

che decoprime i files flac in wav direttamente nel RAM disk ed infine

Codice: Seleziona tutto

sox --single-threaded --combine sequence -V3 /dev/shm/*.wav  -t alsa hw:1,0 rate -v -I -a 192000

che è sostanzialmente lo stesso comando di prima, solo che invece di leggere direttamente i flac dalla dir corrente gli facciamo leggere i wav dal RAM disk.

Tanto per completezza, vi dico anche che il separatore ";" significa esegui in sequenza mentre "&&" significa "AND" (logico), cioè esegui il primo comando e, se questo termina senza errori, esegui anche l'altro.

Per comodità, potete anche salvare quel comando in uno shell script (più o meno l'equivalente di un .BAT in DOS/windows, solo molto più versatile e potente).

Aprite un editor di testo (ovviamente potete farlo anche dal sistema completo, con l'interfaccia grafica, ad es. utilizzando gedit; altrimenti potete usare e.g. "nano" dal sistema minimale) ed in un nuovo file scrivete esattamente quanto segue:

Codice: Seleziona tutto

#!/bin/sh
rm -vf /dev/shm/*.wav 
flac -d --output-prefix=/dev/shm/ $1 && \
sox --single-threaded --combine sequence -V3 \
/dev/shm/*.wav  \
-t alsa hw:1,0 \
rate -v -I -a 192000

N.B.: Attenzione: NON ci devono assolutamente essere spazi dopo i "\" a fine riga!!!

Salvate il file con un nome tipo "mymp.sh" (ma potete chiamarlo come vi pare) e quindi date i comandi:

Codice: Seleziona tutto

chmod +x mymp.sh

per rendere eseguibile il file e

Codice: Seleziona tutto

sudo mv mymp.sh /usr/local/bin/

per spostarlo in una directory appropriata, che è nel default PATH.

Et voilà. Il vostro "linux memory player" (test edition) è pronto.

Ora per usarlo non avete altro da fare che spostarvi in una dir dove avete dei file flac da suonare (che non siano troppi o troppo grandi...) e dare semplicemente il comando:

mymp.sh *.flac

oppure, se ne volete selezionare solo alcuni, usate con fantasia i metacaratteri della shell. Ad es., in questo modo:

mymp.sh 0[12]*.flac

selezionate solo i file che cominciano per "01" e "02"; così invece:

mymp.sh [2-7]*.flac

solo quelli che cominciano con un numero da 2 a 7 (compresi); così:

mymp.sh *Mozart*.flac

solo quelli il cui nome contiene la stringa "Mozart", ecc.

Happy testing!

wow
ottima guida

vince ha scritto:wow
ottima guida

grazie!

però non siete attenti!

nell'ultimo post c'è una stupidaggine colossale. Non si tratta di un banale errore di sintassi, ma di una stupidaggine logica!

La pagliuzza e la trave

ovvero: ma come, mi preoccupo di risparmiare i pochi cicli di clock necessari a decomprimere il flac e non al carico molto più pesante necessario a fare l'upsampling?!

Se "MP" deve essere, ovviamente conviene fare l'upsampling "offline" al momento della scompattazione nel RAM-disk di modo che durante il playback l'unica cosa che resta da fare è semplicemente copiare i dati dal RAM-disk alla scheda!

Questo si può fare banalmente utilizzando direttamente sox per leggere il file dal HDD, decomprimerlo, farne l'upsampling e salvarlo come wav sul RAM-disk, già in formato 24/192 (o 32/192, a seconda di quale/i formati sono direttamente supportati dalla scheda audio).

Andiamo quindi a riscrivere un nuovo script:

Codice: Seleziona tutto

#!/bin/sh

# ripulisco il RAM-disk da eventuali files vecchi
#
rm -vf /dev/shm/*.wav 

# converto i file audio in wav e ne faccio l'upsampling, salvandoli direttamente nel RAM-disk
#
for file in "$@"; do 
   sox -V3 -S -G  "$file" -b 32 /dev/shm/"$file".wav  rate -v -I -a 192000
done

# verifico che ci siano files wav nel RAM-disk e se ci sono li faccio suonare
#
[ -f /dev/shm/*.wav ] && AUDIODEV=hw:1,0 play -V3 /dev/shm/*.wav

tra l'altro, con questo script c'è anche il vantaggio che si possono usare non solo i flac ma qualsiasi formato supportato da SOX (vedi: "man soxformat" per maggiori info).

L'opzione "-b 32" prima del file di output nella linea di comando di SOX genera un file di output codificato con risoluzione (AKA bit-depth o word-length) di 32 bit, mentre se si specifica "-b 24" si ottiene una bit-depth di 24 bit. Omettendo completamente l'opzione "-b" il file di output mantiene la bit-depth "originale" (caso per caso, quella del file in ingresso). Probabilmente, in unione all'upsampling è conveniente utilizzare "-b 24" o "-b 32". Da provare se ci sono differenze tra le due possibilità.

N.B.: questo non ha nulla a che vedere con il formato utilizzato internamente da SOX, che è sempre a 32 bit (IIRC). In teoria, quindi, se la scheda e (soprattutto!) il relativo DAC supportano stream a 32bit, potrebbe essere conveniente uscire a 32bit. Altrimenti potrebbe essere meglio uscire a 24bit (con dithering automatico se necessario).

L'opzione "-G" ("guard") invoca automaticamente la funzione "gain" per prevenire il clipping. Da provare se va' meglio con o senza.

Ovviamente, c'è da giocare un bel po' con le opzioni di resampling...

Dalla man page di SOX:

Codice: Seleziona tutto

     rate [-q|-l|-m|-h|-v] [override-options] RATE[k]
              Change the audio sampling rate (i.e. resample the audio) to any given RATE (even non-integer if this is supported by the output file format) using a quality level defined as follows:

-v == very high quality, band 95%, Rej. dB 175

Codice: Seleziona tutto

where Band-width is the percentage of the audio frequency band that is preserved and Rej dB is the level of noise rejection.  Increasing levels of resampling quality come at the expense of increasing amounts of time to process the audio.  If no quality option is given, the quality level used is `high'.

The `quick' algorithm uses cubic interpolation; all others use band-limited interpolation. By  default,  all  algorithms  have a `linear'  phase response; for `medium', `high' and `very high', the phase response is configurable (see below).

The rate effect is invoked automatically if SoX's -r option specifies a rate that is different to that of the input file(s).  Alternatively, if this effect is given explicitly, then SoX's -r option need not be given.  For example, the following two commands are equivalent:
  sox input.wav -r 48k output.wav bass -3
  sox input.wav        output.wav bass -3 rate 48k
though the second command is more flexible as it allows rate options to be given, and allows the effects to be ordered arbitrarily.

                                                                              *        *        *

Warning: technically detailed discussion follows.

The simple quality selection described above provides settings that satisfy the needs of the vast majority of resampling tasks.  Occasionally, however, it  may  be desirable to fine-tune the resampler's filter response; this can be achieved using override options, as detailed in the following table:

-M/-I/-L      Phase response = minimum/intermediate/linear
-s                Steep filter (band-width = 99%)
-a               Allow aliasing/imaging above the pass-band
-b 74-99.7   Any band-width %
-p 0-100      Any phase response (0 = minimum, 25 = intermediate, 50 = linear, 100 = maximum)

N.B.  Override options can not be used with the `quick' or `low' quality algorithms.

All resamplers use filters that can sometimes create `echo' (a.k.a. `ringing') artefacts with transient signals such as those that occur with `finger snaps' or other highly percussive sounds.  Such artefacts are much more noticeable to the human ear if they occur before  the  transient (`pre-echo')  than if they occur after it (`post-echo').  Note that frequency of any such artefacts is related to the smaller of the original and new sampling rates but that if this is at least 44.1kHz, then the artefacts will lie outside the range of human hearing.

A phase response setting may be used to control the distribution of any transient echo between `pre' and `post': with minimum  phase,  there is no pre-echo but the longest post-echo;  with linear phase, pre and post echo are in equal amounts (in signal terms, but not audibility terms); the intermediate phase setting attempts to find the best compromise by selecting a small length (and level) of pre-echo and a medium lengthed post-echo.

Minimum, intermediate, or linear phase response is selected using the -M, -I, or -L option; a custom phase response  can  be  created  with the  -p option.  Note that phase responses between `linear' and `maximum' (greater than 50) are rarely useful.

A  resampler's  band-width setting determines how much of the frequency content of the original signal (w.r.t. the original sample rate when up-sampling, or the new sample rate when down-sampling) is preserved during conversion.  The term `pass-band' is used to refer to all frequencies  up  to the  band-width  point  (e.g. for 44.1kHz sampling rate, and a resampling band-width of 95%, the pass-band represents frequencies from 0Hz (D.C.) to circa 21kHz).  Increasing the resampler's band-width results in a slower conversion and can increase transient echo artefacts (and vice versa).

The -s `steep filter' option changes resampling band-width from the default 95% (based on the 3dB point), to 99%.  The -b option  allows  the  band-width to be set to any value in the range 74-99.7 %, but note that band-width values greater than 99% are not recommended for normal use as they can cause excessive transient echo.

If the -a option is given, then aliasing/imaging above the pass-band is allowed.  For example, with 44.1kHz sampling rate, and  a  resampling  band-width  of  95%,  this means that frequency content above 21kHz can be distorted; however, since this is above the pass-band (i.e.  above the highest frequency of interest/audibility), this may not be a problem.  The benefits of allowing aliasing/imaging are reduced processing  time,  and  reduced (by almost half) transient echo artefacts.  Note that if this option is given, then the minimum band-width allowable with -b increases to 85%.

Examples:
  sox input.wav -b 16 output.wav rate -s -a 44100 dither -s
  default (high) quality resampling; overrides: steep filter, allow aliasing; to 44.1kHz sample rate; noise-shaped dither to 16-bit WAV file.

  sox input.wav -b 24 output.aiff rate -v -I -b 90 48k
  very high quality resampling; overrides: intermediate phase, band-width 90%; to 48k sample rate; store output to 24-bit AIFF file.

Possibile ulteriore improvement: utilizzare lo scheduling real-time per il processo che esegue il play.

Per farlo, installate il pacchetto "schedtool":

Codice: Seleziona tutto

sudo aptitude install schedtool

quindi aggiungete ad es. il comando:

Codice: Seleziona tutto

schedtool -a 0,1 -n -10 -R -p 10 -e

davanti al comando che esegue il play. Ad es., l'ultimo script potrebbe essere riscritto così:

Codice: Seleziona tutto

#!/bin/sh

# ripulisco il RAM-disk da eventuali files vecchi
#
rm -vf /dev/shm/*.wav 

# converto i file audio in wav e ne faccio l'upsampling, salvandoli direttamente nel RAM-disk
#
for file in "$@"; do 
   sox -V3 -S -G  "$file" -b 32 /dev/shm/"$file".wav  rate -v -I -a 192000
done

# verifico che ci siano files wav nel RAM-disk e se ci sono li faccio suonare
#
if [ -f /dev/shm/*.wav ] then 
   export AUDIODEV=hw:1,0 
   schedtool -a 0,1 -R -p 10 -e  play -V3 /dev/shm/*.wav
fi

al solito, leggetevi la man page di schedtool:

Codice: Seleziona tutto

man schedtool

Casomai il suo uso dovesse avere un qualche effetto (ne dubito, ma non si sa' mai), anche con le opzioni di questo c'è da giocare parecchio...

Finora, non abbiamo toccato il sistema standard. Se uno volesse fare il gioco duro, poi potrebbe divertirsi praticamente all'infinito con le configurazioni del kernel e le relative patch. Ma non è un gioco da novellini... se siete in grado di farlo, non avete bisogno delle mie istruzioni.

P.S.: ovviamente, anche per l'ultima versione non è necessario utilizzare uno script; se preferite anche questo può essere scritto in forma compatta direttamente come un'unica riga di comando:

Codice: Seleziona tutto

rm -vf /dev/shm/*.wav ; for file in *.flac ; do sox -V3 -S -G  "$file" -b 32 /dev/shm/"$file".wav  rate -v -I -a 192000 ; done ; export AUDIODEV=hw:1,0 ; [ -f /dev/shm/*.wav ] && schedtool -a 0,1 -R -p 10 -e play -V3 /dev/shm/*.wav

...ma in questo caso lo script è decisamente più leggibile!

grande, molto interessante!
Proprio ieri ho dedicato un po' di tempo a sox.

Facciamo un attimo un passo indietro.

Quella adottata nello script precedente costituisce senza dubbio la soluzione più "estrema", dato che durante la riproduzione l'attività del sistema è ridotta praticamente a zero.

Ma, per contro (come sicuramente non avrete potuto fare a meno di notare se lo avete provato!) sfortunatamente è praticamente inutilizzabile per via del tempo necessario a fare il resampling prima di cominciare a suonare qualsiasi cosa! (latenza... misurabile in minuti!).

A quanto mi dicono il cMP utilizza invece una soluzione molto meno drastica (e non potrebbe essere diversamente...), limitandosi a copiare in RAM i files originali ed eseguendo poi tutte le altre operazioni (decompressione ed upsampling) "online", durante la riproduzione.

Questo aumenta sensibilmente il carico del sistema durante la riproduzione ma limita la "latenza" (il ritardo iniziale tra quando gli dite di suonare un file a quando comincia a farlo) al solo tempo necessario a copiare i files dal HDD al RAM-disk. Cosa che di norma causa un ritardo iniziale ancora accettabile.

Di seguito, eccovi uno script che si comporta esattamente allo stesso modo del cMP:

Codice: Seleziona tutto

#!/bin/bash

# copio i file audio indicati in riga di comando nel RAM-disk
#
declare -a playlist
i=1
for file in "$@"; do
   cp -v "$file"  /dev/shm/
   playlist[$i]="/dev/shm/`basename "$file"`"
   let i++
done

# avvio la riproduzione (con upsampling "online")
#
schedtool -a 0,1 -R -p 10 -e \
sox -S -V --single-threaded --combine sequence "${playlist[@]}" \
 -t alsa -b 32 hw:0,0 \
 gain -3 \
 rate -v -I -a 192000

# ripulisco il RAM-disk
#
rm -vf "${playlist[@]}"

vi conviene salvare questo script con un nome diverso da quello precedente. Ad es. potete chiamare "lMP.sh" questo ed "lMP-extreme.sh" il precedente.

Dopo di che, potete divertirvi a confrontare i risultati all'ascolto. Se non trovate differenze udibili tra le due versioni (o se queste sono minime), siamo fortunati e possiamo procedere così.

In caso contrario, se volete approfittare della eventuale qualità extra, l'unica soluzione "pratica" (meno scomoda...) sarebbe quella di tenersi una (ulteriore) copia dell'intero archivio di musica già convertito alla risoluzione voluta (24/192 o 32/192). Una bella seccatura, specie considerando che dovete comunque tenervi già almeno due copie degli originali (per non rischiare di perderli...) e che per di più la versione pre-processata "pesa" molto di più degli originali.

P.S.: ovviamente, potete confrontare questo ultimo script anche con la prima versione. Dubito che il poco carico extra dovuto alla decompressione online (quando allo stesso tempo viene eseguito il ben più pesante upsampling) cambi qualcosa tra questo e quello... ma, se siete curiosi, provare non costa nulla.

oggi che sono in vena di prove ho tentato di seguire i passi descritti da paolo

mi riferisco all'ultimo script.
dapprima ho avuto un problema con schedtool immagino

Codice: Seleziona tutto

ERROR: could not set PID 19681 to R: SCHED_RR - Operation not permitted

ho commentato con l'asterisco la linea relativa allo schedtool e funziona, però non so come interpretare queste due linee

Codice: Seleziona tutto

sox WARN formats: alsa can't encode to 32-bit
sox INFO formats: can't set sample rate 192000; using 96000

troppo alto 192000??

di seguito l'output completo:

Codice: Seleziona tutto

vincenzo@vima-casa:~/Musica/Eagles (1976) Hotel California$ mymp.sh [0]1*.flac
`01 Hotel California.flac' -> `/dev/shm/01 Hotel California.flac'
sox: SoX v14.3.0
sox INFO formats: detected file format type `flac'

Input File     : '/dev/shm/01 Hotel California.flac'
Channels       : 2
Sample Rate    : 44100
Precision      : 16-bit
Duration       : 00:06:30.27 = 17210760 samples = 29270 CDDA sectors
File Size      : 43.8M
Bit Rate       : 899k
Sample Encoding: 16-bit FLAC
Endian Type    : little
Reverse Nibbles: no
Reverse Bits   : no
Comments       : 
ALBUM=Hotel California (JP-Import)
DATE=1976
GENRE=Rock
ARTIST=Eagles
TRACKNUMBER=01
TITLE=Hotel California

sox WARN formats: alsa can't encode to 32-bit
sox INFO formats: can't set sample rate 192000; using 96000

Output File    : 'hw:0,1' (alsa)
Channels       : 2
Sample Rate    : 96000
Precision      : 16-bit
Duration       : 00:13:00.53 = 74931200 samples ~ 58540 CDDA sectors
Sample Encoding: 16-bit Signed Integer PCM
Endian Type    : little
Reverse Nibbles: no
Reverse Bits   : no

sox INFO sox: effects chain: input      44100Hz 2 channels
sox INFO sox: effects chain: rate       192000Hz 2 channels
sox INFO sox: effects chain: rate       96000Hz 2 channels
sox INFO sox: effects chain: dither     96000Hz 2 channels
sox INFO sox: effects chain: output     96000Hz 2 channels

Alla prima domanda mi rispondo da solo:
per impostare quella priorità bisogna essere root, credo
Ho aggiunto sudo alla linea precedentemente commentata e funziona, anche se chiede la password ogni volta (cosa non desiderabile)

vince ha scritto:Alla prima domanda mi rispondo da solo:
per impostare quella priorità bisogna essere root, credo

Vince', ma che "tutorial" hai seguito? Se avessi fatto tutto come indicato, avrebbe funzionato senza intoppi.

Per prima cosa, dovevi essere in "Single User Mode"! In quella modalità non c'è possibilità di login utente, esiste solo una unica shell di root. Che ha permessi e privilegi per fare tutto.

Ovviamente "schedtool" ha bisogno di privilegi adeguati per poter cambiare priorità e modalità di scheduling dei processi! Dal sistema normale non puoi farlo a meno che l'utente non abbia i privilegi giusti. Ma, soprattutto, NON ha alcun senso farlo! Se hai letto l'introduzione, il motivo di tutto questo lavoro è quello di avere un sistema ridotto ai minimi termini, dove non ci sono altri processi/thread che quelli strettamente indispensabili all'unica funzione desiderata (far suonare i files e niente altro).

Poi, altrettanto ovviamente, non puoi dire a sox di utilizzare un formato di uscita che abbia una risoluzione (sampling rate e/o bit-depth) maggiori di quelle supportate dalla tua scheda audio!

vince ha scritto:ho commentato con l'asterisco la linea relativa allo schedtool e funziona, però non so come interpretare queste due linee
Codice: Seleziona tutto
sox WARN formats: alsa can't encode to 32-bit
sox INFO formats: can't set sample rate 192000; using 96000
troppo alto 192000??

ovviamente si. Per altro, se stai utilizzando l'uscita digitale S/PDIF (come presumo dall'uso del device 1), ci sono ben poche schede audio che permettono di arrivare a 192KHz (che è fuori standard). E naturalmente solo con uscita su rame: il Toslink (S/PDIF su fibra ottica) semplicemente non può andare oltre i 96K.

Quindi ovviamente devi mettere 96000 al posto di 192000.

Idem per la risoluzione: ovviamente, "-b 32" è utilizzabile solo per le schede (e le uscite) che supportano i 32 bit! (di sicuro NON è mai il caso di uscite S/PDIF). Tu al più puoi metterci "-b 24".

L'errore (warning) specifico "alsa can't encode to 32-bit" è invece legato al tuo sistema obsoleto: le vecchie versioni di sox non supportano l'output a 32 bit su device ALSA (max 24).

vince ha scritto: sox INFO sox: effects chain: input 44100Hz 2 channels
sox INFO sox: effects chain: rate 192000Hz 2 channels
sox INFO sox: effects chain: rate 96000Hz 2 channels
sox INFO sox: effects chain: dither 96000Hz 2 channels
sox INFO sox: effects chain: output 96000Hz 2 channels

e questo invece non lo hai notato?!

a causa dell'errore precedente (s/r troppo alta) stavi facendo un doppio resampling, prima su a 192K e poi di nuovo giù a 96K!

UnixMan ha scritto:Per prima cosa, dovevi essere in "Single User Mode"! In quella modalità non c'è possibilità di login utente, esiste solo una unica shell di root. Che ha permessi e privilegi per fare tutto.

Si l'ho letto, non avevo pensato che in quella modalità non sarebbe stato lo stesso riguardo le autorizzazioni.
Ad ogni modo le prove che ho fatto erano solo per far funzionare lo script e avere internet a portata di mano, non avevo nemmeno acceso l'ampli

, la prova con audio la faccio appena posso.

Grazie per le correzioni.

P.s. snd-aloop non mi è ricomparso

vince ha scritto:Si l'ho letto, non avevo pensato che in quella modalità non sarebbe stato lo stesso riguardo le autorizzazioni.
Ad ogni modo le prove che ho fatto erano solo per far funzionare lo script

per quello si può usare "sudo -s" da un terminale per aprire una shell come root. In effetti, probabilmente può essere più comodo preparare e verificare tutto così, prima di riavviare in single user mode per i test audio. Sarebbe anche interessante valutare se ci siano differenze percepibili tra il sistema normale e quello minimale.

vince ha scritto:P.s. snd-aloop non mi è ricomparso

fai questo benedetto aggiornamento! devi arrivare almeno alla 10.04LTS. Visto che dovresti fare almeno due "passaggi" successivi e che non avevi partizionato adeguatamente il disco, sarebbe meglio se ti fai un bel backup su un altro disco (anche esterno) di /home e /etc e poi reinstalli da zero la 11.04, ripartizionando come si deve. Dopo di che fai il restore dei dati di /home (mentre la vecchia /etc la tieni solo come riferimento per le eventuali configurazioni particolari che avevi fatto, specie nel caso qualcuna di esse sia ancora utile con il nuovo sistema).

All'installazione devi scegliere di usare il partizionamento manuale. Per il solo Linux (tranne in casi particolari) si devono fare sempre almeno 3 partizioni. Per un sistema "all-purpouse" come il tuo, nell'ordine fai una prima partizione da 20-30GB(*) (formattata ext4 o xfs) per il sistema ed il software (root file-system, /), poi una (grande circa il doppio della RAM installata) per lo swap ed infine una terza (ancora ext4 o xfs) per /home, cioè per i tuoi dati. Se non ti serve spazio per altre cose (e.g. partizioni per altri S.O.), alla /home assegni tutto lo spazio restante.

Se devi fare solo queste 3 partizioni, conviene che le fai tutte primarie. Se invece te ne servono 4 o più, ricorda che non puoi avere più di 3 partizioni primarie più una quarta "estesa" che contiene tutte le altre partizioni ("logiche"). Se stai installando un sistema multi-boot con più sistemi operativi, ricorda che alcuni S.O. (ad es. varie versioni di windows) devono essere installate in una partizione primaria.

Inoltre, almeno con alcune combinazioni di HDD/BIOS, potrebbe non essere possibile avviare un S.O. se questo è installato su una partizione che si trova "troppo lontano" dall'inizio del disco. Conviene quindi che i dischi di avvio di tutti i S.O. siano all'inizio del disco.

Per quanto riguarda Linux, per ottimizzare le prestazioni conviene che le sue 3 partizioni siano sempre l'una contigua all'altra (nell'ordine: /, swap, /home). In definitiva, come esempio, per il comune dual-boot Windows/Linux conviene avere: p1 win, p2 linux /, p3 linux swap, p4 linux /home.

(*) per un sistema minimale/dedicato può bastare molto meno spazio... anche meno di 1GB, se non addirittura poche decine di MB (ma questo è un altro discorso).

Io ho un problema di clipping delle tracce audio.
Ho provato ad utilizzare -v -3 oppure gain -3, ma le cose sono andate peggio e la traccia distorceva maggiormente. Forse non ho capito bene la sintassi di sox

vince ha scritto:Io ho un problema di clipping delle tracce audio.

strano, non mi è mai capitato. Hai cercato di fargli fare qualcosa di diverso dal solo upsampling come indicato?

(N.B.: occhio che, spesso, quando sox dopo aver processato e/o riprodotto un brano ti dice che ha clippato "n" volte, questo può anche essere dovuto al clipping già contenuto nelle registrazioni "pompate" che oggi sono purtroppo estremamente comuni!)

vince ha scritto:Ho provato ad utilizzare -v -3 oppure gain -3, ma le cose sono andate peggio e la traccia distorceva maggiormente. Forse non ho capito bene la sintassi di sox

dove hai messo quelle opzioni all'interno della riga di comando?

Nella riga di comando di sox la posizione e l'ordine delle varie opzioni conta! Se devi prevenire il clipping, la riduzione del gain la devi fare prima della/e operazione/i che possono dar luogo a clipping.

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:

Codice: Seleziona tutto

sox -S -V --single-threaded --combine sequence "${playlist[@]}"  -t alsa -b 32 hw:0,0  gain -3  rate -v -I -a 192000

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:

Codice: Seleziona tutto

{[file server]<-(1)->[stream transmitter]}-(2)->[stream receiver]-(3)->[audio system]

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

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
Reverse Nibbles: no
Reverse Bits   : no

sox INFO sox: effects chain: input      44100Hz 2 channels
sox INFO sox: effects chain: gain       44100Hz 2 channels
sox INFO sox: effects chain: rate       96000Hz 2 channels
sox INFO sox: effects chain: dither     96000Hz 2 channels
sox INFO sox: effects chain: output     96000Hz 2 channels
In:5.64% 00:00:17.00 [00:04:44.50] Out:1.62M [      |      ]        Clip:0

invece con

Codice: Seleziona tutto

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

plughw invece di hw
questo

Codice: Seleziona tutto

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

sox INFO sox: effects chain: input      44100Hz 2 channels
sox INFO sox: effects chain: gain       44100Hz 2 channels
sox INFO sox: effects chain: rate       96000Hz 2 channels
sox INFO sox: effects chain: dither     96000Hz 2 channels
sox INFO sox: effects chain: output     96000Hz 2 channels
In:0.68% 00:00:02.04 [00:04:59.45] Out:190k  [     =|=-    ]        Clip:0

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:

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
EndianType    : little
Reverse Nibbles: no
Reverse Bits   : no

sox INFO sox: effects chain: input      44100Hz 2 channels
sox INFO sox: effects chain: gain       44100Hz 2 channels
sox INFO sox: effects chain: rate       96000Hz 2 channels
sox INFO sox: effects chain: dither     96000Hz 2 channels
sox INFO sox: effects chain: output     96000Hz 2 channels
In:2.37% 00:00:03.90 [00:02:40.51] Out:369k  [      |=     ]        Clip:0

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

Codice: Seleziona tutto

Sample Encoding: 16-bit FLAC

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:

Codice: Seleziona tutto

sudo apt-get update
sudo aptitude install dpkg-dev dh-make build-essential fakeroot
mkdir /var/tmp/build
cd /var/tmp/build
apt-get source sox
cd sox-14.3.2
sudo apt-get build-dep sox

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:

Codice: Seleziona tutto

sudo aptitude install cdbs debhelper ladspa-sdk libao-dev libasound2-dev libavcodec-dev libavformat-dev libavutil-dev libgsm1-dev libid3tag0-dev libltdl3-dev libmad0-dev libmagic-dev libmp3lame-dev libopencore-amrnb-dev libopencore-amrwb-dev libpng12-dev libpulse-dev libsamplerate0-dev libsndfile1-dev libvorbis-dev libwavpack-dev

(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:

Codice: Seleziona tutto

dpkg-buildpackage -rfakeroot

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:

Codice: Seleziona tutto

cd ..
sudo dpkg -i *.deb

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:

Codice: Seleziona tutto

Output File    : 'hw:0,0' (alsa)
Channels       : 2
Sample Rate    : 44100
Precision      : 16-bit
Sample Encoding: 32-bit Signed Integer PCM
Endian Type    : little
Reverse Nibbles: no
Reverse Bits   : no

(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).

A proposito dell'influenza sul suono dell'hardware informatico di una "sorgente liquida", qui hanno fatto un confronto tra due diversi sistemi dedicati, uno basato su una scheda Alix 3d2 (AMD Geode, x86 compatibile) con Voyage MPD ed un altro basato su un CuBox (ARM) con "MuBox" (cioè Voyage MPD per CuBox):

http://exd-audio.blogspot.it/2013/04/cubox-vs-alix.html
[youtube]wxXcAG3uGzI[/youtube]

Onestamente non so cosa si possa capire da un video su youtube. Certo sarebbe più interessante leggere su "DIYMania.NET" i commenti di chi ha assistito direttamente alla prova, se ce ne sono. Ho provato ad usare un traduttore automatico, ma il risultato non è dei migliori.

Se qualcuno conoscesse il coreano...

anche sul forum di nexthardware (frequentato dalla comunità italiana dei "fan" del cMP²) si comincia a parlare di Linux. In particolare, in questo topic:

http://www.nexthardware.com/forum/cmp2- ... post880548

potete trovare l'immagine ISO di una versione di "TinyCore Linux" pre-configurata (con ALSA e DeadBeef) per l'uso come sorgente audio (interattiva, locale, con GUI), nonché le (semplicissime) istruzioni dettagliate per trasferirla su un memory-stick ("chiavetta") USB ed utilizzarla su qualsiasi PC.

Si tratta di un sistema "live", che parte direttamente dal memory-stick e si carica completamente in RAM all'avvio. Non installa né modifica nulla sul disco/i del PC su cui lo si fa girare, ed anzi un disco rigido può anche non esserci affatto. Quindi si può provare tranquillamente su qualsiasi PC senza timore di modificare in alcun modo il sistema che ci sia eventualmente già installato, che resta inalterato.

Tanto l'installazione che l'uso sono oltremodo semplici e non richiedono connessioni di rete. Provatelo...

In questo topic sul forum di TinyCore trovate una discussione correlata:

http://forum.tinycorelinux.net/index.ph ... 739.0.html

Per chi ha un minimo di spirito di iniziativa, è possibile "importare" i pacchetti di Debian, convertendoli in pacchetti "sce" di Core: http://tinycorelinux.net/5.x/x86/README ... import.txt

In questo modo dovrebbe essere possibile installare e provare anche altri player, incluso MPD (e relativi client).

La versione "Core" (la più minimale, priva di interfaccia grafica ed altri orpelli) potrebbe quindi essere anche utilizzata come base per realizzare un music server ("headless", cioè senza monitor ne dispositivi di input) basato su MPD in alternativa a Voyage o altre distribuzioni (possibile vantaggio di una soluzione simile è il minimalismo ancora più spinto del sistema di base ed il fatto che questo gira interamente in RAM, ancorché personalmente dubito che ciò possa offrire vantaggi significativi, mentre Voyage è sicuramente di gran lunga più comodo e pratico per questo scopo).

Una guida all'ottimizzazione di Linux per l'audio. Si riferisce principalmente all'uso in produzione (dove ottenere una bassa latenza è una necessità), ma alcune cose possono tornare utili anche in fase di riproduzione:

http://wiki.linuxaudio.org/wiki/system_configuration

potete trovare l'immagine ISO di una versione di "TinyCore Linux" pre-configurata (con ALSA e DeadBeef) per l'uso come sorgente audio (interattiva, locale, con GUI), nonché le (semplicissime) istruzioni dettagliate per trasferirla su un memory-stick ("chiavetta") USB ed utilizzarla su qualsiasi PC.

Scaricata e provata a confronto con windows e foobar, senza upsampling......
Qualche differenza c'è.......linux sembrerebbe un pò "attufato".....ma è un confronto da ripetere...

mandello ha scritto:Scaricata e provata a confronto con windows e foobar, senza upsampling......
Qualche differenza c'è.......linux sembrerebbe un pò "attufato".....ma è un confronto da ripetere...

non puoi confrontare mele e pere. Il confronto lo devi fare a parità di condizioni, cioè con o senza upsampling in entrambi i casi. Però con il tuo DAC l'upsampling è di fatto obbligatorio: è stato progettato per funzionare così. Con stream 44/16 senza upsampling si ottiene un suono all'apparenza più aperto e brillante che però ad un ascolto più attento è evidentemente "sbagliato".

Il confronto è stato fatto a pari condizioni, no upsampling per entrambi, semplicemente perchè non avevo voglia di smanettare col player linux (ero preso dal posizionamento delle casse), comunque ripeto.....confronto volante tanto per curiosità, decisamente da ripetere....

A quanto pare, gli sviluppatori di "HQPlayer" hanno avuto la mia stessa idea, ovvero quella di separare il computer che gestisce interfaccia, accesso ai dischi, elaborazioni varie (e.g. upsampling), ecc. da quello che è connesso direttamente all'interfaccia audio, utilizzando per questo scopo un micro-sistema dedicato ed ottimizzato, a bassissimo consumo, senza dischi, video, ecc (e quindi verosimilmente a basso rumore), mentre l'altro computer può avere la potenza di calcolo necessaria per le elaborazioni richieste nonché tutti i dischi e le periferiche che servono. La connessione Ethernet garantisce l'isolamento galvanico tra il "master" e lo "slave". Meglio ancora, si potrebbe anche pensare di utilizzare una connessione Ethernet su fibra ottica...

network_streaming.png

http://www.nexthardware.com/forum/cmp2- ... layer.html (vedi "Network Audio").

Una architettura del tutto analoga si può realizzare convenientemente anche utilizzando esclusivamente software Open Source, ad es. con "Jack" e "NetJack".

http://jackaudio.org/netjack

http://trac.jackaudio.org/wiki/WalkThrough/User/NetJack

Bha?!?!

[IMHO mode = on]
Tutto 'sto casino per una FIFO e isolamento galvanico ? Mi pare come usare il cannone per ammazzare le zanzare.
Ho pure dei dubbi che il sistema operativo abbia così importanza. Il PC deve dare dati senza interruzioni alla scheda USB-I2S: se lo fa il risultato deve essere indipendente dal S.O.Se non lo è hai sbagliato qualcosa da qualche parte nel configurare il tutto.
Già che ci sono ho dubbi anche sul ricampionamento: non si possono ricreare i dati che non ci sono dal nulla. L'unico motivo per cui potrebbe valere la pena ricampionare e quella di far lavorare il chip del DAC alla frequenza dove ha le prestazioni migliori. Spesso 44 o 48Khz. In tutti gli altri casi le differenza che senti sono gli errori di arrotondamento e il ringing dei filtri che introduci campionando.
[IMHO mode = off]

Sono rientrato da qualche giorno e, complice la rottura della meccanica, sto ascoltando molto da pc con dead beef....sono riuscito a fare l'upsampling e sembra vada molto bene, vorrei metabolizzare un pò e poi ripeto i confronti con altri software anche se attualmente non ne sento il bisogno....
per il momento sto ascoltando con amanero alimentata a batteria, un piccolo ma deciso passo avanti....

Dopo un weekend di ascolti ho deciso di usare tynicore con deadbeef come "player", mi è sembrato superiore a windows e si avvia in un secondo.....
attualmente faccio il boot da usb, vorrei farlo da sd card ma non riesco, nel menù non riesco a trovare l'opzione, mi da solo hd locale, dvd o usb device....sapreste spiegarmi come procedere????

in genere le SD sono viste come devices USB, quindi proverei quello...

Niente da fare, al boot non mi vede la scheda sd......

www.audiofaidate.org

Con Linux sulla via del cMP²

Con Linux sulla via del cMP²

Re: Con Linux sulla via del cMP²

Re: Con Linux sulla via del cMP²

Re: Con Linux sulla via del cMP²

Re: Con Linux sulla via del cMP²

Re: Con Linux sulla via del cMP²

Re: Con Linux sulla via del cMP²

Re: Con Linux sulla via del cMP²

Re: Con Linux sulla via del cMP²

Re: Con Linux sulla via del cMP²

Re: Con Linux sulla via del cMP²

Re: Con Linux sulla via del cMP²

Re: Con Linux sulla via del cMP²

Re: Con Linux sulla via del cMP²

Re: Con Linux sulla via del cMP²

Re: Con Linux sulla via del cMP²

Re: Con Linux sulla via del cMP²

Re: Con Linux sulla via del cMP²

Re: Con Linux sulla via del cMP²

Re: Con Linux sulla via del cMP²

Re: Con Linux sulla via del cMP²

Re: Con Linux sulla via del cMP²

Re: Con Linux sulla via del cMP²

Re: Con Linux sulla via del cMP²

non capisco a quanti bit è l'output

Re: non capisco a quanti bit è l'output

Re: non capisco a quanti bit è l'output

Re: non capisco a quanti bit è l'output

Re: Con Linux sulla via del cMP²

Re: Con Linux sulla via del cMP²

Re: Con Linux sulla via del cMP²

Re: Con Linux sulla via del cMP²

Re: Con Linux sulla via del cMP²

Re: Con Linux sulla via del cMP²

Re: Con Linux sulla via del cMP²

Re: Con Linux sulla via del cMP²

Re: Con Linux sulla via del cMP²

Re: Con Linux sulla via del cMP²

Re: Con Linux sulla via del cMP²

Re: Con Linux sulla via del cMP²

CuBox vs Alix

Re: Con Linux sulla via del cMP²

Re: Con Linux sulla via del cMP²

Re: Con Linux sulla via del cMP²

Re: Con Linux sulla via del cMP²

Re: Con Linux sulla via del cMP²

Re: Con Linux sulla via del cMP²

Re: Con Linux sulla via del cMP²

Re: Con Linux sulla via del cMP²

Re: Con Linux sulla via del cMP²

Re: Con Linux sulla via del cMP²

Re: Con Linux sulla via del cMP²