Vai al contenuto
Melius Club

Elenco Streamer con uscita I2S.


Ultima Legione @

Messaggi raccomandati

Inviato
3 hours ago, maxgazebo said:

ma infatti se il ivello di rumore strumentale della interfaccia è trascurabile, sotto i -150dB come sulla maggior parte dei DAC recenti, gli isolatori non servono a nulla

Tutto altro discorso è invece legato alle intime sensazioni, il discorso "sento, non sento" che non va assolutamente confuso con la parte tecnico/teorica, perchè legato a soggettività e specificità intime e personali

ma che vai dicendo ,il D10s con gli isolatori guadagna 20db minimo..

Ultima Legione @
Inviato
11 ore fa, maxgazebo ha scritto:

ma un trasporto di informazione digitale che modifica l'informazione stessa per farla diventare nettamente migliore mi rifiuto anche di pensarlo

.

Bhè ..... è evidente che hai frainteso e letto superficialmente perchè l'oggetto del mio post non erano i possibili limiti del "trasporto digitale" ma bensì quelli delle "interfacce digitali" con il quale colleghiamo uno Streamer a un DAC.

.

Sapendo di parlare ad uno di .... mestiere, concordo pienamente sulla circostanza che fortunatamente gli "handshake packet" posti a chiusura delle "transazioni/pacchetti" per il controllo di parità nel mondo delle comunicazioni asincrone su IP, garantiscono pienamente l'integrità dell'informazione che se và bene così come è per mandare in orbita un satellite o far funzionare Internet nel mondo, va sicuramente anche bene per fare viaggiare uno streaming musicale dai Server ove risiede la nostra amata Musica, ovunque essi si  trovino nel mondo, sino alla presa RJ-45 del nostro Streamer. 

.

I possibili problemi e i margini di miglioramento al quale mi riferivo nel mio post sono invece riferiti a quelle che succede dopo......... ovvero al modo migliore per veicolare verso il DAC lo streaming di dati una volta che il Network Player o lo Streamer li ha pescati dalla Rete LAN/WAN intercettandoli sul NAS domestico o sul Server del fornitore di servizi di Musica.

.

E qui gli ambiti di valutazione meramente tecnica e le problematiche peculiari delle Interfacce Seriali Asincrone o Adattive che siano (S/PDIF Coax-RCA, Ottiche-TosLink, AES/EBU-XLR, USB e I2S-LVDS), sono completamente diverse e senza possibilità di similitudine e sovrapposizione con quelle invece tipiche del Protocollo TCP-IP che governa il mondo INTERNET e LAN/WAN.

.

Inviato
1 ora fa, Ultima Legione @ ha scritto:

.

Bhè ..... è evidente che hai frainteso e letto superficialmente perchè l'oggetto del mio post non erano i possibili limiti del "trasporto digitale" ma bensì quelli delle "interfacce digitali" con il quale colleghiamo uno Streamer a un DAC.

.

Sapendo di parlare ad uno di .... mestiere, concordo pienamente sulla circostanza che fortunatamente gli "handshake packet" posti a chiusura delle "transazioni/pacchetti" per il controllo di parità nel mondo delle comunicazioni asincrone su IP, garantiscono pienamente l'integrità dell'informazione che se và bene così come è per mandare in orbita un satellite o far funzionare Internet nel mondo, va sicuramente anche bene per fare viaggiare uno streaming musicale dai Server ove risiede la nostra amata Musica, ovunque essi si  trovino nel mondo, sino alla presa RJ-45 del nostro Streamer. 

.

I possibili problemi e i margini di miglioramento al quale mi riferivo nel mio post sono invece riferiti a quelle che succede dopo......... ovvero al modo migliore per veicolare verso il DAC lo streaming di dati una volta che il Network Player o lo Streamer li ha pescati dalla Rete LAN/WAN intercettandoli sul NAS domestico o sul Server del fornitore di servizi di Musica.

.

E qui gli ambiti di valutazione meramente tecnica e le problematiche peculiari delle Interfacce Seriali Asincrone o Adattive che siano (S/PDIF Coax-RCA, Ottiche-TosLink, AES/EBU-XLR, USB e I2S-LVDS), sono completamente diverse e senza possibilità di similitudine e sovrapposizione con quelle invece tipiche del Protocollo TCP-IP che governa il mondo INTERNET e LAN/WAN.

.

Scusami ma non capisco...cosa c'entra il protocollo IP?  Non si parlava di USB vs. I2S? Il protocollo USB controlla l'integrità dei dati/informazione in arrivo rispetto a quelli di partenza, I2S no...questo intendevo

Quindi il modo di portare informazione dalla sorgente (streamer, p.e.) al DAC, e quindi USB 2.0 o I2S

Magari sbaglio? :classic_rolleyes:

Inviato
54 minuti fa, maxgazebo ha scritto:

Il protocollo USB controlla l'integrità dei dati/informazione in arrivo rispetto a quelli di partenza

Gli esperti mi correggeranno ma, se la connessione usb è asincrona e cioè comanda il clock del DAC, non c’è controllo di integrità e ritrasmissione ma solo il controllo del CRC e l’eventuale scarto del pacchetto non valido, non è così? 

  • Thanks 1
Ultima Legione @
Inviato
1 ora fa, alanford69 ha scritto:

Gli esperti mi correggeranno ma, se la connessione usb è asincrona e cioè comanda il clock del DAC, non c’è controllo di integrità e ritrasmissione ma solo il controllo del CRC e l’eventuale scarto del pacchetto non valido, non è così? 

.

Giustissimo e infatti è proprio così e aggiungo che quello ......"scarto" del pacchetto non valido, da parte del ricevitore USB (Amanero o XMOS che sia), viene sostituito con tanti begli ZERI riempitivi con buona pace di tutte le aspettative di illusorio Bit Perfect.:classic_biggrin::classic_biggrin:

.

Non a caso l'USB per lo specifico impiego audio, definito e regolato dal protocollo MTP - Media Transfer Protocol , a differenza di quello MSC - Mass Storage Class  (che è lo standard di specifiche USB per la connessione di unità di memoria rimovibili), utilizza una modalità di Trasferimento Isocrono (nella specifica sottomodolalità Asincrona che tutti conosco) per le sue caratteristiche in tempo reale, ma che ovviamente avviene a scapito del tempo necessario al recupero degli errori.

.

Ovvero nella modalità Isocrona/Asicrona usata dal procollo MTP, la larghezza di banda è garantita ma tuttavia, non può essere garantito e non viene eseguito alcun riconoscimento o ritrasmissione dei pacchetti in caso di errore a ben differenza di quanto invece prevede e fà il protocollo MSC quando per esempio colleghiamo la nostra stampantina o l'unità hard-disk esterna al nostro PC e che non può certo permettersi il lusso di perdere un solo bit di quelli trasferiti e da memorizzare o stampare. 

.

Morale della favola e per quanto shoccante :classic_laugh::classic_laugh: possa magari essere per l'Audiofilo, l'USB asincrono dei nostri amati DAC, nella sua costituzione ed essenza funzionale è un collegamento seriale di tipo Lossy e quindi anche con possibile perdita di dati.

.

.

P.S. Ritengo pertanto soddisfatta anche la risposta anche a @maxgazebo pur dovendo nettamente smentire la sua convinzione in merito alla presunta, ma ahìme assolutamente non vera, integrità dei dati/informazione in arrivo rispetto a quelli di partenza in un collegamento tra Streamer e DAC quando si usa l'interfaccia USB.

.

 

maxgazebo
Inviato
8 ore fa, Ultima Legione @ ha scritto:

P.S. Ritengo pertanto soddisfatta anche la risposta anche a @maxgazebo pur dovendo nettamente smentire la sua convinzione in merito alla presunta, ma ahìme assolutamente non vera, integrità dei dati/informazione in arrivo rispetto a quelli di partenza in un collegamento tra Streamer e DAC quando si usa l'interfaccia USB.

Azz...onestamente che l'USB sostituisse il dato mancante con degli zeri non la sapevo...insomma...ma comunque penso che questa possibilità sia ben più remota rispetto alla I2S, credo sia indubbio il fatto che USB 2.0 sia interfaccia più affidabile per collegamenti esterni e lunghi rispetto ad I2S

Diciamo che per me l'utilizzo di I2S è una "forzatura" inutile, in quanto non restituisce vantaggi particolari rispetto a USB 2.0, ma alla fine invece svantaggi essendo più "delicata" e soggetta ad errori

Fermo restando che la banda passante necessaria a trasferire l'informazione di un brano musicale per HiRes che possa essere sia molto largamente soddisfatta da entrambe

Poi che ci si associ una differenza all'ascolto alzo le mani, usciamo dalla sfera del dimostrabile scientificamente per cui vale tutto ed il suo contrario

Gustavino
Inviato
1 hour ago, maxgazebo said:

Azz...onestamente che l'USB sostituisse il dato mancante con degli zeri non la sapevo...insomma...ma comunque penso che questa possibilità sia ben più remota rispetto alla I2S, credo sia indubbio il fatto che USB 2.0 sia interfaccia più affidabile per collegamenti esterni e lunghi rispetto ad I2S

Diciamo che per me l'utilizzo di I2S è una "forzatura" inutile, in quanto non restituisce vantaggi particolari rispetto a USB 2.0, ma alla fine invece svantaggi essendo più "delicata" e soggetta ad errori

 

sono solo tuo opinioni frutto di pregiudizi tecnicamente lvds e' ottima

Gustavino
Inviato
9 hours ago, Ultima Legione @ said:

.

Giustissimo e infatti è proprio così e aggiungo che quello ......"scarto" del pacchetto non valido, da parte del ricevitore USB (Amanero o XMOS che sia), viene sostituito con tanti begli ZERI riempitivi con buona pace di tutte le aspettative di illusorio Bit Perfect.:classic_biggrin::classic_biggrin:

.

Non a caso l'USB per lo specifico impiego audio, definito e regolato dal protocollo MTP - Media Transfer Protocol , a differenza di quello MSC - Mass Storage Class  (che è lo standard di specifiche USB per la connessione di unità di memoria rimovibili), utilizza una modalità di Trasferimento Isocrono (nella specifica sottomodolalità Asincrona che tutti conosco) per le sue caratteristiche in tempo reale, ma che ovviamente avviene a scapito del tempo necessario al recupero degli errori.

.

Ovvero nella modalità Isocrona/Asicrona usata dal procollo MTP, la larghezza di banda è garantita ma tuttavia, non può essere garantito e non viene eseguito alcun riconoscimento o ritrasmissione dei pacchetti in caso di errore a ben differenza di quanto invece prevede e fà il protocollo MSC quando per esempio colleghiamo la nostra stampantina o l'unità hard-disk esterna al nostro PC e che non può certo permettersi il lusso di perdere un solo bit di quelli trasferiti e da memorizzare o stampare. 

.

Morale della favola e per quanto shoccante :classic_laugh::classic_laugh: possa magari essere per l'Audiofilo, l'USB asincrono dei nostri amati DAC, nella sua costituzione ed essenza funzionale è un collegamento seriale di tipo Lossy e quindi anche con possibile perdita di dati.

.

.

P.S. Ritengo pertanto soddisfatta anche la risposta anche a @maxgazebo pur dovendo nettamente smentire la sua convinzione in merito alla presunta, ma ahìme assolutamente non vera, integrità dei dati/informazione in arrivo rispetto a quelli di partenza in un collegamento tra Streamer e DAC quando si usa l'interfaccia USB.

.

 

Esatto  come non quotarti

  • Thanks 1
PippoAngel
Inviato

@Ultima Legione @ Allora la connessione migliore in assoluto è ancora la ethernet con protocollo UPnP/DLNA verso un dac con ingresso renderer ?

Gustavino
Inviato
21 minutes ago, PippoAngel said:

@Ultima Legione @ Allora la connessione migliore in assoluto è ancora la ethernet con protocollo UPnP/DLNA verso un dac con ingresso renderer ?

 in fibra però...Anche se del rumore viene comunque convertito

stefano_mbp
Inviato
16 ore fa, Ultima Legione @ ha scritto:

viene sostituito con tanti begli ZERI riempitivi

Questa bufala dove l’hai letta?

Gustavino
Inviato
49 minutes ago, stefano_mbp said:

Questa bufala dove l’hai letta?

se ne ignori il funzionamento non possiamo farci nulla

stefano_mbp
Inviato

“I2S (Inter-IC Sound) does not have a built-in error correction mechanism; it is a digital audio protocol designed for simplicity, not robustness against errors.”

  • Melius 1
Gustavino
Inviato
4 minutes ago, stefano_mbp said:

“I2S (Inter-IC Sound) does not have a built-in error correction mechanism; it is a digital audio protocol designed for simplicity, not robustness against errors.”

neanche usb2 audio ha  la correzione degli errori :classic_rolleyes:   se avvengono immette  silenzio  tramite gli ZERIIIII

  • Melius 1
maxgazebo
Inviato
1 ora fa, stefano_mbp ha scritto:

Questa bufala dove l’hai letta?

Ah beh...andiamo bene! :classic_sad: ma quindi non è vero che la USB 2.0 corregge gli errori con degli zero?  :classic_mellow:

ildoria76
Inviato
10 minuti fa, maxgazebo ha scritto:

Ah beh...andiamo bene! :classic_sad: ma quindi non è vero che la USB 2.0 corregge gli errori con degli zero?  :classic_mellow:

" 2. Trasferimento Audio (Modalità Isochronous)

La situazione cambia radicalmente per l'audio digitale (come nel caso del GUSTARD U18 che invia dati ad un DAC). Per garantire un flusso temporale costante (necessario per la riproduzione del suono in tempo reale), l'audio USB utilizza la modalità Isochronous (Isocrona).

Priorità al Tempo: La modalità Isochronous garantisce la larghezza di banda e la latenza (ovvero, i dati arrivano con una cadenza costante).

Nessuna Ritrasmissione: In questa modalità, NON è prevista la ritrasmissione dei pacchetti in caso di errore. Se il DAC dovesse aspettare un pacchetto ritrasmesso, ci sarebbe un ritardo nel flusso audio che causerebbe un evidente drop-out (interruzione).

Gestione degli Errori: Se il ricevitore (il DAC) rileva un pacchetto danneggiato tramite il CRC:

Il DAC scarta il pacchetto corrotto.

Il DAC deve riempire il "buco" nel flusso di campioni audio in tempo reale.

Qui entra in gioco la questione degli "zero" (o di una forma di interpolazione):

Quando un pacchetto (che contiene campioni audio) viene scartato, il DAC ha un'interruzione di dati e deve decidere cosa riprodurre per mantenere la continuità. Se non ha un algoritmo di "riparazione" sofisticato:

Il DAC può tentare una semplice interpolazione (es. calcolare un valore intermedio tra il campione prima dell'errore e quello dopo l'errore, se il ritardo non è troppo grande).

Se l'errore è più grave o il DAC è più basilare, la soluzione più semplice è sostituire i campioni mancanti con un valore pari a zero (silenzio totale o "muting"). Questo previene la riproduzione di rumore digitale casuale e ad alto volume, manifestandosi come un breve click o un drop-out (silenzio).

In sintesi: non è il protocollo USB 2.0 in sé a "correggere con degli zero", ma è il ricevitore (il DAC) che, non potendo richiedere la ritrasmissione dei dati nel flusso isocrono, deve adottare una strategia di emergenza (come lo zero o l'interpolazione) per mascherare la perdita di dati.

Il GUSTARD U18, come DDC, serve proprio a ridurre al minimo la probabilità di questi errori di trasmissione (CRC falliti) ripulendo il segnale e inviandolo con un clock molto più stabile. "

  • Melius 1
  • Thanks 1
Gustavino
Inviato
11 minutes ago, maxgazebo said:

Ah beh...andiamo bene! :classic_sad: ma quindi non è vero che la USB 2.0 corregge gli errori con degli zero?  :classic_mellow:

immettere zeri non corregge affatto il dato perso ! evita solo che ci siano  glitch click durante la riproduzione

  • Melius 1
Ultima Legione @
Inviato

@ildoria76

.

Egregio,

.

per la risposta molto più che chiara, oggettiva e impeccabile e che mi sgrava dall'iniziativa della replica, ti ringrazio personalmente anche perchè stavo già abbozzando una risposta che ricorrendo alla analitica spiegazione dei polinomi funzionali sul quale si basano le logiche Controllo di Ridondanza Ciclica (CRC) nel caso di una trasmissione dati Isocrona, però mi avrebbe portato ampiamente O.T. e fuori contesto dal senso e dalla logica di questo Thread.

.

Ma sopra tutto, mi rendo conto, avrebbe dato veramente troppa importanza ai falsi ....."San Tommaso" tra i quali spicca sicuramente il buon @stefano_mbp al quale con l'occasione dico che:....... in genere le "Bufale" le mangio e non le riporto bovinamente quando le leggo e né tanto meno consento mai questi toni sgarbati a coloro con il quale mi relaziono e ancor meno se a queste persone, come nel Tuo caso, ho anche offerto la mia personale stima ma che completamente incapaci della seppur minima forma di Tatto, Stile ed Eleganza di modi, l'hanno però bellamente buttata nel cesso.

.

Quindi da questo momento in poi ti pregherei di ignorarmi quando mi incroci nei thread e sicuramente farò io ricambiando l'apprezzata cortesia. 

.

  • Melius 1

Crea un account o accedi per lasciare un commento

Devi essere un membro per lasciare un commento

Crea un account

Iscriviti per un nuovo account nella nostra community. È facile!

Registra un nuovo account

Accedi

Sei già registrato? Accedi qui.

Accedi Ora
×
×
  • Crea Nuovo...