Rumori ad alta frequenza e il PC

[grunter]

Avevo capito ci fosse un isolatore tra la linea del PC e del DAC/Impianto, per questo consideravo esclusa la via galvanica da rete. Me lo sarò sognato...

Non te lo sei sognato, pc e dac vedono interposti tra le rispettive schede di rete due media converter ethernet fibra, cioè due TP-Link MC200CM
413L1YiShZL.jpg

[marcoc1712]

Fatto sta che mi ha fatto capire che non è solo con i dac usb che ci possono essere grosse differenze tra un pc e un altro ma anche con pc che usano ethernet (ravenna in particolare) come il mio.

Non so se è OT, nel qual caso eventualmente autorizzo da subito a spostare o cancellare.

Ravenna è un protocollo 'real ltime' appoggiato su IP, che di sua natura è asincrono e NON garantisce la consegna di tutti i pacchetti (anche se è rarissimo) e tantomeno il tempo massimo di consegna.

Ci sono solo 2 modi per gestire la continuità in una trasmissioni a pacchetti:

a. si aspetta finche non è disponibile il pacchetto con la porzione di stream da inviare.
b. quando è il momento se il pacchetto non è disponibile si salta al primo disponibile successivo.

entrambe le situazioni provocano 'disturbi' e sarebbero da minimizzare, il modo per farlo, data una determinata infrastruttura di rete ed una situazione di traffico, è utilizzare buffers di dimensioni adeguate.

Più il buffer è grande, maggiore è la tolleranza del sistema al 'rirardo' dei pacchetti, ma dalla dimensione del buffer dipende la latenza, quindi SE il protocollo impone limiti di latenza, si devono limitare le dimensioni dei buffers.

La latenza massima ammessa (a standard) da AES67 è di 6 ms, a 44100 Hz/16bit 2 canali un pacchetto contiene circa 1 ms di musica, aumentando la risoluzione serviranno più pacchetti (più traffico) per 'garantire' quei 6 mSec, quindi aumenta il rischio di xRuns.

A 384K/32/2 siamo a circa il 50% delle capacità di un 'normale' NIC 100T, qualsiasi apparato di rete ha un buffer, pur minimo, quindi aumenta la latenza complessiva.

Siamo così lontano dal punto critico da poter escludere che si presentino abbastanza microinterruzioni/salti da diventare udibili anche senza assumere la forma di dropouts (parliamo di < 1ms)?

Io non ho trovato documentazione in merito, di certo nella mia esperienza, buffer più grandi producono un effetto di 'rilassamento' e maggiore focalizzazione del messaggio, forse i due aspetti sono collegati, ma è solo un'ipotesi, non ho certezze in merito.

Però...

6 ms di latenza massima sono utili per sistemi live, di acquisizione audio o multicanale (su stream diversi), ma per la semplice riproduzione di un unico stream sono del tutto inutili, a chi importa se il sistema risponde ai comandi con un ritardo di 6 o 600 ms ?

Non ho idea se si sia possibile regolare la latenza nel driver di Ravenna, se si, proverei a farlo per capire cosa succede. Se non è possibile, valuterei bene l'opportunità degli optocoupler, che certamente aggiungono latenza. Forse il NIC del PC24 è semplicemente di qualità superiore a quello 'commerciale' sui tuo pc?

Tracciare ed analizare il traffico di rete, per capire se ci sono criticità e dove, potrebbe risultare utile.

Solo uno spunto di riflessione, ma è bene considerare che TCP/IP e AES67 (Ravenna) non sono la stessa cosa.

[marcoc1712]

Non te lo sei sognato, pc e dac vedono interposti tra le rispettive schede di rete due media converter ethernet fibra, cioè due TP-Link MC200CM

In realtà intendevo la rete di alimentazione, avevi scritto che sono su due linee isolate, da cui avevo (frettolosamente) dedotto ci fosse un isolatore.

[grunter]

In realtà intendevo la rete di alimentazione, avevi scritto che sono su due linee isolate, da cui avevo (frettolosamente) dedotto ci fosse un isolatore.

Ah.. Non c'è un isolatore ma il PC è sulla linea standard (quella su cui sono presenti tutte le prese di casa) mentre la pesa dedicata allo stereo è separata e parte dal quadro elettrico posto dopo il contatore ma a monte di tutte le altre prese e quadri elettrici.

Inviato dal mio A0001 utilizzando Tapatalk

[grunter]

Non so se è OT, nel qual caso eventualmente autorizzo da subito a spostare o cancellare.

Ravenna è un protocollo 'real ltime' appoggiato su IP, che di sua natura è asincrono e NON garantisce la consegna di tutti i pacchetti (anche se è rarissimo) e tantomeno il tempo massimo di consegna.

Ci sono solo 2 modi per gestire la continuità in una trasmissioni a pacchetti:

a. si aspetta finche non è disponibile il pacchetto con la porzione di stream da inviare.
b. quando è il momento se il pacchetto non è disponibile si salta al primo disponibile successivo.

entrambe le situazioni provocano 'disturbi' e sarebbero da minimizzare, il modo per farlo, data una determinata infrastruttura di rete ed una situazione di traffico, è utilizzare buffers di dimensioni adeguate.

Più il buffer è grande, maggiore è la tolleranza del sistema al 'rirardo' dei pacchetti, ma dalla dimensione del buffer dipende la latenza, quindi SE il protocollo impone limiti di latenza, si devono limitare le dimensioni dei buffers.

La latenza massima ammessa (a standard) da AES67 è di 6 ms, a 44100 Hz/16bit 2 canali un pacchetto contiene circa 1 ms di musica, aumentando la risoluzione serviranno più pacchetti (più traffico) per 'garantire' quei 6 mSec, quindi aumenta il rischio di xRuns.

A 384K/32/2 siamo a circa il 50% delle capacità di un 'normale' NIC 100T, qualsiasi apparato di rete ha un buffer, pur minimo, quindi aumenta la latenza complessiva.

Siamo così lontano dal punto critico da poter escludere che si presentino abbastanza microinterruzioni/salti da diventare udibili anche senza assumere la forma di dropouts (parliamo di < 1ms)?

Io non ho trovato documentazione in merito, di certo nella mia esperienza, buffer più grandi producono un effetto di 'rilassamento' e maggiore focalizzazione del messaggio, forse i due aspetti sono collegati, ma è solo un'ipotesi, non ho certezze in merito.

Però...

6 ms di latenza massima sono utili per sistemi live, di acquisizione audio o multicanale (su stream diversi), ma per la semplice riproduzione di un unico stream sono del tutto inutili, a chi importa se il sistema risponde ai comandi con un ritardo di 6 o 600 ms ?

Non ho idea se si sia possibile regolare la latenza nel driver di Ravenna, se si, proverei a farlo per capire cosa succede. Se non è possibile, valuterei bene l'opportunità degli optocoupler, che certamente aggiungono latenza. Forse il NIC del PC24 è semplicemente di qualità superiore a quello 'commerciale' sui tuo pc?

Tracciare ed analizare il traffico di rete, per capire se ci sono criticità e dove, potrebbe risultare utile.

Solo uno spunto di riflessione, ma è bene considerare che TCP/IP e AES67 (Ravenna) non sono la stessa cosa.

Si il driver Ravenna permette di fissare il numeri dei campioni asio, la latenza ed il numero di canali in input (qualora si disponga di scheda a/d) e output.
Appena possibile metto degli screenshot.
Ti posso dire che solitamente tengo settati i valori minimi di latenza nel driver e i valori massimi di buffer nella scheda di rete.

Il nic integrato sulla motherboard che uso per l'hapi è un Intel i217v ma ho anche a disposizione una scheda pro PCI xpress (Intel E1G42ETBLK) con cui non ho notato differenze rispetto a quella integrata.

[UnixMan]

Ti posso dire che solitamente tengo settati i valori minimi di latenza nel driver [...]

per i ns. scopi mi sembra assolutamente controproducente... al contrario, dovresti settarli al valore MASSIMO consentito!

[marcoc1712]

Ah.. Non c'è un isolatore ma il PC è sulla linea standard (quella su cui sono presenti tutte le prese di casa) mentre la pesa dedicata allo stereo è separata e parte dal quadro elettrico posto dopo il contatore ma a monte di tutte le altre prese e quadri elettrici.

Inviato dal mio A0001 utilizzando Tapatalk

Puoi certamente provare ad aggiungere un autotrasformatore, magari filtrato, a monte del PC. 30-40 euro e te la cavi, male non fa di certo, se vuoi qualcosa di più 'figo' puoi cercare un 'vecchio' isolatore BCD, io ne ho uno prima di ogni apparecchio, tranne i finali, e vanno benisimo.

[UnixMan]

Puoi certamente provare ad aggiungere un autotrasformatore,

e a che serve un autotrasformatore, in questo caso? Casomai, un trasformatore di isolamento...

[marcoc1712]

e a che serve un autotrasformatore, in questo caso? Casomai, un trasformatore di isolamento...

Si, errore mio, chiedo scusa.