Voyage MPD + Alix + ESI Juli@ + Ali by Tfan = Sorgente liquida superba!

Esagererò? Io lo definirei con orgoglio un "ammazza Bryston" perché, pur prendendo ispirazione dall'eccellente lettore digitale della famosa azienda, ho passato gli scorsi tempi a realizzarne una versione migliorata, ad un costo decisamente più contenuto dei 3000 sacchi chiesti dal prodotto commerciale.

In realtà questo lettore è pronto da qualche mese, ma l'estate e gli impegni hanno come al solito ritardato la sua presentazione

Non è nulla di particolarmente nuovo o incredibile, bensì l'unione di temi noti nella rete, in buona parte qui conosciuti. Tuttavia, anche se mi piacerebbe fare qualche "sfida" per capacitarmi delle sue possibilità, dubito ci siano molte meccaniche cd in giro capaci di battere questo "coso", sopratutto tenendo conto della spesa fatta.

Gli ingredienti sono pochi ma buoni:

1) Scheda madre con CPU e RAM integrata Alix.1D: questa scheda è favolosa perché offre buone performance e ottima costruzione a prezzo contenuto e, sopratutto, a bassissimi consumi. Considerate che prevede un picco di 1.2 ampere per 12v, con un consumo medio di 0.4 A.
Per l'hard disk ho usato una semplice CF card da 4 GB.



2) Sistema operativo Voyage MPD (in questo istante ho appena fatto l'upgrade all'ultimo snapshot, versione 0.9)

Se ne è parlato molto di questa distribuzione linux leggera ed efficente, con kernel realtime, alsa 1.25 e mpd 0.17 (quest'ultimo solo nella snapshot attuale).
Beh, funziona che è un piacere, stabilissima e sonicamente (che ci crediate o no), FA LA DIFFERENZA!

Come client uso un netbook con Ubuntu e GMPC, ma qui ci si può sbizzarrire.

La musica risiede tutta su di un nas con condivisioni di rete Samba.


3) Scheda audio Esi Juli@: semplicemente la scheda audio più amata dagli autocostruttori. Ho a lungo cantato le lodi dello strabiliante stadio di uscita della mia precedente Asus Xonar Essence, ma se volete il massimo da un'uscita digitale non vi resta che prendere questa schedina, per via della grande versatilità e della facilità di apportarle modifiche.

Ecco una foto "di repertorio" in versione liscia:



ed ecco quella che ho ottenuto io dopo qualche modifica:




Come potete vedere, ho eliminato quell'obbrobrio di adattatore, il quale permette di uscire in digitale ed inviare segnali MIDI.
Dopo aver eliminato la sezione analogica, ho quindi estratto il segnale spdif dal relativo chip, usando del cavo mogami spellato. Visto che volevo strafare ho quindi realizzato sia una RCA che una BNC. Il risultato è abbastanza pulito visto che il bracket della scheda, una volta eliminata la sezione analogica, lascia diversi buchi adatti per infilarci i suddetti connettori.

Poi arriva il bello. Dove c'è la sigla "U1" potete notare un regolatore di tensione. La scheda audio riceve una tensione da 5 volts dallo slot PCI. La sezione analogica riceve questa corrente da quegli header scoperti che vedete in secondo piano (ma a noi non interessa visto che non la utilizziamo). La sezione digitale invece necessita di una 3.3 volts, ottenuta dal regolatore U1.
Dissaldando questo regolatore è possibile isolare l'alimentazione della scheda da quella dello slot PCI, permettendoci così di alimentare la scheda con il nostro alimentatore lineare superfigo oltre al fatto che così facendo separiamo le alimentazioni di scheda audio e del resto del pc (ovviamente i segnali di controllo del bus PCI vengono preservati).



Uno dei miei esperimenti è stato anche prelevare il segnale I2S dalla scheda, ottenendolo dagli header centrali della scheda. Come potete vedere, usando un estremo di un cavo di rete questo è ottenibile con relativa facilità.
Se vi state chiedendo come abbia fatto a collegare tale cavo agli header senza saldare, vi svelo un segreto: ho utilizzato i piccoli jumper che si usano nelle schede madri per collegare led e bottoni vari alla stessa

Ecco uno scatto.



Il motivo di utilizzare quel connettore RJ45 è dato dalla necessità di interfacciarlo all'ingresso I2S di un North Star 32. Tuttavia, visto il risultato tutto sommato deludente (rispetto alla SPDIF), immagino che le perplessità di molti su questo ingresso, così implementato, siano fondate. Infatti, se sommiamo la lunghezza di questa connessione (in verità molto contenuta) alla distanza tra il connettore del DAC e il punto in cui il segnale I2S viene elaborato, probabilmente si ottiene una distanza totale assolutamente penalizzante (ricordo che la I2S sembra richiedere distanze cortissime, entro i 2-3 cm, se non sbaglio).


4) Per il case ho voluto strafare e mi sono rivolto al meraviglioso Silverstone Grandia GD02.
Di spazio ne avanza un bel po', visto che la Alix è una scheda molto contenuta (miniitx). Però come resistere alla tentazione di riusare un case così bello? E poi, per l'alimentazione, avevo intenzione di usare qualcosa nel formato ATX (vedrete poi) e così...
Ovviamente è possibile usare case ancor più piccoli e, sopratutto, economici (Silverstone costicchia, ahimè).



5) Un alimentatore lineare da 12 + 3.3 volt, costruito dal mitico Tfan!
Ebbene si, c'è il suo zampino anche qua, e vista la mia richiesta di un buon lineare per le sopracitate tensioni (12v per la mobo Alix e 3.3v per la Juli@), che entri in un contenitore per PSU ATX opportunamente svuotato, ecco cosa ha tirato fuori!







Come dicevo, le dimensioni dell'alimentatore entro le quali ho chiesto a Tfan di rimanere non sono casuali. E' stato più faticoso del previsto inserire questo blocco in un ATX, ma una volta riuscito ho ottenuto un dispositivo facilmente fissabile nel case Silverstone. Nelle foto ho lasciato aperto l'alimentatore (che tra l'altro, visti i bassi consumi in gioco, scalda pochissimo) giusto per mostrare la circuiteria, ma normalmente lo chiudo con lo sportello superiore, ottenendo tra l'altro anche uno schermo ad eventuali interferenze (non so quanto efficace, in verità... ma vabbè).


Inutile dire che questo alimentatore, semplice ma di ottimi componenti, ha letteralmente surclassato ciò che utilizzavo prima, con conseguenze sulla qualità sonora più che tangibili.


Ancora qualche scatto, in panoramica









E come suona? Beh, il già citato Bryston (rispetto a cui qui c'è una maggior cura nell'alimentazione, sebbene quell'elettronica presenti un'uscita digitale bilanciata, che però credo sia meno determinante del primo aspetto) l'ho ascoltato in una fiera e mi è piaciuto moltissimo, però non avendone uno a casa non ho avuto modo di confrontarli.
Sta di fatto che con una spesa decisamente inferiore mi ritrovo con la miglior sorgente che abbia posseduto, oltre a battere nettamente ogni altra meccanica o pc con la quale ho avuto modo di confrontarla.
Mi piacerebbe fare altri confronti in futuro, per capire bene quanto possa dare questa creatura, e ho onestamente grandi aspettative al riguardo

E stic......
Complimenti!!!!!

Ma all'incirca supperggiù la spesa?

non vedo nessuna foto...

Eccellente, bravissimo!! Fantastica realizzazione, ha la mia approvazione!

Unica cosa che m'ha quasi fatto partire un embolo...

Miclaud ha scritto:La musica risiede tutta su di un nas con condivisioni di rete Samba.

Argh, ti affidi al protocollo TCP/IP per lo streaming di dati???
Eresia!!!

Mettici un SSD da 256 GB (costa lo so... http://www.ebay.it/itm/CRUCIAL-SSD-interno-Crucial-v4-256-GB-/170891621433 170 euro) e hai il sistema definitivo.

Vuoi tenere il NAS comunque per la musica? Benissimo, allora ti fai uno script che ti tiene sincronizzato il tuo SSD con il NAS così hai sempre tutta la musica disponibile.

Fidati, è nettamente meglio.

Concordo con DonLuca... Epperò complimenti !

Complimenti Miclaud: ho visto che i file per MPD nel Voyage non sono ottimizzati:

Codice:

/etc/init.d/mpd
/etc/mpd.conf


Se me li mandi, ti cambio alcuni parametri fondamentali che hanno un impatto non trascurabile sul suono (migliora la trasparenza e la presenza).

Vedi anche il mio post sul Synology Nas su cui ho installato MPD:

https://www.tforumhifi.com/t27961-trasforma-il-tuo-hard-disk-nas-synology-in-un-trasporto-usb-audiofilo

Miclaud, ho visto che ci sono poche modifiche, te le scrivo direttamente qui che ci vogliono pochi minuti, basta che usi un editor di testi ASCII (vi, emacs, nano, ...). Ho scritto i commenti in inglese (sono quelli che iniziano con #blabla) perché li avevo messi nel forum di Synology NAS, ma li puoi togliere se vuoi.

Facci sapere se senti differenze! Ho passato un po' di tempo a sperimentare, mi sono studiato anche come MPD interagisce con ALSA.

file da modificare: /etc/init.d/mpd

Qui dai la massima piorità al processo MPD

Modifica 1:

Codice:

START_MPD=true

diventa

Codice:

START_MPD=true

CAT="/bin/cat"
RENICE="/usr/bin/renice"
RENICE_VAL="-20"                  # range is -20..20, best is -20


Modifica 2:

Codice:

    start-stop-daemon --start --quiet --oknodo --pidfile "$PIDFILE" \
        --exec "$DAEMON" -- $MPD_OPTS "$MPDCONF"
    log_end_msg $?
}


diventa

Codice:

    start-stop-daemon --start --quiet --oknodo --pidfile "$PIDFILE" \
        --exec "$DAEMON" -- $MPD_OPTS "$MPDCONF"
    "$RENICE" "$RENICE_VAL" `$CAT $PIDFILE`
    log_end_msg $?
}


file da modificare: /etc/mpd.conf

Qui disabiliti completamente il mixer (che può sporcare il suono) e aumenti opportunamente i buffer audio.

Modifica 3:

Codice:

audio_output {
   type      "alsa"
   name      "My ALSA Device"
   device      "hw:0,0"   # optional
   format      "44100:16:2"   # optional
   mixer_device   "default"   # optional
   mixer_control   "PCM"      # optional
   mixer_index   "0"      # optional
}


diventa

Codice:

audio_output {
   type      "alsa"
   name      "BitPerfect ALSA"
   device      "hw:0,0"   # optional
   mixer_type   "none"
   #use_mmap   "yes"
   replay_gain_handler   "none"
   auto_resample   "no"
   auto_channels   "no"
   auto_format   "no"
        # tune these two params in usec (buffer_time = 4 * period_time), where period=fragment in the round-robin buffer (see alsa_output_plugin.c)
   period_time   "524288"
   buffer_time   "2097152"
}


Prova anche a togliere la gratella # a #use_mmap, in alcune schede il suono migliora, in altre no.

Modifica 4:

Codice:

#audio_buffer_size      "2048"
#buffer_before_play      "10%"


diventa

Codice:

audio_buffer_size   "16384"  # audio_buffer_size >= 8 * sampling_freq * 2 * (bit_depth/8) * buffer_time/1000000 
buffer_before_play      "25%"    # follows from: buffer_time = 4 * period_time


Modifica 5 (in fondo al file):

Codice:

mixer_type "hardware"


diventa

Codice:

mixer_type "none"


Tfan ha scritto:non vedo nessuna foto...

È possibile avere lo schema dell'alimentazione a 3.3V?

P.S. Ogni agosto sono a SBT, ero lì fino a pochi giorni fa (mia moglie ha vissuto lì fino alla maggiore età)

Oh ! Finalmente sei diventato FANLESS !!!

Urge incontro per approfondito ascolto !

Molto bello complimenti
Unica domanda: ma per l'alimentazione si deve per forza mantanere quel cavo che si fa il giretto fuori..??

robertopisa ha scritto:file da modificare: /etc/init.d/mpd

Qui dai la massima piorità al processo MPD

Modifica 1:

Codice:

START_MPD=true

diventa

Codice:

START_MPD=true

CAT="/bin/cat"
RENICE="/usr/bin/renice"
RENICE_VAL="-20"                  # range is -20..20, best is -20


Dal momento che viene usato un kernel Real-Time, IN TEORIA questo passaggio dovrebbe essere inutile.

Ah, e se propende per usare un SSD non c'è bisogno d'avere il buffer audio così grande

Complimenti per l'ottima spiegazione e realizzazione!

Quando avrò finito di giocare con l'ibook G4 della mia fidanzata mi farò qualcosa di simile!

Via, sei un ingegnere, sai bene che c'è differenza tra la teoria e la pratica :-)

Per esempio: l'importante è che con "top -d1" il CPU time sia quasi sempre 0.0% (sì, hai letto bene, ottengo ciò con MPD sul NAS) con degli sporadici picchi del 60-70% (quando il buffer viene ricaricato). Sorprendentemente questo va molto meglio acusticamente di avere constantemente un CPU time basso, attorno al 3-7%. Non so bene il perché, la motivazione potrebbe essere nella Fisica e nell'Elettronica, non è il mio campo.

La modifica che propongo è semplice da fare, uno la prova e vede se funziona o no... si basa sulla lettura del plugin di MPD per ALSA e l'ascolto estivo.

-R

donluca ha scritto:

robertopisa ha scritto:file da modificare: /etc/init.d/mpd

Qui dai la massima piorità al processo MPD

Modifica 1:

Codice:

START_MPD=true

diventa

Codice:

START_MPD=true

CAT="/bin/cat"
RENICE="/usr/bin/renice"
RENICE_VAL="-20"                  # range is -20..20, best is -20


Dal momento che viene usato un kernel Real-Time, IN TEORIA questo passaggio dovrebbe essere inutile.

Ah, e se propende per usare un SSD non c'è bisogno d'avere il buffer audio così grande

Madonna un lavoro con i fiocchi!!!!

Miclaud.

Molto bella l Alix.1D...ha pure il bios Award..

1)è perfettamente stabile con voyage ..??

2)fa il boot da usb.??


Grazie

Gran lavoro e grande voglia di emulazione. Complimenti Michele.

Ma ha battuto anche l'XMOS che hai provato?

Se lo ha battuto credo solo grazie alle distanze citate da Michele, o magari qualcosa non andava per il verso giusto. Per prove effettuate personalmente fra I2s e S/pdif non c'è storia ovviamente a favore di I2s.

robertopisa ha scritto:Via, sei un ingegnere, sai bene che c'è differenza tra la teoria e la pratica :-)

Per esempio: l'importante è che con "top -d1" il CPU time sia quasi sempre 0.0% (sì, hai letto bene, ottengo ciò con MPD sul NAS) con degli sporadici picchi del 60-70% (quando il buffer viene ricaricato). Sorprendentemente questo va molto meglio acusticamente di avere constantemente un CPU time basso, attorno al 3-7%. Non so bene il perché, la motivazione potrebbe essere nella Fisica e nell'Elettronica, non è il mio campo.

La modifica che propongo è semplice da fare, uno la prova e vede se funziona o no... si basa sulla lettura del plugin di MPD per ALSA e l'ascolto estivo.

-R

Non sono cose che ho provato personalmente quindi ti dico come qualcosa dovrebbe funzionare sempre in teoria e in mancanza di dati tangibili che mi dimostrino il contrario

Per dirti... il carico di lavoro della CPU in che modo potrebbe mai inficiare sulla resa sonora? Pure che sta carico al 90% ma non sfora mai, cosa comporta? Uno sforzo del bus (che non dovrebbe mai diventare saturato sennò c'è un problema di progettazione dietro)? Uno sforzo dell'alimentazione (se così fosse vuol dire che l'alimentazione non è all'altezza perchè deve essere stabile pure con la CPU al 100%)?
Ci sono tantissime cose "strane" e apparentemente prive di senso (informatico, elettronico, fisico, matematico) nella musica liquida e personalmente sono fortemente scettico finchè non tocco con mano, un pò come S. Tommaso

Comunque non posso fare a meno di fare una citazione a riguardo...

Spoiler:

donluca ha scritto:

Miclaud ha scritto:La musica risiede tutta su di un nas con condivisioni di rete Samba.

Argh, ti affidi al protocollo TCP/IP per lo streaming di dati???
Eresia!!![...]

Ciao,
perché la ritieni un'eresia?

Grazie,
Andrea

Il protocollo TCP/IP è un protocollo di tipo "best effort", tradotto un pò liberamente in italiano "alla bell'emmeglio".

Si basa sulla trasmissione di pacchetti senza alcun tipo di controllo d'errore, lui li spedisce e basta e non gli interessa se eventuali pacchetti sono arrivati "integri" o meno, alla peggio li rispedisce in un secondo momento qualora non fossero pervenuti causando così una desincronizzazione che se stai a trasferire un file alla fine dirai pure "sticavoli" ma parlando di musica quella è una botta di jitter non indifferente.

Diciamo che quest'ultimo problema lo risolvi col buffering ma rimane comunque il problema dell'integrità dei pacchetti che in realtà potrebbe essere risolto con un controllo via software ma questo indurrebbe un ulteriore ritardo causato dal controllo su ogni singolo pacchetto.

Parte di questi problemi vengono risolti mediante il protocollo UDP (che almeno è multicast) e viene largamente usato per lo stream di contenuti multimediali ma per applicazioni audiofile imho è ancora non soddisfacente.

Poi ci sarebbe il discorso Samba ma qua veramente non finiamo più se mi metto anche a parlare di tecnologie di condivisione file

Per approfondimenti:

http://it.wikipedia.org/wiki/Suite_di_protocolli_Internet
http://it.wikipedia.org/wiki/User_Datagram_Protocol

L'UDP è piú veloce ma non è affidabile come il TCP, infatti non c'è nessun controllo che i pacchetti spediti siano stati ricevuti, né alcuna garanzia che i "pacchetti" vengano ricevuti nello stesso ordine con cui sono stati inviati, il controllo e l'eventuale ritrasmissione se la deve gestire chi scrive il software. Il TCP è più "lento" proprio perchè gestisce la ritrasmissione, mette in ordine i pacchetti e verifica l'integrità dei dati (tramite checksum).

Riguardo al jitter, secondo me in caso di problemi si possono verificare delle interruzioni della riproduzione nettamente avvertibili come pause (risolvibili con un buffer dati), ma non credo possa introdurre jitter del tipo riscontrabile in lettori CD o DAC...

Switters ha scritto:Il TCP è più "lento" proprio perchè gestisce la ritrasmissione, mette in ordine i pacchetti e verifica l'integrità dei dati (tramite checksum).

Odierei sbagliarmi ma posso mettere la mano sul fuoco che la ritrasmissione avviene solo mediante degli "ACK" che si occupano di dire alla sorgente dei dati se il pacchetto è stato ricevuto o meno e nella configurazione standard questo avviene fino a 3 volte dopodichè il pacchetto non arrivato viene mandato in coda e rispedito in un secondo momento, quindi data proprio la natura "best effort" del protocollo non garantisce assolutamente che i pacchetti arrivino nell'ordine in cui sono stati inviati (a volte neanche che vengano ricevuti, ci sta sempre il timeout) e l'integrità dei dati viene controllata mediante checksum software in base a cosa stai usando, ma il protocollo in se non ha alcun tipo di controllo sull'integrità dei dati (non a caso i grossi download di software vengono forniti proprio con un md5 checksum, una stringa numerica che confrontata col file scaricato ti dice se è integro).

Riguardo l'UDP imho è meglio del TCP perchè i dati vengono inviati in multicast quindi, a meno di errori, il timing dell'invio e ricezione è più tight, assicurando così una riproduzione più accurata.

Riguardo al jitter dipende fortissimamente dal programma usato per la riproduzione, ma un programma che fa uno streaming "puro" senza controllo sul timing della trasmissione porterà inevitabilmente alla creazione di jitter a seconda della qualità della connessione. Diciamo che con un buffer in parte ci si mette una pezza, ma a meno di non implementare un algoritmo di re-sincronizzazione dei dati non hai la sicurezza che eventuali errori in trasmissione non vadano a creare jitter.

Bellina la citazione di Asimov, tanto lo sai che in realtà i computer sono non-deterministici (trad: ogni tanto fanno come c...o gli pare :-)
-R

donluca ha scritto:

robertopisa ha scritto:Via, sei un ingegnere, sai bene che c'è differenza tra la teoria e la pratica :-)

Per esempio: l'importante è che con "top -d1" il CPU time sia quasi sempre 0.0% (sì, hai letto bene, ottengo ciò con MPD sul NAS) con degli sporadici picchi del 60-70% (quando il buffer viene ricaricato). Sorprendentemente questo va molto meglio acusticamente di avere constantemente un CPU time basso, attorno al 3-7%. Non so bene il perché, la motivazione potrebbe essere nella Fisica e nell'Elettronica, non è il mio campo.

La modifica che propongo è semplice da fare, uno la prova e vede se funziona o no... si basa sulla lettura del plugin di MPD per ALSA e l'ascolto estivo.

-R

Non sono cose che ho provato personalmente quindi ti dico come qualcosa dovrebbe funzionare sempre in teoria e in mancanza di dati tangibili che mi dimostrino il contrario

Per dirti... il carico di lavoro della CPU in che modo potrebbe mai inficiare sulla resa sonora? Pure che sta carico al 90% ma non sfora mai, cosa comporta? Uno sforzo del bus (che non dovrebbe mai diventare saturato sennò c'è un problema di progettazione dietro)? Uno sforzo dell'alimentazione (se così fosse vuol dire che l'alimentazione non è all'altezza perchè deve essere stabile pure con la CPU al 100%)?
Ci sono tantissime cose "strane" e apparentemente prive di senso (informatico, elettronico, fisico, matematico) nella musica liquida e personalmente sono fortemente scettico finchè non tocco con mano, un pò come S. Tommaso

Comunque non posso fare a meno di fare una citazione a riguardo...

Spoiler:

Se non ricordo male nell'header TCP dovrebbe esserci un sequence number che dovrebbe servire allo stack TCP proprio per rimettere in ordine i pacchetti anche se li ha ricevuti fuori sequenza (credo che un pacchetto venga rispedito se non viene ricevuto il rispettivo ACK).
Non ci metto la mano sul fuoco, potrebbe essere che il controllo del checksum non sia obbligatorio e che dipenda da come è implementato lo stack TCP, però se così fosse immagino si scaricherebbero molti piú file corrotti di quanto capiti
E sono pressoché certo che la verifica dell'integrità non viene fatta a livello di software applicativo, ho dato un'occhiata a un po' di sorgenti di software di networking che usano TCP e non ne ho mai trovato traccia.
Riguardo lo streaming l'UDP come prestazioni è sicuramente meglio, non avendo tutto l'overhead del TCP, però poi ci possono essere altri problemi, ad esempio se uno dei client che devi raggiungere è dietro un firewall che fa masquerading (source NAT), però qui mi sembra che stiamo andando leggermente OT...