Originariamente inviato da bigtube
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...