Streaming vs cd, una riflessione

[davenrk]

3 ore fa, Turandot ha scritto:

Non capisco cosa vuoi dire

Un CD rippato verrà comunque riprodotto attraverso hardware+software tipo mini-PC, di solito su base Linux, all' interno del "lettore", per cui suonerà diverso dallo stesso CD riprodotto attraverso la normale meccanica, senza ripping. Ovviamente si parla in generale, non di uno specifico apparecchio.

[TetsuSan]

4 minuti fa, davenrk ha scritto:

Ovviamente si parla in generale, non di uno specifico apparecchio.

E qui casca l'asino. Se attraverso "uno specifico apparecchio" che consente di ragionare "a parità di" non senti differenze, le differenze stesse sono dovute al sistema di riproduzione, non al software che stai ascoltando.

Cionondimeno il distinguo è da fare tra "musica liquida - files" ricavata da fonte più che certa (ripping o download non fa differenza) e "streaming" (riproduzione di un flusso di dati di provenienza non univoca, magari elaborati attraverso qualche algoritmo). In definitiva ci sono 3 variabili in gioco :

- il contenuto (cioè COSA ascolto)

- Il contenitore (cioè ATTRAVERSO COSA o PER MEZZO DI COSA posso ascoltare)

- il sistema di riproduzione ( per il digitale, (meccanica cd o streamer) + (dac) + stadio di uscita analogico)

Se non si ragiona " a parità di" ogni confronto è inevitabilmente influenzato dalle altre variabili.

[davenrk]

@TetsuSan va bene, la mia era una precisazione in merito all' utilizzo di una meccanica CD, senza ripping. Non entro nel merito dello streaming perché è influenzato da "n" altre variabili (rete, switch, cavi, ecc ecc ecc).

[Turandot]

59 minuti fa, davenrk ha scritto:

Un CD rippato verrà comunque riprodotto attraverso hardware+software tipo mini-PC, di solito su base Linux, all' interno del "lettore", per cui suonerà diverso dallo stesso CD riprodotto attraverso la normale meccanica, senza ripping. Ovviamente si parla in generale, non di uno specifico apparecchio.

per il paragone avrei in mente un innuos, con cui si può rippare nello stesso apparecchio e ascoltare la stessa produzione poi chesso su quobuz.

rockna ad esempio potrebbe riprodurre il disco e andare anche di streaming

pur essendo stessi apparecchi a fare la stessa cosa i risultati saranno differenti per la natura del file oringinale che ci è sconosciuta

[pro61]

6 ore fa, mastergiven ha scritto:

È una tecnica di trasmissione asincrona

Asincrona, appunto, quindi non c'è sincronia fra trasmettitore e ricevitore, per cui il cavo c'entra niente.

[mastergiven]

15 ore fa, pro61 ha scritto:

Ma sto tizio parla di trasferimento isocrono, che mi risulta non essere più utilizzato. I dac hanno tutti trasferimento asincrono, quindi il problema non si pone.

Ma hai capito di cosa si parla?

Tu hai affermato quanto ti ho riportato qui sopra e io ti ho dimostrato che isocrono non significa sincrono, anzi é una tecnica asincrona.

 

[mastergiven]

55 minuti fa, pro61 ha scritto:

Asincrona, appunto, quindi non c'è sincronia fra trasmettitore e ricevitore, per cui il cavo c'entra niente.

Poi qust’ altra idiozia. Cioé, se la trasmissione é sincrona il cavo ha importanza, altrimenti no?

A volte mi chiedo se il fatto che su un forum chiunque possa dire la propria sia effettivamente un bene…

[pro61]

12 minuti fa, mastergiven ha scritto:

isocrono non significa sincrono

Vedo che hai le idee confuse. Isocrono significa "stesso tempo", io parlo e nello stesso tempo tu ascolti.

Asincrono significa che io scrivo un messaggio e tu lo leggi dopo un certo tempo.

La trasmissione isocrona può essere sincrona, asincrona e adattiva. Nelle trasmissioni audio si usa o l'asincrona o l'adattiva, non la sincrona.

Il tizio nell'articolo parla di trasmissione REAL TIME e perciò da importanza al cavo, ma questo non è vero. 

Sia i player che i DAC hanno un buffer che può essere configurato all'occorrenza, proprio per evitare problemi di perdita dati.

Sarebbe bello se certuni, prima di dare dell'idiota al altri, si guardassero un po allo specchio.

[mastergiven]

12 minuti fa, pro61 ha scritto:

Asincrono significa che io scrivo un messaggio e tu lo leggi dopo un certo tempo.

No, guarda, non ci siamo proprio, con tutto il rispetto.

Nella trasmissione sincrona, i due dispositivi che comunicano devono essere sincronizzati, appunto, e collegati allo stesso segnale di clock. Nella trasmissione asincrona non c’é esigenza di sincronizzazione, il clock é gestito esclusivamente dal ricevente che gestisce il flusso dei dati.

Non é questione di leggere dopo un certo tempo.

Poi il fatto di aver scritto un idiozia non significa che chi l’ha scritta é un idiota. Potrebbe essere semplicemente mal informato o ignorante della materia.

[ilmisuratore]

Il protocollo USB isocrono invia pacchetti di dimensione fissa ad intervalli regolari (generalmente ogni 125us) 

Il protocollo isocrono non trasporta il clock master di riferimento ma soltanto un clock per dare ordine alle trame

Si definisce trasmissione "asincrona" in quanto il clock master di riferimento viene ricostruito nel device tramite oscillatori propri e risulta indipendente dal clock che da ordine alle trame 

Piccole irregolarità di temporizzazione vengono tamponate tramite delle memorie fifo e/o buffer

 

[captainsensible]

21 minuti fa, ilmisuratore ha scritto:

Il protocollo isocrono non trasporta il clock master di riferimento ma soltanto questo per dare ordine alle trame

Mi sa che non è così: il segnale di clock del convertitore viene ricavato da quello dell'host (computer).

E non potrebbe essere diversamente, non essendo previsto un handshake. se ci fossero delle differenza di clock tra i due si perderebbero dei dati.

 

CS

[ilmisuratore]

18 minuti fa, captainsensible ha scritto:

Mi sa che non è così: il segnale di clock del convertitore viene ricavato da quello dell'host (computer).

E non potrebbe essere diversamente, non essendo previsto un handshake. se ci fossero delle differenza di clock tra i due si perderebbero dei dati.

CS

 

Entriamo nei dettagli 

Ai fini del jitter del DAC l'unica cosa essenziale è chi stabilisce il
clock...il fatto che il clock del DAC venga generato sul posto
attribuisce ogni responsabilità del jitter all'oscillatore 'locale'

 

La modalità isocrona permette l'invio di pacchetti di dati di
dimensione fissa ad intervalli di tempo regolari

Un nodo, detto Cycle Master, è incaricato di inviare un pacchetto di sincronizzazione (detto
Cycle Start Packet) ogni 125 microsecondi

Il chip che sta a monte del bus è cycle master, vale a dire che il pacchetto di sincronizzazione lo invia lui
Naturalmente detti pacchetti sono solo segnali di arbitraggio non clock
IIS o SPDIF cioè clock di riferimento, e serve specificamente ad arbitrare il sistema e
a dare un ordine alle trame

 

Il clock interno nel DAC fa la lettura dei campioni e il pilotaggio dei
convertitori
Il clock interno è usato per generare i Cycle Start Packet di
arbitraggio del bus
Il computer 'prende atto' dell'arbitraggio del bus e invia le sue
trame secondo quello che è richiesto dal collegamento
Eventuali irregolarità di trasmissione del bus saranno assorbite
dalle FIFO/BUFFER

 

 

 

 

 

 

[captainsensible]

@ilmisuratore mi sa che ti confondi perché nel sincrono il bus non è arbitrato.

Nel sincrono il funzionamento è molto simile ad una interfaccia SPDIF.

CS

[ilmisuratore]

Adesso, captainsensible ha scritto:

@ilmisuratore mi sa che ti confondi perché nel sincrono il bus non è arbitrato.

Nel sincrono il funzionamento è molto simile ad una interfaccia SPDIF.

CS

Non è stato nominato alcun protocollo "sincrono"

[captainsensible]

@ilmisuratore volevo dire isocrono (nome omen).

 

CS

[ilmisuratore]

Adesso, captainsensible ha scritto:

@ilmisuratore volevo dire isocrono, per la precisione.

CS

L'isocrono funziona esattamente per come descritto

Poi c'è anche la modalità sincrona, e asincrona bulk (con altre peculiarità)

Se le frequenze di campionamento fossero rimaste confinate entro 96 khz (max 192 khz) avremmo potuto convivere ancora con l'asincrona bulk (che fino a tali frequenze andava benissimo)

[captainsensible]

@ilmisuratore facciamo ordine (presa da copilot)

 

 

 2. Come funziona USB Audio in modalità isocrona?

A. Struttura del trasferimento

Il host USB (es. PC) invia pacchetti audio al dispositivo a intervalli regolari (tipicamente ogni 1 ms).

Ogni pacchetto contiene un certo numero di campioni audio.

Il dispositivo riceve questi pacchetti e li converte in segnale analogico (se è un DAC).

B. Gestione del clock

Ci sono tre modalità operative per USB Audio isocrono:

Modalità Master Clock

Synchronous: Master clock fornito dall'Host. Il dispositivo segue il clock del host. Poco usata per audio di qualità.

Adaptive: Master clock fornita dall'Host: Il dispositivo adatta il proprio clock al flusso dati ricevuto.

Asynchronous: Il dispositivo ha un proprio clock interno e informa il host quando inviare dati.

La modalità asincrona è preferita nei sistemi audio ad alta fedeltà perché riduce il jitter (variazioni temporali nel segnale digitale).

📦 3. Buffering e sincronizzazione

Il dispositivo audio usa buffer per gestire le variazioni nel flusso dati.

In modalità asincrona, il dispositivo comunica al host la quantità di dati che può ricevere, sincronizzando il flusso con il proprio clock interno.

 

 

Quindi, eccetto che per caso asincrono (che ha l'handshake), nelle altre modalità il clock di riferimento è derivato da quello dell'host (il computer).

 

CS

[ilmisuratore]

1 minuto fa, captainsensible ha scritto:

Asynchronous: Il dispositivo ha un proprio clock interno e informa il host quando inviare dati.

 

...ecco, questa è la modalità di cui parliamo

Asincrono vuol dire che il clock di riferimento è slegato da chi da ordine alle trame

Il protocollo è isocrono (come lo era la Firewire e il suo chip TSB) ma il clock generato localmente la rende "asincrona" 

La citazione "informa l'host quando inviare dati" viene definita in Cycle Start Packet

Se implementi un decriptor USB e tiri fuori la connection information trovi tutte le voci relative alla gestione delle trame