Question Foobar

» 06 Déc 2006 14:52

>Plus sûrement une incidence positive sur le jitter je pense.

Je ne comprend pas ce que tu veux dire. Il n'y a pas de notion de jitter tant qu'on reste ds le domaine numérique interne au PC. La machinerie numérique garantit que les 0 et les 1 envoyée à la CS sont ok et que le buffer interne à la CS ne sera jamais vide pdt la lecture (pas de présence de "pops").

Les données du buffer de la CS sont consommées par les DAC à un bout et alimentée via le bus PCI ou la liaison firewire à l'autre bout. C'est le driver de la CS qui gère le fonctionnement de ce buffer.

Le jitter n'intervient qu'au moment de la conv num->analog. Il est induit par la qualité (stabilité) de l'horloge qui pilote le DAC. Ca n'a rien à voir avec le traitement des infos numériques ds le PC (heureusement car le cheminement d'un signal audio depuis un DD ou un CD est une sacrée aventure : ça commence par une visite du buffer du DD ou du lecteur DVD, puis ensuite de multiple allé-retours sur les bus de données entre la RAM et la mémoire cache du CPU (1 et 2e niveaux) pdt que le CPU traite les données (prg foobar), puis envoi au buffer de la CS. Il n'y a pas de jitter au sens ou l'entende les audiophiles pdt cette phase. Le système d'exploitation + les drivers des différents périphériques mis en cause garantissent que pas un bit ne se perd au cours du cheminement).

@+
Emmanuel

» 06 Déc 2006 15:06

C'est toi l'expert.

Ceci dit, le jitter peut exister aussi en numérique : http://www.forum.audioaddict.fr/viewtopic.php?t=262

Mais je te l'accorde, je crois qu'on pinaille là. ;-)

» 06 Déc 2006 16:06

totafée josé, et pour paraphraser les dupont/d :

je dirais même plus, hors du domaine numérique point de jitter. :mdr:

plus sérieusement, les risques de jitter qui concernent un pchifi/hc doivent se limiter au niveau des dacs et donc être à peu près maitrisés, négligeables dans le cas cas d'une carte bien conçue.

sans doute d'ailleurs que ce sacré jitter est bien plus critique lorsqu'on cascade deux cartes en numérique, sans référence d'horloge exerne. :wink:

» 06 Déc 2006 17:26

Jose Hidalgo a écrit:C'est toi l'expert.

Ceci dit, le jitter peut exister aussi en numérique : http://www.forum.audioaddict.fr/viewtopic.php?t=262

Mais je te l'accorde, je crois qu'on pinaille là.

Tout ce qui est sur ce site bien connu est rigoureusement exact et rigoureusement inappliquable à ce qu'il se passe dans ton PC en dehors des conv AN et NA.

Je vais essayer d'être clair : Le jitter est partout ominiprésent dans une électronique numérique. Dès l'instant ou tu demandes à un transistor de commuter, tu as forcément du jitter. Donc, il y a du jitter ds le CPU, dans la RAM, dans tout ce que tu veux qui comporte des transistors. De même, dès l'instant où tu as un fil de connection (une piste sur une CM par exemple) entre deux éléments, tu as du jitter induit par la structure électronique de cette connection.

SAUF QUE :

*** une machine numérique est construite de manière à ce que son fonctionnement ne soit pas altéré par le jitter présents dans tous les éléments qui la compose *** . Autrement dit, les tolérances de fonctionnement sur les composants sont suffisamment large pour que si un transistor commute un pouillème plus tard que ce qui est prévu nominalement, cela n'affecte pas la chaîne aval ***

Ce fonctionnement est garanti par la hardware du PC (ainsi que le software bas niveau qui gère les communications ds le PC).

Si ne n'était pas le cas, ton PC ne booterai même pas.

Au passage, garantir tout cela n'est pas simple quand l'information est traité à plusieurs GigaHertz comme c'est le cas ds un PC... Mais les softs de CAO électronique tiennent compte des tolérance sur le jitter pour la conception des circuits haute fréquence.

Donc, je le répète à nouveau, en lecture de wav sur DD , la seule source de jitter se trouve au moment de la conv NA, et là effectivement, une bonne horloge externe sur l'entrée "clock" de la CS peut faire la différence.

@+
Emmanuel

» 06 Déc 2006 18:44

Manu, j'avais déjà tenté ça la dernière fois --->

Cette fois-ci je tente carrément ça --->

Bon, voilà qui règle la question du jitter. Je me demande en revanche si mon idée initiale (tout précharger en RAM dans foobar) ne trouverait pas son utilité quand-même dans le cas d'un serveur de fichiers distant, lorsqu'on utilise le seeking par exemple. Il doit bien y avoir une latence sensible non ?

Ou tout simplement parce que, vu que foobar bufferise, les modifs (volume, seeking, etc.) ne sont appliquées réellement sur le son audible que quelques secondes après avoir appuyé sur les touches (le nb de secondes étant bien sûr égal à la durée paramétrée dans le buffer, de 1 à 10 quoi). Essayez avec une durée de 10, c'est rigolo. :lol:

Si on pré-chargeait tout en RAM, on pourrait se permettre d'avoir une durée de buffer quasiment nulle dans foobar non ?

Zenpensékwa ? ;-)

» 06 Déc 2006 18:55

Sur le sujet, un extrait qui fait écho à Emmanuel.

Often sampling jitter is confused with data link jitter. They are linked because inappropriate clock recovery circuits are often used for deriving sampling clocks from the interface signal - which will often have relatively high levels of jitter as a result of the information being carried. This data link jitter need not affect the quality of the finally reproduced signal - until it is so large that the data errors are produced - and measurements of data link jitter may not give any clue as to sampling jitter in the associated equipment.

» 06 Déc 2006 19:23

Jose Hidalgo a écrit: Je me demande en revanche si mon idée initiale (tout précharger en RAM dans foobar) ne trouverait pas son utilité quand-même dans le cas d'un serveur de fichiers distant, lorsqu'on utilise le seeking par exemple. Il doit bien y avoir une latence sensible non ?

Ou tout simplement parce que, vu que foobar bufferise, les modifs (volume, seeking, etc.) ne sont appliquées réellement sur le son audible que quelques secondes après avoir appuyé sur les touches (le nb de secondes étant bien sûr égal à la durée paramétrée dans le buffer, de 1 à 10 quoi). Essayez avec une durée de 10, c'est rigolo. Si on pré-chargeait tout en RAM, on pourrait se permettre d'avoir une durée de buffer quasiment nulle dans foobar non ?

Zenpensékwa ?

Si tu as un serveur distant, il faudrait faire des tests mais il est probable que le débit audio même pour un wav multicanal en wav natif 24/96 ne pose pas de pb... idem pour le seeking. Donc l'intérêt comme tu l'as dit un peu avant serait surtout de pouvoir arrêter le DD, tous les échanges se faisant par réseau.

Dans ce cas, à mon avis pour une machine dédiée audio pure, il faut carrément aller plus loin et virer le DD en bootant sur une clé USB. Ca sera un poil plus long, mais en audio pure je ne vois pas de désavantages. Nota : cette approche est "classique" sous linux par la communauté qui fait de la convo :

http://www.duffroomcorrection.com/wiki/ ... mory_stick

Sinon, pour le buffer de foobar, je met 256 Ko, ce qui fait une toute petite latence lors de réglage du volume qui n'est pas désagréable du tout

@+
Emmanuel

» 06 Déc 2006 19:32

Emmanuel Piat a écrit: en lecture de wav sur DD , la seule source de jitter se trouve au moment de la conv NA, et là effectivement, une bonne horloge externe sur l'entrée "clock" de la CS peut faire la différence.

Tu te situes en cas d'utilisation d'un dac externe je suppose, pas en utilisation du dac de la carte son ?

» 06 Déc 2006 19:38

Emmanuel Piat a écrit: Dans ce cas, à mon avis pour une machine dédiée audio pure, il faut carrément aller plus loin et virer le DD en bootant sur une clé USB. Ca sera un poil plus long, mais en audio pure je ne vois pas de désavantages. Nota : cette approche est "classique" sous linux par la communauté qui fait de la convo :

http://www.duffroomcorrection.com/wiki/ ... mory_stick

C'est jouable sous windows pour toi ?

J'attendais dans le même esprit les portables avec "mémoires disques" qui semblent s'annoncer mais cette solution serait plus économique et pourrait être mise en oeuvre plus rapidement.

» 06 Déc 2006 20:03

J'ai un pote qui a acheté une clé USB2 de 4 Go pour booter dessus... bilan, c'est un b... sans nom, il a passé des heures et des heures à tenter d'installer Windaube dessus, à modifier des fichiers à la main pour rendre le tout installable/bootable... sans succès. Donc pas vraiment facile, y compris quand on est un poil expérimenté comme lui.

Perso j'opterais plus pour la solution CompactFlash. Seul inconvénient, une CompactFlash est limitée dans le nb de lectures/écritures qu'on peut faire sur un secteur donné (environ 100.000 je crois). Donc il faut absolument installer un OS stable dessus, puis interdire au maximum toutes les écritures système (dates de modification fichiers, etc.). Est-ce que quelqu'un aurait connaissance d'un tuto sur le net à ce sujet (démarrage OS sur CompactFlash en verrouillant les écritures) ?

Sinon la solution ultime c'est le i-RAM de Gigabyte (renommé dernièrement). Démarrage Windows en 5 secondes, lancement des applis instantané. Mais bonjour le prix !!!

» 06 Déc 2006 20:38

Emmanuel Piat a écrit:>Plus sûrement une incidence positive sur le jitter je pense.

Je ne comprend pas ce que tu veux dire. Il n'y a pas de notion de jitter tant qu'on reste ds le domaine numérique interne au PC. La machinerie numérique garantit que les 0 et les 1 envoyée à la CS sont ok et que le buffer interne à la CS ne sera jamais vide pdt la lecture (pas de présence de "pops").

Les données du buffer de la CS sont consommées par les DAC à un bout et alimentée via le bus PCI ou la liaison firewire à l'autre bout. C'est le driver de la CS qui gère le fonctionnement de ce buffer.

Le jitter n'intervient qu'au moment de la conv num->analog. Il est induit par la qualité (stabilité) de l'horloge qui pilote le DAC. Ca n'a rien à voir avec le traitement des infos numériques ds le PC (heureusement car le cheminement d'un signal audio depuis un DD ou un CD est une sacrée aventure : ça commence par une visite du buffer du DD ou du lecteur DVD, puis ensuite de multiple allé-retours sur les bus de données entre la RAM et la mémoire cache du CPU (1 et 2e niveaux) pdt que le CPU traite les données (prg foobar), puis envoi au buffer de la CS. Il n'y a pas de jitter au sens ou l'entende les audiophiles pdt cette phase. Le système d'exploitation + les drivers des différents périphériques mis en cause garantissent que pas un bit ne se perd au cours du cheminement).

@+
Emmanuel

Ben, je ne suis pas tout à fait d'accord : (ou alors je suis tombé dans l'audio(idiot ?)-philie ésotérico-mystique :mdr:

)

J'ai fait des essais répétés avec mon PC branché sur un convertisseur Audionote Dac zéro à travers une carte Terratec (M-audio) Universe, sans aucun filtre numérique dans le chemin et en sortant en numérique coaxial à 44,1khz.

1 - Lecture de CD à partir du lecteur de CD avec FooBar sortie en mode "Direct Sound".
2 - Lecture du même morceau en .APE depuis le DD avec FooBar sortie en mode "Direct Sound"
3 - Idem en sortie en mode "Kernel Streaming".

Croyez-le ou pas, ça s'entend !!, le meilleur étant en lecture DD + kernel streaming.

AMHA, le lecteur de CD du micro doit influer sur l'alimentation => jitter +++.
Et il doit y avoir des effets nocif du système de tampon directsound => jitter +.

» 06 Déc 2006 21:08

ton test confirme juste que le kernel streaming est supérieur au direct sound, vu qu'il bypasse le mixer windows, non ?

» 06 Déc 2006 21:22

Pas tout à fait :
1 - avec le volume master et wave à fond, le mixer windows ne devrait avoir aucune influence.
2 - ce qui est surtout troublant, c'est que la lecture du même flux de bits à partir d'un fichier du disque dur ou à partir du lecteur de CD ne donne pas le même son.

Par ailleurs, j'ai pu constater qu'on "entend" si le CPU fait des traitements ou pas en écoutant le sifflement de l'écran (il change suivant ce qu'on fait :roll:

).

A fortiori, comme le signal numérique est généré avec une horloge interne à la carte son et qu'il est bien connu que la dérive est extrèmement sensible à la stabilité de l'alimentation, il n'est pas absurde de penser que la façon dont le processeur est chargé influe sur le jitter induit :

quand il bosse beaucoup, il consomme beaucoup => l'alimentation travaille plus et la tension est plus irrégulière => plus de jitter.
quand il bosse moins, il consomme moins => l'horloge ne se comportera pas pareil. CQFD!

» 06 Déc 2006 22:00

Houla, tu mélanges tout.
Le jitter est du bruit temporel, il influe essentiellement sur la conversion A/D D/A.
Premièrement pour que l'alim influe à ce point, et indirectement le cpu, il faudrait que tu ais une alim sous dimensionnée et une carte son pourrie sans découplage des tensions.
Ce que tu entend provient d'une mauvaise gestion des Irq par ta carte mère et ton OS, fait une petite recherche sur le sujet dans le sommaire.
C'est un phénomène bien connue dite de l'armée de criquets. :wink:

» 06 Déc 2006 22:30

Jose Hidalgo a écrit:J'ai un pote qui a acheté une clé USB2 de 4 Go pour booter dessus... bilan, c'est un b... sans nom, il a passé des heures et des heures à tenter d'installer Windaube dessus, à modifier des fichiers à la main pour rendre le tout installable/bootable... sans succès. Donc pas vraiment facile, y compris quand on est un poil expérimenté comme lui.

Je suis tombé la dessus, ça a l'air sympa
http://www.tomshardware.fr/windows_dans_la_poche_-art-1031-1.html