Uscita I2S per HQPlayer-NAA

[marcoc1712]

No, scusa, mi era parso di capire che qualcuno sostenesse che con il Raspberry o NAA similari si fosse limitati alla riproduzione a 16 bit...
NON E' ASSOLUTAMENTE COSI': il dac riceve files a 24 bit e si sentono tutti e 24 come con una xmos, anzi anche meglio. Con il BBB anche 32 bit.
Poi come questo avvenga non chidetelo a me, ma vi esorto a leggere il 3d della TPA. Per me e' chiaro che i trasporti USB NON sono il futuro, visto che i collegamenti diretti player-dac in i2s si stanno dimostrando superiori e piu' economici.
Se leggete in giro ve ne convincerete.
Quello che voglio capire e' se, con la tecnologia dsd e i no-dac, anche i dac stessi non saranno piu' necessari: non ho dubbi che un pc abbia una capacita' di elaborazione migliaia di volte superiore a qualsiasi chip dac. Si tratta di trovare il modo di sfruttarla per bene, quello della conversione in dsd potrebbe essere un modo convincente.

Ed hai capito male, io l'ho già scritto più volte che non è un limite che impedisce alcunchè, anche se i pargoni che porti centrano come i cavoli a merenda.

Su un bus I2S a 16 Bit passano ... indovina un po? 16 bit per volta. Se vuoi far passae un segnale organizzato su 32 hai due scelte:

a. Ti perdi i 16 bit meno significativi (quindi lo tratti come se fosse a 16, ...ricorda qualcosa?)
b. Usi due frame del bus per trasmettere il contenuto di un unico frame di segnale.

L' hw non sa nulla in merito, lui trasmette i 16 bit, devi farlo a livello di software e la seconda opzione complica leggermente le cose. Posso certamente non essere aggiornato, ma ripeto che non mi risulta che nessun SOC basato su ARM lo faccia nativamente, quindi o approssima ai 16 bit più significativi o il software (es. - come ho già scritto - il driver di scheda audio) si fa carico dell'ovehead, in entrambi i casi si tratta di soluzione sub ottimale.

Se sbaglio o mi sfugge qualcosa, per cortesia, oltre a scrivere che sono un cialtrone che dice castronerie, potresti riportare la versione corretta? forse imparo qualcosa anch'io.

Ti ripeto quindi la domanda: quale SOC basato su ARM è in grado di trasferire OGGI via I2s segnali > 16 bit?

Per questo motivo suonano male o - peggio - non riescono a riprodurre files a 24 bit di profondià? E chi lo ha mai detto.

[marcoc1712]

La lettura del thread di Diyaudio mi ha un po' infuocato a ritentare l'impresa fregandomene dei problemi . Sul mio Raspino non ho la contattiera P5.....è un attimo saldarla
Luca forse hai riacceso una fiammella......vengo a bastonarti se ti sei inventato tutto sulle prestazioni.........ma il tempo dove lo trovo?

Dai che per te è più facile che bere un bicchier d'acqua. Facci sapere come va in confronto al Fultro!

[marcoc1712]

Diciamo che anche il buffalo, essendo un dac asincrono, forse ci mette del suo per la buona riuscita
...è che ultimamente io sono attratto dal vecchiume :-D

...comunque se quando rientri puoi fare una prova con squeezelite per vedere se funge te ne sarei grato. Se va mi prendo un rasp e lo provo con il buffalo, però non voglio rinunciare a squeezelite.

Ovviamente poi i vari settaggi di squeezelite vanno fatti da riga di comando non c'è una interfaccia dedicata in volumio, giusto?

Giusto.

[luca72c]

Ed hai capito male, io l'ho già scritto più volte che non è un limite che impedisce alcunchè, anche se i pargoni che porti centrano come i cavoli a merenda.

Su un bus I2S a 16 Bit passano ... indovina un po? 16 bit per volta. Se vuoi far passae un segnale organizzato su 32 hai due scelte:

a. Ti perdi i 16 bit meno significativi (quindi lo tratti come se fosse a 16, ...ricorda qualcosa?)
b. Usi due frame del bus per trasmettere il contenuto di un unico frame di segnale.

L' hw non sa nulla in merito, lui trasmette i 16 bit, devi farlo a livello di software e la seconda opzione complica leggermente le cose. Posso certamente non essere aggiornato, ma ripeto che non mi risulta che nessun SOC basato su ARM lo faccia nativamente, quindi o approssima ai 16 bit più significativi o il software (es. - come ho già scritto - il driver di scheda audio) si fa carico dell'ovehead, in entrambi i casi si tratta di soluzione sub ottimale.

Se sbaglio o mi sfugge qualcosa, per cortesia, oltre a scrivere che sono un cialtrone che dice castronerie, potresti riportare la versione corretta? forse imparo qualcosa anch'io.

Ti ripeto quindi la domanda: quale SOC basato su ARM è in grado di trasferire OGGI via I2s segnali > 16 bit?

Per questo motivo suonano male o - peggio - non riescono a riprodurre files a 24 bit di profondià? E chi lo ha mai detto.

Aho', stiamo calmini, eh? Vedo che su questo forum vi scaldate un po' troppo velocemente, non c'e' un 3d che non finisca a insulti...
Non ho detto che sei un cialtrone (chi ti conosce?), ma che e' una castroneria dire che un NAA con bus a 16 bit non possa riprodurre files a 24 bit. Se tu non l'hai detto, perche' ti senti tirato in causa?
Gli esempi che ho fatto c'entrano e come, infatti si tratta dello stesso identico meccanismo ma applicato ad altri hardware. Anche un pc deve processare un'informazione a 128 bit in due tranche, ma questo non e' assolutamente un problema, visto che ha un clock di circa 3Ghz, LEGGERMENTE superiore a quello di riproduzione di un file musicale.
Se esistano o no architetture ARM con bus a piu' di 16 bit sinceramente non me ne puo' fregare di meno, e' un dettaglio tecnico che non ritengo cambi alcunche' di significativo nella riproduzione di un file audio, e i risultati lo dimostrano. Se mezzo mondo hiend (tra cui anche quelli della TPA, progettisti stimati in tutto il mondo ma che evidentemente, poverini, non sanno che i bus degli ARM sono a 16 bit) si sta ormai orientando verso soluzioni di questo tipo, qualche motivo ci sara' o no?
Occhio perche' passare da un dato tecnico ad un dato sonoro non e' affatto semplice e si rischia di fissarsi su aspetti secondari senza considerare quelli veramente significativi, in questo caso il numero inferiore di passaggi che vanno a modificare il segnale sonoro.

[bibo01]

marcoc1712 e luca72c,

se avete una questione da chiarire, spiegatevi in privato - questo è un avvertimento!

Nessun botta e risposta che non sia IN TOPIC.

Come da Regolamento, NON SONO AMMESSE REPLICHE a tale messaggio, se non in forma "privata"

[luca72c]

Grazie e scusatemi

[bigtube]

Già ho contattato un mio amico che ha un raspberry 2 :-D
Giovanni, non pensi che (come ho detto sopra) le buone prestazioni siano influenzate anche dal fatto che il buffalo è asincrono?

si Giorgio ma a me i Sabre ,peraltro ottimi DAC, non mi convincono .....non li amo, questione di preferenze personali. Tu hai anche modo
di fare confronti ad alto livello perchè hai il Buffalo......che dici il "vecchio 1541" a 16 bit nel confronto puo' ritenersi messo in discussione ?

[marcoc1712]

Vabbè.

Volevo solo precisare che in una serie di collegamenti asincroni, ove i bit vengono 'parcheggiati' in un fifo ed il clock è ricostruito, il numero e la qualità delle 'conversioni' digitali sincrone o asincrone (bit perfect, ovvio) avvenute in passaggi precedenti è assolutamente ininfluente.

Il clock è fornito dall'ultimo oscillatore, l'eventuale lavoro dei precedenti viene scartato.

In questo senso non c'è nessuna manipolazione del segnale, a meno che non si intenda come manipolazione anche la scrittura su disco, la copia da una chiavetta USB, il trasferimento da un NAS o il download da internet, passando per Wifi o Powerline.

Altri fattori, certo, possono influire sulla qualità sonora percepita, alcuni dei quali originati proprio dal funzionamentio del NAA, dell'interfaccia e financo dal buffer stesso, ma è un altro discorso, certamente importante, ma che nulla ha a che fare con le caratteristiche 'logiche' dei diversi protocolli.

Ammesso e non concesso quindi che il PI via I2s suoni meglio di XMOS via USB (valutazione soggettiva), sicuramente non è a causa delle 'minori manipolazioni del segnale', a meno di dimostrare che i bit nel fifo a valle di entrambi sono diversi, cosa che non credo, ma rimango aperto a confutazioni.

Poi non voglio essere fraintes: da sempre ritengo che la strada maestra passi da un'interfaccia ethernet per il DAC, con in mezzo il minimo di quanto strettamente necessario, ma quello ci deve essere e di ottima qualità.

[luca72c]

Ancora con tutte queste inesattezze? Che devo fare, rispondo? No perche' l'appello dei moderatori mi sembrava sensato, ma c'e' un limite alle castronerie che si possono dire, poi con tanta saccente sicurezza...

[marcoc1712]

Aspetto l'intervento dei moderatori, nel frattempo ringrazierei se le mie castornerie venissero confutate con argomenti concreti, così da poter imparare qualcosa.

L'educazione, pur gradita, non è indispensabile.

Grazie.