il dac per Marco....Lu Criaturu

[marcoc1712]

nel datasheet è riportato 96 k equivalente a oversampling 8x ma impostato dal filtro digitale DF1704....il chip in se va' ben oltre come peraltro sappiamo gia' nei fatti.
La questione è che il resampling software ha anch'esso qualche limitazione. Quindi se "demerito " ci fosse non è certo del chip....lui prende i dati e li traduce....ergo debbono essere buoni i dati perche' lui non ha problemi se lo facciamo lavorare bene.

Credo che il limite del chip sia 8x 96 KHz = 768kHz.

Dal data sheet:
Digital data words are read into the PCM1704 at eight times the standard DVD audio sampling frequency of 96kHz (e.g., 8 x 96kHz = 768kHz).

se è così, noi lo stiamo trattando 'con i guanti' facendolo lavorare al massimo a 384Khz, nel mio caso poi parliamo di 192 o 96, il piccolo è steso su un'amaca a ciuparsi una agua de coco, figurati se si impensierisce per così poco.

Sono daccordo con te, al di la delle caratteristiche di 'interpretazione' che ogni dac possiede, per capire le differenze di cui sto parlando bisogna guardare a monte ed in particolare ove il messsaggio viene 'manipolato'.

A tale riguardo, sta frullandomi un'idea in testa che potrebbe essere il prossimo progetto: le differenze causate dai sistemi operativi, drivers, cavi ed altro mi paiono troppo evidenti per essere causate 'solo' da disturbi che non alterano il contenuto in bit del segnale digitale, quindi vorrei investigare 'davvero' su cosa succede a valle delllo stadio (software) di uscita del player (squeezelite). La mia idea sarebbe di catturare l'output di USB (per come ricevuto dalla JLSound) e ritrasmetterlo ad una applicazione di acquisizione audio, per poi confrontarlo (in termini di bit, lasciamo stare il Jitter per il momento) con il contenuto dello stream originario.

La parte difficile (per me impossibile) è quella hw, si tratterebbe di una JLSound 'alla rovescia', se qualcuno si vuole cimentare...

Mi pare una cosa talmente tanto ovvia che mi stupisco nessuno ci abbia ancora pensato. Una cosa del genere, a suo tempo, l'ho realizzata (guidato da terzi, ovviamente) con la IO2 (che ha in ed out SPDIF) ma il risultato era falsato del clock driff tra i due circuiti. Usando SOLO USB si rimane nel dominio asincrono e si confronterebbero 'files' a livello binario, indipendenti dal fattore tempo e dalle interferenze 'elettriche' comunque originate.

L'obiezione che USB non è SPDIF e che la 'bit perfectness' è garantita dal protocollo non regge:

1. UAC2 NON prevede la ritrasmissiione dei pacchetti su errore, non è TCP/IP.
2. Non sono convinto che TUTTI i sistemi operativi /sound subsystems /drivers si pongano il rispetto della bit perfectness come obiettivo, almeno non sempre e non in ogni condizione. Non mi stupirei di trovare in diverse situazioni scelte di compromesso per minimizzare la latenza o altro, con effetti sul reale contenuto in bit dello stream.

La logica è che nell'audio (ed anche nel video) è peggio provocare un 'buco' tentando di gestire un errore o mettendo in atto strategie 'sofisticate' piuttosto che non 'mandare avanti' l'errore in se o ammettere perdita di precisione, logica - in parte - sensata nell'acquisizione o riproduzione real time, ma totalmente ingiustificata nella riproduzione asincrona.

Purtroppo, più scendo in profondità, più mi accorgo che la distinzione tra le due situazioni e spesso sacrificata sull'altare della semplificazione, tanto sono tutte situazioni in cui l'utente medio non distingue la differenza (tranne quel dannato gruppetto di fanatici audiofili...).

Il Tommaso che è in me vuole metterci il naso...




Mi piacerebbe avere un quadro più preciso del problema, almeno per non inseguire fantasmi...

[bigtube]

Riesci d aiutrami con l'alimentatore per il miniPc? v. http://www.nexthardware.com/forum/al...tml#post958604

che tensione alternata ci sta entrando ora?

[UnixMan]

Credo che il limite del chip sia 8x 96 KHz = 768kHz.

Dal data sheet:
Digital data words are read into the PCM1704 at eight times the standard DVD audio sampling frequency of 96kHz (e.g., 8 x 96kHz = 768kHz).

sì. Però, se vai a guardare più in dettaglio le caratteristiche, vedrai che (se non ricordo male) le prestazioni migliori (almeno da un punto di vista strumentale) si ottengono con ingresso a 44.1K (sempre IIRC con il DF1704, quindi x8=352.8). Non è escluso che a frequenze più basse vada ancora meglio (almeno da un punto di vista strumentale, e fintanto che non entrano in gioco altri fattori). Per quello ipotizzavo che (in configurazione "NOS") il compromesso ottimale potrebbe essere intorno a 96K o 192K.

A tale riguardo, sta frullandomi un'idea in testa che potrebbe essere il prossimo progetto: le differenze causate dai sistemi operativi, drivers, cavi ed altro mi paiono troppo evidenti per essere causate 'solo' da disturbi che non alterano il contenuto in bit del segnale digitale, quindi vorrei investigare 'davvero' su cosa succede a valle delllo stadio (software) di uscita del player (squeezelite). La mia idea sarebbe di catturare l'output di USB (per come ricevuto dalla JLSound) e ritrasmetterlo ad una applicazione di acquisizione audio, per poi confrontarlo (in termini di bit, lasciamo stare il Jitter per il momento) con il contenuto dello stream originario.

la cosa sarebbe senza dubbio interessante ma, se stiamo parlando di errori casuali, dubito che la error-rate possa essere tale da influenzare in modo significativo la qualità dell'ascolto. Come giustamente dici, con il link UAC gli errori non sono impossibili ma (salvo problemi/errori grossolani da qualche parte) mi pare inverosimile che la loro probabilità/frequenza possa essere tale da risultare significativa all'ascolto.

Tempo fa, in un'altra discussione proprio su questo forum, avevamo stimato che nella peggiore delle ipotesi in media si potrebbe avere al max un unico errore nel corso di un'intera sessione di ascolto... cosa ovviamente del tutto irrilevante dal punto di vista della qualità del suono. Per alterare la quale è necessario che gli errori siano "costantemente" presenti in una frazione significativa dei campioni trattati.

La parte difficile (per me impossibile) è quella hw, si tratterebbe di una JLSound 'alla rovescia', se qualcuno si vuole cimentare...

ad es. ti basta prendere una interfaccia I2S per ADC: colleghi l'uscita I²S della JLSounds all'ingresso dell'altra ed il gioco è fatto.

In alternativa esistono degli appositi analizzatori USB, che consentono anche di "catturare" lo stream.

Mi pare una cosa talmente tanto ovvia che mi stupisco nessuno ci abbia ancora pensato.

è molto meno ovvia di quel che pensi: per avere effetti udibili, la probabilità di errore e quindi il numero di errori nell'unità di tempo (frequenza) dovrebbero essere incredibilmente alte. Tanto alte da essere semplicemente impensabili in un qualsiasi sistema digitale correttamente funzionante (non "rotto").

Casomai è più probabile che alcune delle differenze riscontrate (in particolare quelle a livello software) siano da ricercarsi in errori di calcolo (veri e propri "bug") o di approssimazione in uno (o più) dei vari pezzi di software che maneggiano lo stream. Ad es. nella conversione tra formati diversi o cose del genere. Cioè che si tratti di errori "sistematici", non di errori casuali.

[marcoc1712]

che tensione alternata ci sta entrando ora?

Il secondario è 15V.

[marcoc1712]

sì. Però, se vai a guardare più in dettaglio le caratteristiche, vedrai che (se non ricordo male) le prestazioni migliori (almeno da un punto di vista strumentale) si ottengono con ingresso a 44.1K (sempre IIRC con il DF1704, quindi x8=352.8). Non è escluso che a frequenze più basse vada ancora meglio (almeno da un punto di vista strumentale, e fintanto che non entrano in gioco altri fattori). Per quello ipotizzavo che (in configurazione "NOS") il compromesso ottimale potrebbe essere intorno a 96K o 192K.


la cosa sarebbe senza dubbio interessante ma, se stiamo parlando di errori casuali, dubito che la error-rate possa essere tale da influenzare in modo significativo la qualità dell'ascolto. Come giustamente dici, con il link UAC gli errori non sono impossibili ma (salvo problemi/errori grossolani da qualche parte) mi pare inverosimile che la loro probabilità/frequenza possa essere tale da risultare significativa all'ascolto.

Tempo fa, in un'altra discussione proprio su questo forum, avevamo stimato che nella peggiore delle ipotesi in media si potrebbe avere al max un unico errore nel corso di un'intera sessione di ascolto... cosa ovviamente del tutto irrilevante dal punto di vista della qualità del suono. Per alterare la quale è necessario che gli errori siano "costantemente" presenti in una frazione significativa dei campioni trattati.


ad es. ti basta prendere una interfaccia I2S per ADC: colleghi l'uscita I²S della JLSounds all'ingresso dell'altra ed il gioco è fatto.

In alternativa esistono degli appositi analizzatori USB, che consentono anche di "catturare" lo stream.


è molto meno ovvia di quel che pensi: per avere effetti udibili, la probabilità di errore e quindi il numero di errori nell'unità di tempo (frequenza) dovrebbero essere incredibilmente alte. Tanto alte da essere semplicemente impensabili in un qualsiasi sistema digitale correttamente funzionante (non "rotto").

Casomai è più probabile che alcune delle differenze riscontrate (in particolare quelle a livello software) siano da ricercarsi in errori di calcolo (veri e propri "bug") o di approssimazione in uno (o più) dei vari pezzi di software che maneggiano lo stream. Ad es. nella conversione tra formati diversi o cose del genere. Cioè che si tratti di errori "sistematici", non di errori casuali.

Esatto, quello che iipotizzo io è non tanto che gli errori (la stima che conosco io è di 1 ogni 10 ore) di trasmissione influenzino il suono, quanto che la minor 'rigidità' delle specifiche e l'idea che 'tanto non si sente' o 'è meglio la bassa latenza', porti a configurazioni che introducano errori 'sistemici'.

[UnixMan]

Il secondario è 15V.

15Vrms * 1.41 = 21.15Vp; togli circa 2*0.7V=1.4V della caduta sui diodi del ponte, ed ottieni circa 19.75Vdc in ingresso al regolatore.

Posto che l'uscita regolata sia a 12Vdc, sul regolatore avresti una caduta ("drop-out") di ben 19.75-12=7.75V. Che, moltiplicati per la corrente assorbita dal carico, ti danno la potenza dissipata dal regolatore. Che, ad occhio e croce, è decisamente troppa...

(BTW: ma non siamo nel thread sbagliato?!)

[bigtube]

Esatto, quello che iipotizzo io è non tanto che gli errori (la stima che conosco io è di 1 ogni 10 ore) di trasmissione influenzino il suono, quanto che la minor 'rigidità' delle specifiche e l'idea che 'tanto non si sente' o 'è meglio la bassa latenza', porti a configurazioni che introducano errori 'sistemici'.

Nel campo digitale bisogna sec. me far funzionare le cose bene .....ma il gioco piu' duro e nel regno dell'analogico.....dall'I/V in poi ....

[marcoc1712]

Nel campo digitale bisogna sec. me far funzionare le cose bene .....ma il gioco piu' duro e nel regno dell'analogico.....dall'I/V in poi ....

Non lo metto in dubbio e - come spesso consiglio a chi lo chiede - se devo decidere dove spendere soldi per 'migliorare' il suono, non è certo nell'alimentatore del router, ma questo è un mio interesse specifico.

[marcoc1712]

15Vrms * 1.41 = 21.15Vp; togli circa 2*0.7V=1.4V della caduta sui diodi del ponte, ed ottieni circa 19.75Vdc in ingresso al regolatore.

Posto che l'uscita regolata sia a 12Vdc, sul regolatore avresti una caduta ("drop-out") di ben 19.75-12=7.75V. Che, moltiplicati per la corrente assorbita dal carico, ti danno la potenza dissipata dal regolatore. Che, ad occhio e croce, è decisamente troppa...

(BTW: ma non siamo nel thread sbagliato?!)

Si, lo avevi già scritto, ma evidentemente non è così semplice. Continuiamo di la però.

[DacPassion]

Marco questa
XMOS Multichannel high-quality USB to/from I2S/DSD SPDIF PCB - DIYINHK
fa quello che vuoi, il problema è che fa tanto altro che non ti serve ma ne lievitano il costo