Briscasti M11 versus Bricasti M1.

[ilmisuratore]

Intanto fornisco una mezza idea di cosa effettua un ricevitore USB implementato dentro un DAC moderno...poi sentiremo Gustavino...

 

L'interfaccia seriale USB (SIE) gestisce il protocollo pacchetti USB per i pacchetti ricevuti e trasmessi dal ricevitore

Per i pacchetti ricevuti il SIE decodifica il campo identificativo del pacchetto (PID) per determinare il tipo di pacchetto ricevuto e per garantire che il PID sia valido

Il SIE calcola quindi il controllo di ridondanza del ciclo (CRC) dei pacchetti token e dati ricevuti e confronta il valore con il CRC contenuto nel pacchetto per verificare che il pacchetto non sia stato danneggiato durante la trasmissione

Per i pacchetti token e dati trasmessi, il SIE genera il CRC che viene trasmesso con il pacchetto

Il SIE genera anche il campo di sincronizzazione (SYNC) e il PID corretto per tutti i pacchetti trasmessi, e questo ha un clock proprio... totalmente indipendente dal clock di riferimento audio

Un'altra funzione importante del SIE è la conversione seriale-parallela dei pacchetti di dati ricevuti e la conversione parallela-seriale dei pacchetti di dati trasmessi

La USB Buffer Manager (UBM) è un gestore buffer e fornisce la logica di controllo che interfaccia il SIE con i buffer endpoint USB

Una delle principali funzioni dell'UBM è quella di decodificare l'indirizzo della funzione USB per determinare se il PC host sta indirizzando la funzione periferica USB del dispositivo (ricevitore)

Inoltre, il campo d'indirizzo endpoint e il segnale di direzione vengono decodificati per determinare quale endpoint USB specifico viene indirizzato

In base alla direzione della transazione USB e al numero endpoint, l'UBM scriverà o leggerà il pacchetto dati da o verso il buffer dati endpoint USB appropriato

La logica del timer frame USB riceve il pacchetto di inizio frame (SOF) dal PC host ogni frame USB

Ogni frame memorizza il valore del numero di frame a 11 bit dal pacchetto SOF in un registro e asserisce il segnale SOF interno

Il registro del numero di frame può essere letto, e il valore può essere utilizzato come timestamp

Per i frame USB in cui il pacchetto SOF è danneggiato o non ricevuto, la logica del timer del frame genererà un segnale pseudo start of frame (PSOF) e incrementerà il registro del numero di frame

La logica di sospensione e ripresa USB rileva le condizioni, e riapplica l'azione di sospensione e ripresa sull'USB

Questa logica fornisce anche i segnali interni utilizzati per controllare il dispositivo (il ricevitore) quando si verificano queste condizioni

È inoltre fornita la capacità di riprendere il funzionamento da una condizione di sospensione con un evento di riattivazione remoto generato localmente

In generale il ricevitore utilizza un core microcontrollore a 8 bit basato sullo standard industriale 8052..e si possono fare tantissime altre cose

Se non c'è azione di controllo qui mi taglio le pa...lle...

 

[ilmisuratore]

...aggiungo l'ultima cosa (e vi lascio in santa pace) riguardo "la qualità del clock" menzionata da Gustavino

La "qualità del clock" riguardo il controller USB c'entra quanto il formaggio sulle vongole

Il campo di sincronizzazione viene generato dal SIE con un proprio clock...anche se questo dovesse valere 1 centesimo di €

L'importante è che TUTTI i dati (non audio, come l'ignoranza fa immaginare) possano essere ricevuti (Bit-Perfect)

Proprio in questi giorni ho effettuato la prova piu esaustiva esistente riguardo la totale ininfluenza dei clock relativi ai controller USB

Quello che conta NON è il clock del SIE, bensi il clock locale che genera quello Master di riferimento audio, questi al giorno d'oggi garantiscono una precisione al femtosecondo

[31canzoni]

15 minuti fa, ilmisuratore ha scritto:

femtosecondo

Che poi sarebbe un milionesimo di miliardesimo di secondo, la cosa straordinaria è che l'audiofilo un eventuale ritardo  lo percepisce e ci soffre, gli viene mal di testa e sente suoni secchi e che lo stancano e poi litiga con la moglie e nega la paghetta ai figli.

(Si scherza ovviamente).

[granosalis]

3 minuti fa, 31canzoni ha scritto:

la cosa straordinaria è che l'audiofilo un eventuale ritardo  lo percepisce e ci soffre

Il clock ha un ruolo importante, non lo banalizzerei in maniera cosi' superficiale.

[ilmisuratore]

2 minuti fa, 31canzoni ha scritto:

Che poi sarebbe un milionesimo di miliardesimo di secondo, la cosa straordinaria è che l'audiofilo un eventuale ritardo  lo percepisce e ci soffre, gli viene mal di testa e sente suoni secchi e che lo stancano e poi litiga con la moglie e nega la paghetta ai figli.

(Si scherza ovviamente).

..beh sull'influenza del clock (tra picosecondi e femtosecondi) ci sarebbe da aprire una discussione con tanto di test

p.s ho procurato un simulatore di jitter fantastico che applica ai segnali audio qualsiasi forma di jitter:

periodico

casuale

di fase

Potendone dosare la quantità e la relativa distribuzione sullo spettro

Si possono simulare anche le diverse caratteristiche degli oscillatori in commercio, nonchè arrivare a sentire anche l'effetto di un clock difettoso

Qualche volta dovremmo realizzare un test sulla percettibilità del jitter e stimarne i valori...se ne vedrebbero delle belle

[Gustavino]

Just now, granosalis said:

Il clock ha un ruolo importante, non lo banalizzerei in maniera cosi' superficiale.

tutto il digitale  si basa sul clock  che ne dica ilmisuratore che non ha basi di elettronica..... il segnale viene ricloccato salla asyncrona e devono essere buoni , si sente lho  già fatto nel 2007 ....

[ilmisuratore]

5 minuti fa, granosalis ha scritto:

Il clock ha un ruolo importante, non lo banalizzerei in maniera cosi' superficiale.

E vero, ma spesso si esagera sulla possibilità di poter discernere i pico dai femto, questo si 

[ilmisuratore]

2 minuti fa, Gustavino ha scritto:

tutto il digitale  si basa sul clock  che ne dica ilmisuratore che non ha basi di elettronica..... il segnale viene ricloccato salla asyncrona e devono essere buoni , si sente lho  già fatto nel 2007 ....

Gustavino, perdonami ma...questa è la conferma della tua ignoranza

Scambi la qualità del clock SIE SYNC da quello che deve generare il clock master di riferimento

Ignoranza pura all'ultimo stadio

[Gustavino]

55 minutes ago, granosalis said:

Prima dell'avvento dei chip X-Mos, l'implementazione dell'USB era problematica. Tuttavia, oggi l'USB asincrono funziona molto bene. Eviterei quindi discussioni generiche su cosa sia meglio o peggio. Quando affermo che non sono favorevole all'uso del PC collegato all'USB, non è per l'USB in sé, ma per il PC.

Un PC collegato all'USB diventa esso stesso il player, assumendo un ruolo primario nella riproduzione. 
Al contrario, quando un PC invia dati a uno streamer, il PC diventa un elemento secondario, mentre lo streamer assume il ruolo principale.

Perché preferire uno streamer a un PC?

• Funzione Specializzata: Uno streamer è progettato per uno scopo specifico.
• Hardware Dedicato: Include componenti ottimizzati per la riproduzione audio.
• Software a Bassa Latenza: Utilizza software ottimizzato per ridurre al minimo la latenza.
• Alimentazione Dedicata: Ha un'alimentazione progettata per garantire stabilità e affidabilità.
• Stabilità e Affidabilità: Gli streamer sono generalmente più stabili e affidabili rispetto ai PC.

Inoltre, uno streamer utilizza un processore specifico, spesso con grandi capacità di calcolo, ma operante a frequenze e con consumi energetici molto più bassi rispetto a un PC. Questo contribuisce a una migliore efficienza complessiva.

Gli streamer di alta qualità utilizzano distribuzioni di Linux compilate appositamente per sistemi embedded, che devono spesso rispondere a eventi in tempo reale. Pensate alla logica di funzionamento di una centralina elettronica per auto o di un sistema di rilevamento delle collisioni. Questi sistemi altamente specializzati operano su piattaforme embedded simili.

In sintesi, preferire uno streamer a un PC per la riproduzione audio offre numerosi vantaggi in termini di qualitativi, di specializzazione, efficienza e affidabilità, rendendo gli streamer la scelta ideale per applicazioni audio di alta qualità.

Lo streamer funziona con in ingresso un collegamento di rete, ma poi deve passare il segnale digitale al convertitore. 
Sul Bricasti (e rientro in tema) questo avviene internamente, con un percorso del segnale molto corto. Ed e' certamente questa la ragione per cui Brian ne suggerisce l'utilizzo. Ma esistono anche tanti buoni motivi per preferire uno streamer esterno da collegare poi al convertitore tramite l'inutilmente criticata porta USB.

just my 2 cents, si intende. 

Giuseppe

su questo siamo d'accordo trattare il segnale internamente in I2S ha notevoli vantaggi  anche dei svantaggi che richiedono perizia visto che un processore irradia di EMI a non finire molti di piu di quanto faccia  il chip del dac stesso ,ad esempio certi operazionali non possono essere usati visto che risentono dei dei disturdi del dac ...
mentre sulla usb lasciamo marinare il misuratore che non ha conpreso che una periferica usb audio non e' un Harddisk usb 

[granosalis]

4 minuti fa, ilmisuratore ha scritto:

E vero, ma spesso si esagera sulla possibilità di poter discernere i pico dai femto, questo si 

Si questo si, lo riconosco. 

Per altro non escludo che qualcuno possa anche preferire un segnale con un gitter maggiore, magari percependolo piu' ricco d'informazioni in gamma alta.

Ma il punto e' che l'audiofilo e' un appassionato maleducato. Nel senso, non educato (non sempre) ad un ascolto di qualità. 

[ilmisuratore]

1 minuto fa, ilmisuratore ha scritto:

ilmisuratore che non ha basi di elettronica

...e qui ci vogliono altre "basi" quelle di informatica e da operatore metrologico

Io le ho, quantomeno mi ricordo molte cose della mia (ex) attività e ne posso parlare con cognizione di causa

Te...????

[Gustavino]

7 minutes ago, ilmisuratore said:

...e qui ci vogliono altre "basi" quelle di informatica e da operatore metrologico

Io le ho, quantomeno mi ricordo molte cose della mia (ex) attività e ne posso parlare con cognizione di causa

Te...????

ma smettila dai

[ilmisuratore]

5 minuti fa, Gustavino ha scritto:

lasciamo marinare il misuratore che non ha conpreso che una periferica usb audio non e' un Harddisk usb 

Diciamo che la periferica audio (DAC) non è un HDD, certo...ma implementa ad esempio un controller TAS1020B

Se tu sapessi come funziona un TAS1020B magari chiederesti anche scusa...non a me (che non interessa nemmeno) ma a tutti i lettori per la tua cattiva informazione propinata

[stefano_mbp]

46 minuti fa, granosalis ha scritto:

Inoltre, uno streamer utilizza un processore specifico, spesso con grandi capacità di calcolo, ma operante a frequenze e con consumi energetici molto più bassi rispetto a un PC. Questo contribuisce a una migliore efficienza complessiva.

Direi che nessuno streamer usi processori “specifici”, il costo di sviluppo di un processore è enorme e renderebbe lo streamer inaccessibile per il costo.

Ricordiamo che il mercato degli streamer è infinitesimo rispetto a quello dei processori.

Alcuni esempi:

• SOtM SMS200 - processore ARM Allwinner sun7i (A20) Family ARMv7 Processor rev 4 (v7l) - Cortex-A7
• Innuos (tutti i modelli) - processore Intel Celeron
• T+A SD 3100 HV - SBC ARM NanoPi NEO4
• Volumio Rivo - Amlogic S905D3 SoC 1.9GHz Quad core ARM Cortex-A55 (SBC prodotta da Khadas)
• Boulder (alcuni modelli) - Raspberry Pi3

quindi direi che tendenzialmente usano processori assolutamente commerciali con modesta capacità elaborativa e clock piuttosto basso 1/2GHz per lo più ARM … del resto uno streamer non ha nessun bisogno di grande capacità elaborativa (a meno delle funzioni di gestione della libreria, infatti spesso vanno in crisi con volumi superiori a un paio di TB)

 

[stefano_mbp]

………

 

[Gustavino]

15 minutes ago, ilmisuratore said:

Diciamo che la periferica audio (DAC) non è un HDD, certo...ma implementa ad esempio un controller TAS1020B

Se tu sapessi come funziona un TAS1020B magari chiederesti anche scusa...non a me (che non interessa nemmeno) ma a tutti i lettori per la tua cattiva informazione propinata

bel cippone ma intanto ce devi mette un bel clock e si sente poi medita su csa significhi usb endpont iso---
 

[PippoAngel]

12 minuti fa, stefano_mbp ha scritto:

del resto uno streamer non ha nessun bisogno di grande capacità elaborativa (a meno delle funzioni di gestione della libreria, infatti spesso vanno in crisi con volumi superiori a un paio di TB)

In effetti Roon impone come minimo un Intel I3 per librerie non troppo grosse ... e gli streamer che possono installare Roon Core sono pochissimi, tra questi gli Innuos che utilizzano un Celeron (e che, per questo motivo, non sono certificati Roon pur potendo installare il Core normalmente via menù)

[granosalis]

39 minuti fa, stefano_mbp ha scritto:

Direi che nessuno streamer usi processori “specifici”,

Intendo processori specifici su quel contesto, che come spesso accade sono ARM, per l'alta efficienza che li contraddistingue. Ovviamente non e' una CPU ad uso audio, ma ad uso sistemi embedded sicuramente si. 

Poi esistono produttori che li mettono dentro ad una lavatrice smarth, ma questo dipende dal vendor.