Uscita I2S per HQPlayer-NAA

[marcoc1712]

Probabilmente sbaglio io, magari, puoi indicarmi quale soc produce i2s> 16 bit?

Inviato dal mio XT1068 utilizzando Tapatalk

[DacPassion]

Chi ha seguito la discussione chilometrica su diyaudio sa dirmi se ci sono delle motivazioni per la scelta di TP di usare il bbb invece del raspberry o altri?

[bigtube]

Allora, scusate l'assenza per qualche ora..
Con il Raspberry il limite e' di 24 bit e non 16. I files a 24/96 li riproduce alla grande e il risultato e' ottimo, anche senza isolamento e reclock, ripeto che non fa rimpiangere alcun trasporto: il passaggio in meno e' ampiamente sufficiente a pareggiare la minor specializzazione dell'hardware. Col BBB, pero', se non sbaglio il limite dovrebbe salire a 32 bit.
Uso il Raspberry con il P5 destinato all'i2s, lo stesso di cui si parla nel 3d della TPA (che ho segnalato prima).
Uso Volumio 1.5 ultima versione senza alcun codice aggiuntivo, il PCM va senza problemi, ma il dsd per ora no.
Quello che vorrei fare sarebbe usare un BBB con le schede TPA, uscendo in dsd tramite un no-dac. Ovviamente serve un server che si occupi della conversione PCM-dsd e dell'upsampling: squeezebox + Volumio potrebbero andare bene?

Luca se le cose stanno come dici tu sarei io il piu' contento. Puoi darci un riferimento dove si parla di questo. Son fermo alle conoscenze che oltre i 16 bit non si và.
comunque mi sembri troppo severo nel giudicare le XMOS. il segnale trasportato in asincrono sempre quello è, anche se il protocollo ethernet è superiore . Sempre che
la macchina di elaborazione sia di livello elevato e finora ARM ha dei limiti

[luca72c]

Mi fa sorridere l'accostamento, non i due componenti separatamentete. Comunque trovò paradossale essere sotto tiro per questo, sono stato certamente un pioniere e riconosco tantissimi meriti a queste soluzioni, ma giocoforza hanno dei limiti economici con cui misurarsi. Metteresri un multijet su una Lotus?

Inviato dal mio XT1068 utilizzando Tapatalk

Tranquillo, non sei sotto nessun tiro, volevo solo capire se ci sono soluzioni piu' prestanti come NAA con uscita i2s, anche piu' costose.
Pare che non ci siano, quindi al momento l'hi end (limite superiore) di questo tipo di soluzione e' il BBB con le schede TPA.
Ora si tratta di riuscire a farlo suonare uscendo in dsd tramite le uscite i2s, e che sia il dsd migliore ottenibile da un PCM. Squeezebox e' all'altezza di HQPlayer? Se si, con l'accoppiata Squeezebox server e Volumio client, la cosa sembrerebbe fattibile...

[marcoc1712]

Con la versione ufficiale di sox lms

Inviato dal mio XT1068 utilizzando Tapatalk

[marcoc1712]

Scusate, dicevo, con la versione ufficiale di sox LMS non fa conversione PCM 2 DSD, quindi o provi il fork di sox di. Cui si e recentemente parlato o usi altro.

Inviato dal mio XT1068 utilizzando Tapatalk

[luca72c]

Luca se le cose stanno come dici tu sarei io il piu' contento. Puoi darci un riferimento dove si parla di questo. Son fermo alle conoscenze che oltre i 16 bit non si và.
comunque mi sembri troppo severo nel giudicare le XMOS. il segnale trasportato in asincrono sempre quello è, anche se il protocollo ethernet è superiore . Sempre che
la macchina di elaborazione sia di livello elevato e finora ARM ha dei limiti

La risposta la trovi nel 3d della TPA. E' ovvio che qualsiasi limite di bit e' un limite software, non hardware, al massimo legato alla potenza di elaborazione: per questo alla TPA hanno scelto il BBB invece del Raspberry.
Tutto quello che dico passa per la mia esperienza personale, non sono cosi' tecnico da fare dissertazioni, ma le orecchie ce l'ho anch'io: per quello sono cosi' deciso nel dire che le xmos non suonano meglio del Raspberry in i2s, semplicemente perche' l'ho provato.
Nel mio dac monto tutte e due, percio' posso fare confronti praticamente in contemporanea. L'xmos forse e' appena piu' precisa nei dettagli, ma come musicalita' e piacevolezza e' inferiore. Sono sicuro che col reclock della TPA non c'e' piu' nulla a favore della xmos.
Semplicemente e' un passaggio in piu', che non puo' che rovinare - seppur di poco - il segnale originario.
Sul sito di Volumio trovate una spiegazione un po' piu' tecnica...
A parte che non capisco come un chip xmos da pochi euro possa avere una potenza di calcolo maggiore di una cpu arm, magari dual o quad core, ricordatevi che nel caso dell'uscita in i2s il NAA NON FA lo stesso lavoro che fa la xmos, semplicemente quel lavoro non serve piu'. Il resto del lavoro del NAA e' lo stesso che farebbe anche con la xmos...

[marcoc1712]

Il limite ai soli 16 bit del bus è comune a tutti soc basati su arm, agendo a livello software (es. Driver di scheda audio) è possibile aggirarlo, ma non mi risulta venga fatto, almeno non da bbb o arduino come tali. Come si rifletta sul suono, non saprei.

Inviato dal mio XT1068 utilizzando Tapatalk

[luca72c]

Il limite ai soli 16 bit del bus è comune a tutti soc basati su arm, agendo a livello software (es. Driver di scheda audio) è possibile aggirarlo, ma non mi risulta venga fatto, almeno non da bbb o arduino come tali. Come si rifletta sul suono, non saprei.

Inviato dal mio XT1068 utilizzando Tapatalk

Ragazzi, che un file a 24 bit non possa passare per un bus hardware a 16 bit e' una delle piu' grandi castronerie che ho mai sentito. E' come dire che un pc non puo' riprodurre un file a 128 bit perche' il processore e' a 64 bit... cosa c'entra? Forse i pc x86 o x64 che riproducono files a 128 bit o files dsd256 hanno tutti i bus hardware interni a 128 o 256 bit?

[marcoc1712]

E chi lo ha mai detto?

Inviato dal mio XT1068 utilizzando Tapatalk