Rumori ad alta frequenza e il PC

[grunter]

Non ho avuto modo di guardare dentro il pc... si tratta di un pc in vendita che costa caro, purtroppo, come dicevo.
Come scrivevo parlando con il venditore/creatore dell'oggetto quello che mi ha detto è questo:
- Case costruito con materiale atto a schermare emi/rfi
- Base antivibrazioni e sistema antivabrazioni anche interno al case
- Uso di motherboard di tipo industrial, nata cioè per lavorare h24
- Particolare attenzione a mantenere il più costante possibile la temperatura di esercizio del pc
- Sostituzione di alcuni condensatori con altri di qualità al top
- Alimentazione (non atx) switch 12v costruita ad hoc e schermata dal resto

Poi se sono mitologie ed io sono stato succube di psicoacustica non so, tutto possibile.
Sarei propenso a credere che non siano mitologie vista la resa finale, ma posso essermi sbagliato.
Dunque ipotizzando che queste accortezze siano reali ed io non mi sia sbagliato a valutare la resa finale direi che ho sempre trascurato, colpevolmente, questi aspetti e che invece se tenuti di conto possono dare risultati migliori di casi in cui si bada al sodo per i componenti ma si trascurano.

[madman]

scusa ma marca e modello del prodotto di cui parli?

[grunter]

E' il system 24 di Vdm, distributore di Merging.

[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.

[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!

[grunter]

Il mio Merging Hapi non credo possa funzionare con LMS e squeezelite.
Sempre nel mio caso l'hapi ed il PC sono distanti più di due metri fisicamente ed isolati elettricamente, infatti uso degli adattatori in fibra, cioè pc-ethernet-fibra-ethernet-hapi, ciò nonostante le differenze tra il mio PC ed il system 24 sono nette.
Dunque son portato a pensare che alcuni tra gli aspetti sopra menzionati o anche tutti insieme contribuiscano a rendere la qualità di ascolto superiore, o meglio a non degradarla cosa che avviene con il mio PC.

Inviato dal mio A0001 utilizzando Tapatalk

[marcoc1712]

Il mio Merging Hapi non credo possa funzionare con LMS e squeezelite.

Perchè? Se non sbaglio hai un driver che simula la presenza di una scheda audio locale, il pc su cui gira squeezelite la vede? Se si, dovresti senz'altro poterla selezionare ed usare, se no è un problema di configurazione di quel PC, puoi risolverlo o installare squeezelite su quello già collegato all'hapi, dovrebbe andare senza problemi, ma occhio ai buffer ed alla RAM.

Se non va e mi mandi il messaggio di errore (magari nel log di squeezelite) ci guardo volentieri.

Sempre nel mio caso l'hapi ed il PC sono distanti più di due metri fisicamente ed isolati elettricamente, infatti uso degli adattatori in fibra, cioè pc-ethernet-fibra-ethernet-hapi, ciò nonostante le differenze tra il mio PC ed il system 24 sono nette.
Dunque son portato a pensare che alcuni tra gli aspetti sopra menzionati o anche tutti insieme contribuiscano a rendere la qualità di ascolto superiore, o meglio a non degradarla cosa che avviene con il mio PC.

L'isolamento elettrico lo hai sul cavo ethernet, se i pc sono distanti due metri ed attaccati allo stesso ramo di alimentazione (insieme agli switch dei TP-Link) hai certamente più probabilità che il rumore elettrico passi di li. Perchè l'altro suona meglio? potrebbe semplicemnete essere un migliore qualità ed isolamento dell' alimentazione (minori schifezze inviate in rete).

A mio avviso, il vero, grande, vantaggio di usare ethernet è quello di tenere il server FUORI dalla sala di ascolto (>> i 3 m di USB) con ramo di alimentazione isolato, evitando qualsiasi possibile inquinamento... Il network audio player è la sublimazione di questo principio, peccato invalidarlo.

Per una prova, puoi usare wifi e e verificare SE il miglioramento è nel collegamento via cavo o meno...

Le prove le hai fatte nello stesso ambiente, impianto e configurazione elettrica/di rete?

Cosa succede se inserisci uno switch immediatamente a monte del DAC e colleghi entrambi i PC? Le differenze permangono?

[grunter]

Perchè? Se non sbaglio hai un driver che simula la presenza di una scheda audio locale, il pc su cui gira squeezelite la vede? Se si, dovresti senz'altro poterla selezionare ed usare, se no è un problema di configurazione di quel PC, puoi risolverlo o installare squeezelite su quello già collegato all'hapi, dovrebbe andare senza problemi, ma occhio ai buffer ed alla RAM.

Se non va e mi mandi il messaggio di errore (magari nel log di squeezelite) ci guardo volentieri.



L'isolamento elettrico lo hai sul cavo ethernet, se i pc sono distanti due metri ed attaccati allo stesso ramo di alimentazione (insieme agli switch dei TP-Link) hai certamente più probabilità che il rumore elettrico passi di li. Perchè l'altro suona meglio? potrebbe semplicemnete essere un migliore qualità ed isolamento dell' alimentazione (minori schifezze inviate in rete).

A mio avviso, il vero, grande, vantaggio di usare ethernet è quello di tenere il server FUORI dalla sala di ascolto (>> i 3 m di USB) con ramo di alimentazione isolato, evitando qualsiasi possibile inquinamento... Il network audio player è la sublimazione di questo principio, peccato invalidarlo.

Per una prova, puoi usare wifi e e verificare SE il miglioramento è nel collegamento via cavo o meno...

Le prove le hai fatte nello stesso ambiente, impianto e configurazione elettrica/di rete?

Cosa succede se inserisci uno switch immediatamente a monte del DAC e colleghi entrambi i PC? Le differenze permangono?

Per squeezelite proverò.
Per il discorso alimentazione il PC con l'adattatore in fibra è sulla linea elettrica standard di casa, mentre l'impianto stereo (hapi compreso con l'altra interfaccia in fibra) è su una linea dedicata che arriva direttamente dal contatore.
Dunque elettricamente sono su due linee elettriche separate.
La prova l'ho fatta mettendo i PC, il mio ed il system 24, nelle stesse identiche condizioni.

Inviato dal mio A0001 utilizzando Tapatalk

[marcoc1712]

Per squeezelite proverò.
Per il discorso alimentazione il PC con l'adattatore in fibra è sulla linea elettrica standard di casa, mentre l'impianto stereo (hapi compreso con l'altra interfaccia in fibra) è su una linea dedicata che arriva direttamente dal contatore.
Dunque elettricamente sono su due linee elettriche separate.
La prova l'ho fatta mettendo i PC, il mio ed il system 24, nelle stesse identiche condizioni.

Inviato dal mio A0001 utilizzando Tapatalk

Tutto sembrerebbe restringere il campo al segnale elettrico che arriva al NIC sull'Hapi.

Ovviamnete credo a quello che riporti, ma mi lascia ben perplesso. Se fossi in te sarei curiosissimo di stabilire se le differenze sono imputabili a Ravenna o al PC, usandolo immediatamente in una configurazione solo IP con un normale dac USB ed un pc player remoto (player, non server).

Se in questo modo le differeze svanissero, sarebbe una bella bandiera gialla per Ravenna (nel bene e nel male) permanessero sarebbe un bel punto interrogativo per quel PC e varrebbe certamente la pena investigare più a fondo.

Tienici informati.