Uscita I2S per HQPlayer-NAA

[luca72c]

Ethernet-i2s? Molto interessante! Ma e' appunto quello che fa il Raspberry nel mio sistema: legge un file in rete dal server e lo passa in i2s al dac. Non ho dubbi che l'interfaccia della xmos lo fara' anche meglio, ma per ora come sistema eguaglia e secondo me supera anche la Jlsounds. Se poi la lettura con relativo processamento la puo' fare una macchina piu' potente (es. Pc con LMS) cosi' che il NAA faccia solo il passaggio in i2s (es. con Squeezelite) tanto meglio, ma il beneficio di eliminare il trasporto mi pare decisamente auspicabile, per cui al momento non vedo alternative ai NAA arm, che sono cosi' piccoli da poter essere inseriti nello chassis del dac.. Comunque leggendo in rete mi pare che i benefici di tutta questa complicazione in piu' rispetto al solo Raspberry con Volumio non siano poi cosi' tangibili... provero'..
Chiarisco inoltre che si tratta di un sistema molto semplice, molto piu' del sistema NAA-trasporto-dac, con meno alimentatori in gioco e meno fattori influenti da tenere sotto controllo, per cui casomai i salti mortali si fanno usando il trasporto.
Infine ricordo che il mio semplicissimo desiderio era di realizzare un no-dac prelevando il segnale dsd direttamente dal NAA, senza passare per il trasporto. Non so se al momento HQPlayer lo permetta, ma sfido chiunque a dire che suonerebbe peggio! Un buon trasporto mica aggiunge qualita' al suono, casomai ne toglie di meno... tanto il segnale passerebbe per il NAA COMUNQUE.
N.B. Chiunque pensi che le mie spiegazioni di prima siano farneticanti, si vada a leggere un test di ingegneria informatica serio, non qualche thread in giro qua e la'... internet non e' tutto...

[antonellocaroli]

Ethernet-i2s? Molto interessante! Ma e' appunto quello che fa il Raspberry nel mio sistema: legge un file in rete dal server e lo passa in i2s al dac. Non ho dubbi che l'interfaccia della xmos lo fara' anche meglio, ma per ora come sistema eguaglia e secondo me supera anche la Jlsounds. Se poi la lettura con relativo processamento la puo' fare una macchina piu' potente (es. Pc con LMS) cosi' che il NAA faccia solo il passaggio in i2s (es. con Squeezelite) tanto meglio, ma il beneficio di eliminare il trasporto mi pare decisamente auspicabile, per cui al momento non vedo alternative ai NAA arm, che sono cosi' piccoli da poter essere inseriti nello chassis del dac.. Comunque leggendo in rete mi pare che i benefici di tutta questa complicazione in piu' rispetto al solo Raspberry con Volumio non siano poi cosi' tangibili... provero'..
Chiarisco inoltre che si tratta di un sistema molto semplice, molto piu' del sistema NAA-trasporto-dac, con meno alimentatori in gioco e meno fattori influenti da tenere sotto controllo, per cui casomai i salti mortali si fanno usando il trasporto.
Infine ricordo che il mio semplicissimo desiderio era di realizzare un no-dac prelevando il segnale dsd direttamente dal NAA, senza passare per il trasporto. Non so se al momento HQPlayer lo permetta, ma sfido chiunque a dire che suonerebbe peggio! Un buon trasporto mica aggiunge qualita' al suono, casomai ne toglie di meno... tanto il segnale passerebbe per il NAA COMUNQUE.
N.B. Chiunque pensi che le mie spiegazioni di prima siano farneticanti, si vada a leggere un test di ingegneria informatica serio, non qualche thread in giro qua e la'... internet non e' tutto...

Sembra una ottima alternativa, sicuro si elimina un po di roba... e a quanto pare sul Raspberry Pi 2 si puó pure installare una versione di Windows 10
Windows IoT - Get Started
chissá se riesce a girarci anche jplay...

[bigtube]

Se la vuoi vedere gia' subito, ho inserito una discussione sul tforum (cerca buffalo e unbalancer, la dovresti trovare subito), dove me l'avevano chiesta. Ma e' un'opera in continua trasformazione, a breve voglio provare inserendo un 4490 invece del Buffalo per sentire la differenza. Adesso sto lavorando alla sostituzione di alcune resistenze e condensatori di vario tipo per capire come influiscano sul suono.
P.S. Anch'io ho scelto lo stadio di uscita a tubi ed ho 2 finali OTL con 6C33C-B. Anch'io avrei usato i 1704 se li avessi trovati. Mi sa che abbiamo gusti simili...

ho visto il tuo lavoro e meriti un encomio solenne per la realizzazione.
Tuttavia tu hai detto che hai fatto un confronto con la jlSounds ma nel tua costruzione non usi quella interfaccia ma quella della diyinhk.
Non è che stai estendendo un po' il giudizio senza averla provata? potresti ribattere che sono simili ma non e proprio cosi.
Il mio interesse per il Raspy è legato soprattutto alla semplificazione e al fatto che si puo' gestire con Linux e disporre della sua potenza
In apparenza la macchina Raspy appare un po' primitiva e ha dei limiti HW ma io stesso son rimasto sorpreso quando provai a usarlo
con Volumio .
Pertanto sono incuriosito anche per colpa di tutti coloro ( anche fior di tecnici su DiyAudio ) che hanno speso molto tempo e impegno
nell'esaltare le doti e le possibilita' di questa minimacchina e che hanno relazionato molto positivamente sulle prestazioni finali.
Saranno tutti dei fessi e sordi per giunta.....non mi torna

Una curiosita' : che OTL hai costruito ?
Un suggerimento : ma hai letto il thread ( a proposito di chip R-2R NOS ) http://www.nexthardware.com/forum/cm...tml#post939081
se sei alla ricerca di un DAC con 1704 eccoti servito.

[luca72c]

Alla fine ci ho montato la diyinhk, ma prima ci avevo messo la Jlsounds, che poi ho spostato su un altro dac (dual ak4399), dove mi serviva l'uscita spdif.
Ho letto il 3d del nos, ma io non sono in grado di saldare smd e gli altri chip nos non mi convincono.
Gli OTL per ora non sono in grado di costruirli, ho preso 2 Circlotron fatti da Giovanni Morrone (progetto Marotta). Piu' in la' pero' mi cimentero'...

[marcoc1712]

Attacchi di gurofilia estiva. Poichè non riesco a vedere offese rilevanti ma solo posizioni assai differenti e neanche così stringenti tecnicamente, faccio osservare , rispettosamente per carità, che passare dal particolare all'universale sulla scorta di una esperienza personale è un'operazione quantomeno temeraria. In questo campo poi diventa impossibile, in quanto esistono fin troppe variabili ancora poco conosciute per poter dire con sicurezza che "la connessione I2S è migliore di quella USB" come pure affermare che "la USB è ininfluente". In realtà vedo una discussione interessante in prospettiva ma tecnicamente un po' prematura, almeno fino a quando XMOS non rilascerà la loro interfaccia Ethernet I2S, con la quale si potranno perlomeno eseguire test razionali tra la USB e la Ethernet a parità di circuito di elaborazione.
Esprimendo un parere assolutamente personale trovo la USB di JLSounds assai soddisfacente al momento, tanto che non mi viene grande voglia di fare tripli salti mortali carpiati accrocchiando microcomputer del tutto economici (memento la qualità delle alienazioni locali della mobo!) alla ricerca del sacro graal.
Ribadisco invece, da moderatore, l' assoluta necessità di evitare discussioni a due sul forum, se vi volete chiarire al di là delle affermazioni tecniche fatelo in privato. Ora vado a rileggere gli interventi precedenti rimuovendo quelli che ritengo ininfluenti rispetto all'argomento della discussione.
PS: i moderatori non vivono attaccati allo schermo di un PC, ergo moderatevi un po' da soli, visto che siamo tutti maggiorenni e vaccinati.

Vabbè... più che gurufilia estiva è la mia fissa decennale.... cos'è L'SB+ se non il prototipo di una interfaccia 'intelligente' tra ethernet ed il dac via I2S? Qualcuno ricorda cos'è squeezelite? Un emulatore di SB... Perchè è stato inventato? perchè Logitech ha 'suicidato' lo squeezebox... pazzi.

Quindi occhio a giudizi affrettati sul nuovo, che poi così nuovo non è.

Nel merito, l'XMOS Ethernet, è basata su un suo protocollo (Ethernet AVB, qui qualche info utile) che la renderà certamente interessante ma purtroppo, almeno inizialmente, temo non così largamente supportata, è un paradigma diverso, cui gli sviluppatori dovranno adeguarsi e credo occorrerà tempo, ma finchè non esce qualcosa nel mercato consumer, non avverrà.

Ad oggi non si può prescindere da una qualche capacità elaborativa on board, fosse anche solo quella messa a disposizione da uno switch, per gestire correttamente la connessione ethernet e l'applicazione di rendering (squeezelite, il daemon di HQP o...), quindi le strade praticabili sono sostanzialmente due:

a. piattaforma legacy con firmware proprietario, stile squeezebox.
b. piattaforma generalista che supporti i sistemi operativi (e di conseguenza le applicazioni) più diffuse.

lasciando stare a, b oggi è praticamente arm per i SOC, NUC o comunque micro PC intel (es. Fitlet b) oltre al pc 'tradizionale'.

Il supporto ad I2S ha preso piede con il PI a causa di un suo difetto che rendeva poco praticabile l'USB, oggi si sta diffondendo, a mio avviso con molte ragioni, ma purtroppo troppo spesso sulla scorta di una nuova (che poi è tutt'altro che nuova) moda e parola d'ordine, al di fuori di ogni considerazione razionale sui rapporti di costo e valore dei singoli oggetti, nonchè sulla effettiva convenienza di mettere un PI (o un BBB) dentro il case di un dac, a pochi cm di distanza...

Su una cosa io e te conveniamo: la qualità costruttiva di questi SOC non è certament 'military' e nemmeno 'medical' grade... Ottimi apparecchi, con uno strepitoso rapporto qualità (sonora ottenibile) /prezzo, ma nessun pasto è gratis, mai.

Per fortuna, sono sicuramente in arrivo novità interessanti, il settore di IOT porterà sicure evoluzioni nella disponibilità di SOC generalisti ma sempre più piccoli ed integrabili all'interno di soluzioni mirate ai diversi settori.

Stando agli analisti, questo sarà uno dei pochi mercati dinamici per l'IT nei prossimi anni, anche Microsoft con windows 10 guarda avanti in questa direzione, quindi, farà eccezione solo l'audio 'hi end'? Non credo proprio...

Scusate se ho voluto esprimere la mia opinione in merito, come so fare e secondo il mio stile, nessuno è obbligato a leggere o a commentare.

[marcoc1712]

... come pure affermare che "la USB è ininfluente"....

A volte - molto rararamente - mi viene il sospetto di perdere il controllo sulla tastiera, quindi rileggo quanto ho scritto e... dove avrei detto questa cosa, cui non credo assolutamente?

Mi pare di aver asserito esattamente il contrario, specificando però che le differenze non sono da cercarsi nei 'bit persi' a causa di 'manipolazioni del segnale'.

Pare che sia una castroneria talmente grossa da non poter essere scritta qui e nel 2015... E perchè mai?

[marcoc1712]

Pertanto sono incuriosito anche per colpa di tutti coloro ( anche fior di tecnici su DiyAudio ) che hanno speso molto tempo e impegno
nell'esaltare le doti e le possibilita' di questa minimacchina e che hanno relazionato molto positivamente sulle prestazioni finali.
Saranno tutti dei fessi e sordi per giunta.....non mi torna...

Giovanni, non sono ne fessi ne tantomeno sordi, ti posso assicurare che, avendo collaborato attivamente per portare LMS/squeezelite in Volumio e quindi sul PI, è una soluzione con rapporto qualità/costo stratosferico e quello che avevo usato io per le prove oggi suona a casa di un amico felicissimo di averlo. Non l'ho provata con il Buffalo, ma già con uno dei DAC su dougther board di 'medio' costo (80€, se ricordo bene) se la cava alla grande, se lo alimenti bene e non pretendi risoluzioni impossibili.

Per chi lo ha già, usatelo, senza se e senza ma!

Per chi lo deve comprare, pensateci bene, ci sono oggi alternative (sempre in ARM) che sulla carta sono di maggiore qualità progettuale e costruttiva e che in Volumio stesso dicono andare meglio, una di queste è il CUBOX, che già conoscete, o comunque basate su freescale i.mx6, per esempio la italianissima UDOO.

Personalmente continuo a preferire la ALIX con Voyage, ma la differenza non è certo abissale. Attendo i tuoi confronti con il Futro.

[luca72c]

Nel dire "manipolazioni" ho usato un termine improprio, ma devi capire che scrivo da un cellulare mentre percorro sentieri di montagna...
In realta' non si tratta di manipolazione, ma di un "riaggiustamento" del timing dei dati ricevuti via usb per riadattarli al dac, a cui vengono passati in i2s.
Quindi c'e' un primo passaggio dal NAA alla usb e poi un altro dalla usb in i2s. Ogni passaggio necessita di un processamento per l'"aggiustamento" del timing e ogni volta qualcosa viene perso, per forza, e interpolato (il famoso fenomeno del jitter, che si puo' ridurre all'infinitesimo ma non eliminare).
Visto che il primo passaggio, da ethernet o disco a usb, svolto dal player, non si puo' eliminare, tanto vale lasciare un solo passaggio: da player a dac, eliminando la perdita (seppur ridotta) introdotta dal trasporto.
Come e' spiegato nella pagina che ho linkato prima.

[luca72c]

Aggiungo una cosa: ho anche un Udoo quad, macchina ben piu' prestante del Raspberry e poco piu' costosa. L'ho usata a lungo per pilotare un dac via usb (con la Jlsounds), con Volumio.
Beh, il mio attuale sistema suona meglio. Perche', se l'Udoo e' piu' potente?
Semplice, per il collegamento diretto via i2s, che con l'Udoo - nonostante sulla carta sia previsto - ancora non e' stato implementato via software.
Questo dimostra che il collegamento diretto via i2s influisce di piu' della capacita' di calcolo.
Come dicevo piu' sopra, pero', al momento il sistema migliore mi sembra il BBB (che supera alcuni limiti del Raspberry) con le schede di isolamento e reclock della TPA: tutti i problemi di clock vengono risolti e si mantiene il passaggio "corto" da player a dac in i2s.

[marcoc1712]

Va bene, dai scusami di nuovo, puo' succedere di avere idee diverse, non muore nessuno.
Ma per favore dai un'occhiata pure a questa pagina (non e' molto tecnica, ma rende l'idea): https://volumio.org/raspberry-pi-i2s...ounds-so-good/
E a questo 3d:
Building an open embedded audio applicance. - diyAudio
(ma in rete puoi trovare molto altro materiale in proposito).
Per il resto, per me amici come prima.

Secondo me non hai capito - o non sono riuscito a spiegarti - che io sono forse più convinto di te che la strada che indichi sia quella giusta, tanto che - se guardi la mia firma - io uso l'antesignano delle interfacce Ethernet/DAc via I2s: Lo squeezebox, in particolare lo SB+ che è uno squeezebox a cui è stato sostituito tutto quello che viene dopo la IS2 e l'alimentazione, bada bene che lo uso perchè lo reputo ancora meglio di altre soluzioni (v. mio recente thread, 'paradigma' dell'errore nel forum).


Nel tempo ho seguito il progetto di replica dello SB mediante una WanBoard con Linux, selezionata al posto del PI - ed era il 2011 - perchè giudicata di migliore qualità dagli esperti del forum, tra cui John Swenson, vero o meno che fosse, quel progetto è naufragato e dalle sue ceneri ne sono nati diversi altri, tra cui Daphile e Sueezeplug, oltre ad aver provocato l'attuale diffusione di squeezelite.

Fai un giro - se vuoi - tra i thd che ho aperto anche solo qui nel tempo e te ne renderai conto.

Conosco quei THD, in particolare il primo, dove se leggi tra i commenti, vedrai le stesse informazioni che ti ho riportato io in merito all'I2S del PI, del secondo - facendo la tara all'oste che vende il suo vino - apprezzo l'approccio, che ha messo in primo piano la 'consegna' al dac di quanto di meglio ottenibile da un segnale I2s, quindi ha cercato il modo più economico/veloce/efficace per ottenerlo, selezionando la BBB, che di suo ha meno limti del PI, poi utilizzata in quel modo è 'mascherata' (almeno logicamente).

Rimangono però inalterati i miei dubbi dettati dalla prossimità forzata della BBB al dac, dando per scontato (ma non verificato) che Hermes e Chrono siano invece stati costruiti ben sapendo che sarebbero stati messi lì.