Wtfplay - misurazioni e confronti con players

Pagina 9 di 81
prima
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 59 ... ultimo
Visualizzazione dei risultati da 81 a 90 su 807
  1. #81
    pebibyte L'avatar di marcoc1712
    Registrato
    Jan 2013
    Messaggi
    5,254
    configurazione

    Predefinito

    Originariamente inviato da UnixMan
    certamente...
    Tutto condivisibile e condiviso, con una sola precisazione, ma importante: la velocità media di rempimento è certamente corrispondente a quella di svuotamento, ovvio sia così, ma la dimensione del buffer influenza PESANTEMENTE il profilo di lavoro.

    Tipicamente la riproduzione non parte fino al raggiungimento di 1/2 buffer size, in quel periodo il pc riempe il buffer alla massima velocità compatibile con i suoi algoritmi di schedulazione, tipicamente MOLTO maggiore di quella di prelievo.

    In esecuzione, il processo di 'prelievo' manda un 'interrupt' al raggiungimento della soglia minima, anche questa normalmente calcolata come quota parte del buffer, cui la CPU rispone dedicando un ciclo e riempiendo il buffer della quantità di frames che riesce a recuperare, se non bastano a colmare il gap, riceve un ulteriore interrupt e così via.

    Ecco perchè buffer alti corrispondono a profili di carico di USB (ed all'indietro di TUTTI i sottosistemi afferenti) molto discontinui, mentre buffer piccoli più continui, di più buffer piccoli comportaneo un maggior numero di interrupt,quindi maggior carico di CPU.

    Incidentalmente, buffer grandi provocano maggiore latenza, proprio per questo motivo.

    Quantificare l'effetto di questo fenomeno sul suono è arduo, ma certamente il 'profilo' di carico di USB (e non solo) è certamente più influenzato da questo parametro che non da eventuali drift del clock del pc stesso, che non riesco francamente a capire come possa agire in merito.

    Allo stesso modo,- solo a titolo di esempio - il processo di conversione FLAC/WAV agisce oltre che come 'consumatore' di cicli di CPU anche come una addizionale coppia di buffers asincroni che si aggiungono al processo, 'disaccoppiando' ulteriormente l'input (lettura da disco, ethernet,...) dall'output, con la particolarità che la dimensione in input è scorrelata da quella in output, quindi anche le velocità medie relative variano, lo stesso lo fa lo strato TCP/IP se si usa la rete, il disco o ancora USB con una chiavetta (anche se con un altro approccio).

    Originariamente inviato da UnixMan
    ad es. se il ricevitore s/pdif è realizzato con un ASRC anziché con un PLL, come spesso accade nei ricevitori più recenti con funzionalità "anti-jitter"...
    Continuo a non capire come possa avvenire. Prelevi i bit dello stream 'raw' e li salvi in un file, cosa centra il clock?
    Ciao, Marco.

    "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."
    — E. F. Schumacher (mis-attributed to A. Einstein)
    ________________________________________________________________________________
    Autore della patch R2 per Squeezelite e del plugin C-3PO. note libere
    Logitech media Server 7.9 > miniPc + squeezelite-R2 / SB+ > "Lu Scalmentu" NOS R2R DAC by TubeOne/ AudioResearch DAC 1-20 >
    Klimo Merlino Gold TPS > DIS Interconnect > Kent Gold > Reference > Monitor Audio Studio 20 SE

  2. #82
    tebibyte L'avatar di UnixMan
    Registrato
    Sep 2013
    Messaggi
    2,529
    configurazione

    Predefinito

    Originariamente inviato da marcoc1712
    Tutto condivisibile e condiviso, con una sola precisazione, ma importante: la velocità media di rempimento è certamente corrispondente a quella di svuotamento, ovvio sia così, ma la dimensione del buffer influenza PESANTEMENTE il profilo di lavoro.
    senza dubbio. Ma... occhio che mi sa che hai frainteso qualcosa. Io mi stavo riferendo al buffer interno del "ricevitore", cioè a quello dell'interfaccia USB-I²S che pilota il DAC, non ai buffer del player, o di ALSA, ecc.

    Non mi risulta che i buffer interni delle interfacce USB (ad es. le Xmos) siano configurabili dall'utente!

    Originariamente inviato da marcoc1712
    Continuo a non capire come possa avvenire. Prelevi i bit dello stream 'raw' e li salvi in un file, cosa centra il clock?
    PC e software non c'entrano nulla. Il problema è a monte, in hardware, a livello del ricevitore s/pdif. Devi considerare che la trasmissione s/pdif è sincrona, ma non prevede una linea separata per la trasmissione del clock. Che è "embedded" nella trasmissione dei dati stessi. Il ricevitore deve ricostruire il clock a partire dallo stesso segnale che trasporta anche i dati (e non si tratta di una operazione del tutto banale e scevra da problemi). Questo si può fare in vari modi. Quello tradizionale è per mezzo dell'impiego di un PLL. Una possibile alternativa (piuttosto diffusa) è l'impiego di un ASRC, cioè di un vero e proprio ricampionamento nel dominio digitale. Questo permette di "disaccoppiare" il clock del ricevitore da quello del trasmettitore, al prezzo però di convertire jitter e drift dei due clock in occasionali errori nei dati.
    Ciao, Paolo.

    «Se tu hai una mela, e io ho una mela, e ce le scambiamo, allora tu ed io abbiamo sempre una mela per uno. Ma se tu hai un'idea, ed io ho un'idea, e ce le scambiamo, allora abbiamo entrambi due idee.»

  3. #83
    pebibyte L'avatar di marcoc1712
    Registrato
    Jan 2013
    Messaggi
    5,254
    configurazione

    Predefinito

    Originariamente inviato da UnixMan
    senza dubbio. Ma... occhio che mi sa che hai frainteso qualcosa. Io mi stavo riferendo al buffer interno del "ricevitore", cioè a quello dell'interfaccia USB-I²S che pilota il DAC, non ai buffer del player, o di ALSA, ecc.

    Non mi risulta che i buffer interni delle interfacce USB (ad es. le Xmos) siano configurabili dall'utente!
    Si, avevo frainteso. Pensavo ti riferissi al buffer di ALSA. In ogni caso il concetto è analogo. Un FIFO è sempre controlato da processi che interpellano la CPU ogni volta che viene superato 'il livello di guardia' di troppo pieno o troppo vuoto, la CPU dedica un ciclo e aspetta iun nuovo segnale.

    Originariamente inviato da UnixMan

    PC e software non c'entrano nulla. Il problema è a monte, in hardware, a livello del ricevitore s/pdif. Devi considerare che la trasmissione s/pdif è sincrona, ma non prevede una linea separata per la trasmissione del clock. Che è "embedded" nella trasmissione dei dati stessi. Il ricevitore deve ricostruire il clock a partire dallo stesso segnale che trasporta anche i dati (e non si tratta di una operazione del tutto banale e scevra da problemi). Questo si può fare in vari modi. Quello tradizionale è per mezzo dell'impiego di un PLL. Una possibile alternativa (piuttosto diffusa) è l'impiego di un ASRC, cioè di un vero e proprio ricampionamento nel dominio digitale. Questo permette di "disaccoppiare" il clock del ricevitore da quello del trasmettitore, al prezzo però di convertire jitter e drift dei due clock in occasionali errori nei dati.
    Mi pare che questo avvenga solo in alcuni DAC (ESS SABRE, è un loro brevetto) e, appunto, nel DAC CHIP, non nel ricevitore SPDIF, il che è corretto in quanto in nuovo clock DEVE essere quanto più possibile vicino al DAC, dato che l'obiettivo è svincolare lo stream dal clock del trasporto per produrre un segnale analogico privo di artefatti, NON di fare il reclock del segnale SPDIF.

    http://www.esstech.com/files/4614/40...out-jitter.pdf

    Io ho chiesto a Salvatore di prelevare il segnale SPDIF immediatamente a valle dall'intefaccia USB (in realtà avrei voluto direttamente lo stream USB, ma non è possibile con le attrezzature che abbiamo) quindi PRIMA di qualsiasi filtro o ricampionamento operato dal DAC. Di certo Non è un rischio che si corre con la JL Sound, quindi da questo punto di vista stiamo tranquilli.

    IN ogni caso, io interpreto che l'aggiustamentio avviene nel dominio del tempo, quiindi non nei bit, ma certamente potrei aver capito male.
    Ciao, Marco.

    "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."
    — E. F. Schumacher (mis-attributed to A. Einstein)
    ________________________________________________________________________________
    Autore della patch R2 per Squeezelite e del plugin C-3PO. note libere
    Logitech media Server 7.9 > miniPc + squeezelite-R2 / SB+ > "Lu Scalmentu" NOS R2R DAC by TubeOne/ AudioResearch DAC 1-20 >
    Klimo Merlino Gold TPS > DIS Interconnect > Kent Gold > Reference > Monitor Audio Studio 20 SE

  4. #84
    tebibyte L'avatar di UnixMan
    Registrato
    Sep 2013
    Messaggi
    2,529
    configurazione

    Predefinito

    Originariamente inviato da marcoc1712
    Mi pare che questo avvenga solo in alcuni DAC (ESS SABRE, è un loro brevetto) e, appunto, nel DAC CHIP, non nel ricevitore SPDIF [...]
    È vero che il SABRE integra il ricevitore SPDIF, ed è vero che (anche lui) utilizza proprio un ASRC per farlo... ma è un caso alquanto atipico. Di solito la funzione di ricevitore SPDIF non è integrata nei DAC, ma è svolta da un chip apposito. Alcuni di questi chip utilizzano un PLL, altri un ASRC. Che non è certo una invenzione della ESS.

    Ho l'impressione che tu consideri l'S/PDIF come se fosse una banale linea seriale digitale "locale"... ma non è esattamente così. Il segnale s/pdif è un segnale modulato che combina un segnale digitale (lo stream di dati) con un segnale analogico (il clock). Tecnicamente un trasmettitore s/pdif è un MOdulatore, ed il ricevitore (comunque implementato) è un DEModulatore; le operazioni coinvolte -comunque realizzate- non sono del tutto banali né scevre da problemi e possibili "errori".

    Gli ASRC hanno un gran numero di impieghi diversi, non servono solo per cambiare il sample-rate. Uno degli impieghi più comuni è proprio quello di "risincronizzare" uno stream (sincrono rispetto ad un "proprio" clock) con un clock diverso (asincrono rispetto a quello di partenza, per l'appunto). È il caso ad es. dei link audio USB (UAC1/UAC2) nella classica modalità isocrona, ma anche quello di molti ricevitori S/PDIF laddove si preferisca - o sia necessario - utilizzare un master clock diverso (asincrono) rispetto a quello ricostruito/ricostruibile a partire dal segnale s/pdif.

    Una necessità del genere si ha ad es. proprio nelle schede audio, che devono poter sincronizzare tra loro diversi flussi di dati audio, di diversa provenienza, con un singolo "master clock" locale. Se/quando uno o più di questi flussi vengono ricevuti attraverso link sincroni (ad un proprio clock esterno), com'è il caso degli ingressi S/PDIF, deve necessariamente essere utilizzato un ASRC.

    L'unica eccezione si può avere solo se/quando la scheda è in grado di sincronizzarsi con uno degli stream in ingresso, cioè di utilizzare come suo master clock locale proprio quello ricostruito a partire da (uno ed uno solo) degli stream in ingresso... ma di solito anche in questo caso l'ASRC resta (salvo che il resampling diventa "sincrono", in quanto i due clock sono per l'appunto sincroni tra loro).

    Per altro, anche laddove il ricevitore S/PDIF impieghi un PLL, si ha sempre a che fare con un oscillatore locale (di solito un VCXO), che viene "agganciato" (sincronizzato) per mezzo del loop di feedback del PLL al segnale di ingresso... (è proprio questo il meccanismo che permette di "ricostruire" il clock dello stream a partire dal segnale s/pdif).

    In altre parole, in un link s/pdif i "dati" ed il "clock" non sono due cose completamente distinte ed indipendenti tra loro.
    Ultima modifica di UnixMan : 17-06-2016 a 13:17
    Ciao, Paolo.

    «Se tu hai una mela, e io ho una mela, e ce le scambiamo, allora tu ed io abbiamo sempre una mela per uno. Ma se tu hai un'idea, ed io ho un'idea, e ce le scambiamo, allora abbiamo entrambi due idee.»

  5. #85
    pebibyte L'avatar di marcoc1712
    Registrato
    Jan 2013
    Messaggi
    5,254
    configurazione

    Predefinito

    Originariamente inviato da bibo01
    Purtroppo di materiale reso pubblico c'è poco, ma di discussioni in camera caritatis con progettisti vari ne avrei parecchie.
    Forse in questa discussione qualcosa si può intravvedere anche se vari grafici sono stati cancellati:
    Measuring XXHighEnd ...

    E' del 2009 e, come puoi intuire, qualcosa da allora si è mosso
    Mi paiono interessanti alcune informazioni, anche se vanno prese con le pinze e da consierare valide per quel sistema, non in assoluto:

    In ripetizioni prese in condizioni il più possibile simili (i.e. senza cambiare settings ed in rapida successione)

    1. 82% è la percentuale (costante) di campioni uguali a se stessi in ripetizioni successive.
    2. per il rimanete 18%, la variabilità per campione è 1 o sporadicamente 2.

    Questa misura dice poco in se e corrisponde ala misurazione di Salvatore dve sistemi diversi prouducono differenze relativamente diverse anche di 30 db,
    purtroppo anche in questo caso sono stati usati clock indipendenti, quindi non si riesce a distinguere quanto dovuto al drift e quanto invece a jitter o altro, ripetendo però l'analisi a seguito di correzione ppm, dovrebbe approssimare un valore più realistico, che diventa importante ai fini successivi.

    Verificato che il numero di campioni errati ma, soprattutto, il valore di errore per campione, aumenta considerevole al cambiare dei diversi settings e, soprattutto, che il pattern assume andamento regolare e costante, gli ha consentito di individuare pattern specifici per le diverse cause. Questo è molto interessante:

    se setting A e diverso da Setting B in modo ripetibile e costante secondo un determinato pattern, mentre setting C e diverso da setting B secondo un diverso ma sempre costante pattern, è - forse - possibile estrapolare l'effetto 'tipico' di C.

    Da qui a capire come questo arrivi ad influenzare il suono ne passa, ma almeno avremmo una conferma di differenze 'sistemiche' dovute ai diversi fattori.

    Affrontato solo di sfuggita, ma interessante spunto è la considerazione che pattern regolari nei disturbi potrebbero (il condizionale è d'obbligo) rivelarsi più o meno udibili e fastidisoni ANCHE per ragioni psicoacustiche, al di là dell'effettiva udibilità delle differenze provocate in se, basti pensare al dithering.

    Ricordo che il dithering, in un file a 24 bit, cambia mediamnte 1/24*2 campioni, quindi il 2% e SEMPRE sul bit meno significativo, ma risulta ben udibile proprio per un effetto psicoacustico.

    Di fronte a variabilità almeno analoghe (a seguito della correzione ppm) non mi stupirei se si potessero individuare casi analoghi e nemmeno se si rileverassero essere dovuti proprio a quegli aspetti che - empiricamente - i "dannati audiofili" denunciano da un po, anche se - ovviamente - la correlazione tra quanto 'misurato' e quanto percepito rimarrebbe comunque arbitraria e non dimostrata.

    @Salvatore, la metodologia di indagine sulle variazioni mi pare interessante, almeno in via complemetare alla tua, non ho idea di come produrre il risultato però.

    Detto ciò, non ho trovato accenno alla correlazione tra clock dela MB e quello del DAC, a che punto è?
    Ciao, Marco.

    "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."
    — E. F. Schumacher (mis-attributed to A. Einstein)
    ________________________________________________________________________________
    Autore della patch R2 per Squeezelite e del plugin C-3PO. note libere
    Logitech media Server 7.9 > miniPc + squeezelite-R2 / SB+ > "Lu Scalmentu" NOS R2R DAC by TubeOne/ AudioResearch DAC 1-20 >
    Klimo Merlino Gold TPS > DIS Interconnect > Kent Gold > Reference > Monitor Audio Studio 20 SE

  6. #86
    pebibyte L'avatar di marcoc1712
    Registrato
    Jan 2013
    Messaggi
    5,254
    configurazione

    Predefinito

    Originariamente inviato da UnixMan
    È vero che il SABRE integra il ricevitore SPDIF, ed è vero che (anche lui) utilizza proprio un ASRC per farlo... ma è un caso alquanto atipico. Di norma la funzione di ricevitore SPDIF non è integrata nei DAC, ma è svolta da un chip apposito. Alcuni di questi chip utilizzano un PLL, altri un ASRC. Che non è certo una invenzione della ESS.

    Ho l'impressione che tu consideri l'S/PDIF come se fosse una banale linea seriale digitale "locale"... ma non è esattamente così. Il segnale s/pdif è un segnale modulato che combina un segnale digitale (lo stream di dati) con un segnale analogico (il clock). Tecnicamente un trasmettitore s/pdif è un MOdulatore, ed il ricevitore (comunque implementato) è un DEModulatore; le operazioni coinvolte -comunque realizzate- non sono del tutto banali né scevre da problemi e possibili "errori".

    Gli ASRC hanno un gran numero di impieghi diversi, non servono solo per cambiare il sample-rate. Uno degli impieghi più comuni è proprio quello di "risincronizzare" uno stream (sincrono rispetto ad un "proprio" clock) con un clock diverso (asincrono rispetto a quello di partenza, per l'appunto). È il caso ad es. dei link audio USB (UAC1/UAC2) nella classica modalità isocrona, ma anche quello di molti ricevitori S/PDIF laddove si preferisca - o sia necessario - utilizzare un master clock diverso (asincrono) rispetto a quello ricostruito/ricostruibile a partire dal segnale s/pdif.

    Una necessità del genere si ha ad es. proprio nelle schede audio, che devono poter sincronizzare tra loro diversi flussi di dati audio, di diversa provenienza, con un singolo "master clock" locale. Se/quando uno o più di questi flussi vengono ricevuti attraverso link sincroni (ad un proprio clock esterno), com'è il caso degli ingressi S/PDIF, deve necessariamente essere utilizzato un ASRC.

    L'unica eccezione si può avere solo se/quando la scheda è in grado di sincronizzarsi con uno degli stream in ingresso, cioè di utilizzare come suo master clock locale proprio quello ricostruito a partire da (uno ed uno solo) degli stream in ingresso... ma di solito anche in questo caso l'ASRC resta (salvo che il resampling diventa "sincrono", in quanto i due clock sono per l'appunto sincroni tra loro).

    Per altro, anche laddove il ricevitore S/PDIF impieghi un PLL, si ha sempre a che fare con un oscillatore locale (di solito un VCXO), che viene "agganciato" (sincronizzato) per mezzo del loop di feedback del PLL al segnale di ingresso... (è proprio questo il meccanismo che permette di "ricostruire" il clock dello stream a partire dal segnale s/pdif).

    In altre parole, in un link s/pdif i "dati" ed il "clock" non sono due cose completamente distinte ed indipendenti tra loro.
    Paolo, stiamo sul punto, nessuno sostiene che sono indipendenti, ma ciò non significa che sono 'inseparabili'. Estrarre il contenuto 'rraw' di bit da un SINGOLO stream SPDIF è semplice e - in assenza di guasti - bit perfect. Su questo spero converrai. Che mixare flusi diversi comporti NECESSARIAMENTE un riallineamento è ovvio, anzi proprio quella necssità dimostra la possibilità di siolare i bit dal clock (altrimenti cosa riallinei?) ma in riproduzione di uno stream sterofonico non ci interessa affatto.

    Tutte le 'magagne' imputate a SPDIF sono ricondotte al Jitter proprio a causa della natura 'sincrona' del collegamento, non ho masi sentito imputare a SPDIF la rottura della condizione di bit perfectness di per se. Che poi il collegamento asincrono via USB si sia dimostratio essere tutt'altro che una panacea, è tutto un altro discorso.

    NON STO sostenendo che SPDIF è meglio di USB o che sia priva di problemi, ma dato che per fare le prove non possiamo fare a meno di passare da:


    PC1 -> USB -> SPDIF OUT -> SPDIF IN -> USB -> PC2


    mi interessa SOLO poter dare per assodato che in questa specifica configurazione e per questo specifico uso, salvo guasti o errori sporadic si possa coniderare il tratto " SPDIF OUT -> SPDIF IN " 'bit perfect'.

    Conveniamo su questo?
    Ciao, Marco.

    "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."
    — E. F. Schumacher (mis-attributed to A. Einstein)
    ________________________________________________________________________________
    Autore della patch R2 per Squeezelite e del plugin C-3PO. note libere
    Logitech media Server 7.9 > miniPc + squeezelite-R2 / SB+ > "Lu Scalmentu" NOS R2R DAC by TubeOne/ AudioResearch DAC 1-20 >
    Klimo Merlino Gold TPS > DIS Interconnect > Kent Gold > Reference > Monitor Audio Studio 20 SE

  7. #87
    tebibyte L'avatar di UnixMan
    Registrato
    Sep 2013
    Messaggi
    2,529
    configurazione

    Predefinito

    Originariamente inviato da marcoc1712
    Estrarre il contenuto 'rraw' di bit da un SINGOLO stream SPDIF è semplice e - in assenza di guasti - bit perfect.
    in assoluto, no: gli errori normalmente sono improbabili, ma non impossibili (e la probabilità di errore dipende anche dal timing: è una delle ovvie conseguenze del fatto che dati e clock non sono indipendenti; l'altra è quella ben nota che il jitter del clock ricostruito dal s/pdif è fortemente correlato ai dati trasmessi).

    Originariamente inviato da marcoc1712
    ma in riproduzione di uno stream sterofonico non ci interessa affatto.
    in riproduzione (se il ricevitore è a PLL) forse no... ma qui non stiamo parlando di riprodurre, ma di "registrare" uno stream s/pdif. Non è esattamente la stessa cosa. Di default, tutte le schede audio che conosco lavorano con il loro master clock interno e ricampionano sempre tutto ciò che entra. Solo alcune (tipicamente "pro" o "semi-pro") permettono la possibilità di utilizzare un master clock esterno e/o di utilizzare come tale il clock di uno stream di ingresso. E, anche queste, devono essere espressamente configurate per farlo... altrimenti anche quelle usano il loro master clock interno e ricampionano tutto ciò che entra. Beware!

    Originariamente inviato da marcoc1712
    PC1 -> USB -> SPDIF OUT -> SPDIF IN -> USB -> PC2

    mi interessa SOLO poter dare per assodato che in questa specifica configurazione e per questo specifico uso, salvo guasti o errori sporadic si possa coniderare il tratto " SPDIF OUT -> SPDIF IN " 'bit perfect'.
    e proprio questo è il problema. Purtroppo non si può. Se trovi un errore, chi ti assicura che si sia verificato su un link USB (UAC1/2) e non su s/pdif? Nulla e nessuno. Nessuno dei due "canali" prevede meccanismi di identificazione e correzione degli errori, ed entrambi hanno una probabilità di errore che, per quanto piccola, è sicuramente >0.

    In altre parole, se non trovi errori va tutto bene. Ma se al contrario ne trovi, non c'è modo di sapere con certezza dove abbiano avuto origine...
    Ultima modifica di UnixMan : 17-06-2016 a 16:50
    Ciao, Paolo.

    «Se tu hai una mela, e io ho una mela, e ce le scambiamo, allora tu ed io abbiamo sempre una mela per uno. Ma se tu hai un'idea, ed io ho un'idea, e ce le scambiamo, allora abbiamo entrambi due idee.»

  8. #88
    pebibyte L'avatar di marcoc1712
    Registrato
    Jan 2013
    Messaggi
    5,254
    configurazione

    Predefinito

    Originariamente inviato da UnixMan
    in assoluto, no: gli errori normalmente sono improbabili, ma non impossibili (e la probabilità di errore dipende anche dal timing: è una delle ovvie conseguenze del fatto che dati e clock non sono indipendenti; l'altra è quella ben nota che il jitter del clock ricostruito dal s/pdif è fortemente correlato ai dati trasmessi).


    in riproduzione (se il ricevitore è a PLL) forse no... ma qui non stiamo parlando di riprodurre, ma di "registrare" uno stream s/pdif. Non è esattamente la stessa cosa. Di default, tutte le schede audio che conosco lavorano con il loro master clock interno e ricampionano sempre tutto ciò che entra. Solo alcune (tipicamente "pro" o "semi-pro") permettono la possibilità di utilizzare un master clock esterno e/o di utilizzare come tale il clock di uno stream di ingresso. E, anche queste, devono essere espressamente configurate per farlo... altrimenti anche quelle usano il loro master clock interno e ricampionano tutto ciò che entra. Beware!


    e proprio questo è il problema. Purtroppo non si può. Se trovi un errore, chi ti assicura che si sia verificato su un link USB (UAC1/2) e non su s/pdif? Nulla e nessuno. Nessuno dei due "canali" prevede meccanismi di identificazione e correzione degli errori, ed entrambi hanno una probabilità di errore che, per quanto piccola, è sicuramente >0.

    In altre parole, se non trovi errori va tutto bene. Ma se al contrario ne trovi, non c'è modo di sapere con certezza dove abbiano avuto origine...
    D'accordo, se si verificca un errore casuale , può essre sia uìin USB che in SPDIF. Ma non on cerchiamo errori casuali, ma - eventualmente - solo errori sistematici introdotti dalla variazione dei parametri ALSA su interfaccia USB.

    A mio avviso non ne troveremo, ne dovessimo trovarne di casuali non sarà significativo e scarteremo la prova con l'errorre, ne trovassimo di 'sistematici' ma solo al variare dei parametri (probabilità remota), vedremo di indagare meglio.

    Per il resto io non sono daccordo su quello che scrivi (tranne sul fatto che usndo clock non agganciati, si ha erroee di timing IN ACQUISIZIONE ANALOGICA però!), ma ci porta troppo fuori tema.

    BTW USB (UAC2) ha il CRC e - dipendentemente dai settings di sistema - scrive gli errori nel log, solo non li corregge tramite ritrasmissione.
    Ciao, Marco.

    "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."
    — E. F. Schumacher (mis-attributed to A. Einstein)
    ________________________________________________________________________________
    Autore della patch R2 per Squeezelite e del plugin C-3PO. note libere
    Logitech media Server 7.9 > miniPc + squeezelite-R2 / SB+ > "Lu Scalmentu" NOS R2R DAC by TubeOne/ AudioResearch DAC 1-20 >
    Klimo Merlino Gold TPS > DIS Interconnect > Kent Gold > Reference > Monitor Audio Studio 20 SE

  9. #89
    gibibyte L'avatar di DacPassion
    Registrato
    Jul 2014
    Messaggi
    1,250

    Predefinito

    -semi ot-
    Ci sarà in giro per il mondo qualcuno che ha misurato seriamente il "sistema" BBB/hermes/cronus/rea ??
    ...giusto per capire se può essere una strada alternativa alla "tortuosa" USB
    Clearaudio Emotion + Satisfy + Grado Gold1 > Phono D3A DIY
    Futro S450 + Daphile / Amanero + Buffalo 2 (trident) uscita a TU Cinemag 15/15B DIY / Jlsounds + Lector Digicode TDA1541 S1
    Monoblocchi D3A 2A3 (electrolytich free!!) DIY / Coral Beta8 in BLH DIY

  10. #90
    Moderatore L'avatar di SM63
    Registrato
    Jul 2014
    Età
    62
    Messaggi
    418
    configurazione

    Predefinito

    Tom

    Finito appena adesso con le nuove acquisizioni .... dagli sotto vediamo se si riesce arrivare a qualche conclusione ... qui potete scaricare tutte le acquisizioni ...non sono tagliate come richiesto da Tom ......https://we.tl/nYX7Y8uTG8

    Come atticipato oltre a quelle richieste ....sostanzialmente rispecchiano quelle precedenti ....sono andato oltre ...partendo da alcune considerazioni ...frutto dei tanti interventi fin qui esposti ....grazie Paolo e Marco ...ho riflettuto parecchio sulla stabilita'...ammesso sia l'unica causa a produrre quelle differenze che possa trovare giustificazioni sul percepito ...non posso escludere nessuna ipotesi tra le cause dirette con quelle indirette ....uno dei modi arrivarci per esclusione ...mantenendo il piu' possibile le stesse condizione muovendo una variabile alla volta ....

    Al momento escludiamo Foobar hardware PC non in comune con gli altri due player ....

    Daphile e WTF li ho fatti andare con lo stesso Hardware PC ( FUTRO ) ....l'unico elemento che non accomuna i due player apparte la variante nel sistema operativo .... rimane per il momento la rete ...(router incluso) ...visto che daphile permette anche l'utilizzo senza la rete con i comandi locati ...tastiera e mouse ...ho spento il router escludendo pure la connessione alla rete quindi nessun cavo connesso .......qui la prima novita' ...errore del sample rate non serve piu' compensarlo ...sposto per chiarezza i log completi durante il calcolo prima con il router acceso connesso sul futro daphile come player ....successivamente router spento ....sono tre per ogni verifica ....a confronto tra traccie ....questa volta acquisite singolarmente ...


    Router acceso connesso al futro







    Con router spenco







    I grafici li spostero in un secondo momento ...non appena tom termina con le sue verifice ...

    Continua ....

    PS Marco tra non molto inizio quelle da te richieste in digitale .....


    nulla si crea nulla si distrugge ma tutto si trasforma

Pagina 9 di 81
prima
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 59 ... ultimo

Informazioni Thread

Users Browsing this Thread

Ci sono attualmente 4 utenti che stanno visualizzando questa discussione. (0 utenti e 4 ospiti)

Regole d'invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
nexthardware.com - © 2002-2022