JAVA Alive a écrit:pouly a écrit:Donc, juste pour répondre avec humour à JAVA :
Tu confonds le transport de fichiers informatique avec le transport de fichiers audio ou la notion de temps à une importance vu du côté du convertisseur ce qui peut expliquer une signature de la part d'un câble USB sur des fichiers audio quand bien même que ce câble pourra transférer des fichiers informatique sans signature sonore ( ils n'en ont pas ce ne sont que des un et des zéro stokés dans une mémoire ) ce sera quand tu transfert depuis la mémoire ces un et zéro à l'entrée du convertisseur qu'ils prendrons une signature sonore à cause du temps qui peut varier entre deux transferts ( à cause du câble ou de tout autre phénomène perturbateur )
Et non et non et non. Pas en asynchrone.
En asynchrone, on est sur de la donnée pure.
C'est dans le DAC que cette notion de temps (jitter) intervient car c'est dans le DAC qu'est créé, à partir de la mémoire des bits reçus et de l'horloge interne, le signal envoyé au chip convertisseur.
Edit : dans un DAC Asynchrone bien fait (je ne sais pas si c'est le cas de tous), c'est même le DAC qui dirige le transfert de données.
C'est lui qui dit quand envoyer, et les données sont envoyées par paquets.
En cas d'erreur, le DAC demande le renvoi.
Edit 2 : Pouly, j'attends toujours d'ailleurs ta définition de ce que tu appelles jitter logiciel ou OS.
Je n'avais pas compris que l'usb asynchrone fonctionnait de cette manière, mais si tu le dit effectivement les problèmes de jitter liés au transport en USB sont réglés, ceux liés au jitter logiciel ou OS aussi
Mais fait quand même un essai, fait tourner Jplay sous win 8 ou win server 2012 ou simplement optimise l'os pour limiter les services au minimum pour voire si tu entends une différence.