Source numérique à base de PC : fonctionnement détaillé

[WhyHey]

un exemple de CS externe USB :
http://www.rme-audio.de/download/bface_fr.pdf
page 67.

pour les cartes sons internes, tout passe par le Interface High Definition Audio Bus (par exemple), qui suit l"UAA :
http://en.wikipedia.org/wiki/Universal_ ... chitecture
par exemple cette carte son:
http://www.chrontel.com/media/Datasheet ... rev1.9.pdf
qui suit cette spec et la doc "UAA_guidelines.doc":
http://www.intel.com/content/dam/www/pu ... cation.pdf
en gros l'UAA stock dans des memoires et possède une seule horloge à 24 MHz (voilà pourquoi 90% des cartes son s internes sont à 48KHz d'échantillonnage), tout driver est connecté à cette horloge directement.

après sur la synchronisation, page 72 de la spec:
There are three different domains in which synchronization of streams is desired. They are multiple streams on different systems, multiple streams on different controllers in the same system, and multiple streams on the same controller.
The High Definition Audio Specification does not provide any mechanisms to aid in synchronizing streams on two different systems but does provide mechanisms to synchronize streams within a system. The wall clock can be used to synchronize between two separate controllers which do not share a common clock, and the stream start synchronization can be used to synchronize exactly two streams on the same controller.

et pour la synchro avec la cpu:
il y a un lien de type controlleur PCI entre les mémoires cpu et les mémoires UAA (dites DMA), le propre d'une connexion PCI est d'être compatible/soumise/asservis avec la clock de ce bus, l'UAA est donc obligé de se conformer à cette horloge. pour autant rien n'indique que l'horloge du bus pci (callée sur l'horloge cpu) est callée sur l'horloge UAA. Je pense donc l'inverse (l'horloge de l'UAA est indépendante de l'horloge cpu), en attendant d'en trouver une preuve quelconque.
Par ailleurs un système de control de mémoire permet de savoir à chaque instant où on en est dans les différentes lectures de buffer:
http://www.intel.com/content/dam/www/pu ... fering.pdf
permettant au soft de piloter la taille de la mémoire de cpu.
c'est le propre de la couche dite "azalia" de faire le lien entre mémoire cpu adressable via PCI et mémoire UAA dans les DMA.

[Pio2001]

Hello Pio,

En fait, le jitter représente une disotorsion à part entière dans le domaine analogique

Je ne te suis pas, si tu as des sources à ce propos ça m'intéresse ?
richarpe parle d'une mesure en sortie de DAC, dans ce cas le jitter de l'horloge de conversion provoque l'apparition de fréquences supplémentaires sur le signal audio, un peu comme de l'intermodulation. Voir par exemple http://www.stereophile.com/reference/193jitter/index.html (page 2).
Si on s'intéresse simplement au signal numérique, le jitter c'est juste des réflexions qui s'ajoutent au signal initial, donc une sorte de distorsion de phase.

Des sources non, mais le jitter se manifeste en analyse spectrale par des pics de faible intensité au pied d'une fréquence signal pure. Tant qu'il n'y a rien à 2f, 3f... nf, la DHT est nulle. Le jitter est un décalage temporel. L'intensité n'est pas affectée. Donc la bande passante est intacte puisque c'est une mesure d'intensité. Le jitter est une variation de l'horloge autour d'une valeur moyenne. Donc la phase, si elle est parfois en avance, parfois en retard, sera nulle en moyenne par rapport à la référence. Pour l'intermodulation, c'est plus compliqué à démontrer et je n'ai pas de certitude absolue. L'intermodulation vient du fait qu'une fréquence est modulée en amplitude à une autre fréquence, représentant ainsi un battement dont l'origine est f1 + f2, puisque la fréquence d'un battement entre deux fréquences est égal à la différence entre ces deux fréquences. Or le jitter ne provoque aucune modulation d'amplitude. Donc je pense que le jitter ne provoque pas d'intermodulation...

[Denis31]

Pio, je pense qu'on est d'accord sur le fond, mais dans tes explications tu mets sur le même plan les distorsions du signal numérique et celles du signal analogique après conversion. Sur celui-ci le jitter provoque l'apparition de nouvelles fréquences dont la répartition dépend du contenu spectral du jitter lui-même, c'est ce que j'appelle improprement sans doute 'une sorte d'intermodulation'. C'est bien expliqué dans le lien que j'ai donné.

[richardpe]

y a pas de pll sur les CS ??

Si, sur celles qui ont une entrée numérique. On peut alors (parfois) choisir le mode de synchro du flux sortant: soit sur l'horloge interne, soit sur sur le flux entrant.

Toutafé.
Sur la plupart des cartes son, je pense, il y a une horloge dédiée. C'est une petite boîte métallique perdue parmi les autres composants soudés sur la carte. Comme un condensateur, sauf que cela n'a pas la forme d'un condensateur. Il y a un quartz à l'intérieur.
C'est elle qui est maîtresse du timing lorsqu'on joue de l'audio sur PC. C'est ainsi que sur les logiciels de lecture de DVD standards, comme c'est la carte son qui décide de la vitesse de lecture, l'image gagne ou perd une trame de temps en temps, parce qu'elle n'est pas synchronisée avec l'horloge de la carte vidéo. Ce n'est peut-être pas le cas pour les logiciels à compensation de mouvement, qui recréent des images à une cadence différente des originaux, et ce ne sera pas le cas non plus si le son sort directement en HDMI de la carte vidéo, auquel cas la lecture du DVD peut être soumise à la seule horloge de la carte vidéo.

Il est d'ailleurs tout-à-fait possible d'utiliser l'HDMI comme sortie audio numérique si la carte vidéo comporte des drivers audio. C'est une option que l'on n'a pas abordée.

Comme l'indique Denis31, on peut utiliser une configuration un peu tordue : on branche une mécanique CD hifi sur l'entrée numérique de la carte son, et dans le panneau de contrôle de la carte son, on règle l'horloge sur "externe". La carte devient alors esclave du drive externe.

Le juge de paix ne serait il pas tous simplement de mesurer les signaux carré sortant le PCM des SPDIF corréler à une mesure du jitter selon un protocole viable (Dunn ?) ainsi qu' une mesure du ripple et son influence sur les deux autres mesures ?

Juge de paix, non, car ce n'est qu'une mesure intermédiaire. Il faut mesurer le jitter résiduel tout au bout de la chaîne, sur la sortie analogique du DAC.
Pour cela, il faut un ADC de grande qualité (oscillo, carte son...), et se documenter sur les spectres associés au jitter et à la modulation d'amplitude pour interpréter le spectre que l'on va obtenir.

Seconde question et pas des moindres, peut on vraiment déterminer un seuil objectif des mesures reproduites et en tirer un aspect tangible de nos écoutes subjectives ?

Hors sujet pour le moment, à la demande de JAVA Alive.

La logique voudrait que ces mesures précités influencent sur le spectre audible mesuré en FFT sur les sorties analogiques d'un DAC via un analyseur ou quelque chose de voisin avec les critères suivants : dynamique, distorsion harmonique, bande passante, phase.

Bonne question. En fait, le jitter représente une disotorsion à part entière dans le domaine analogique. Un signal analogique peut être pourri de jitter, il n'aura pour autant ni distorsion harmonique, ni distorsion d'intermodulation, aucune limitation de bande passante, une dynamique impeccable etc. Les mesures de phase et de bruit seront impeccables, bien qu'en toute rigueur, un signal avec du jitter, par définition, a une phase instable et comporte un bruit.
Le jitter se mesure tout simplement en plus des autres critères.

Merci Pio 2001 pour tant de précision. Tu éveille ma curiosité.

Par contre sur le signal carré, désolé de le voir comme un aspect purement électrique et non numérique mais si le filtrage est mal fait au niveau de l'entrée de la PLL je suppose que le jitter prend des proportions inacceptables ? Quand le signal oscille rapidement dans la tension médian exemple de 2.5v à 5v, passe on du bruit numérique ?

Mes cours sur la transformée de fourrier sont tellement loin, je me demande si j’interprète correctement ma pensée.

[JAVA Alive]

Bonjour à tous,

beaucoup de posts intéressants depuis ma dernière intervention, je vais tenter de compiler.
Désolé, je suis super busy en ce moment (go live de SAP, certains comprendrons ) j'interviens donc trop rarement pour synthétiser vos apports en temsp et en heure, ça s'accumule donc un peu.

Notamment, en ce qui concerne l'horloge du signal, elle est où ? Sur la carte son ? C'est l'OS (donc le CPU ) qui la donne ?

Une carte-son possède en principe sa propre horloge. Elle peut donc dériver par rapport à celle du PC, c'est pourquoi c'est toujours le driver de la CS qui 'demande' des données à l'OS quand il en a besoin. Ensuite deux cas de figure: soit l'OS 'demande' alors des données au player; ou bien, le player remplit à son rythme un buffer intermédiaire et l'OS pioche dedans quand il faut. Dans ce dernier cas il faut un mécanisme pour garder le "niveau" de ce buffer à peu près constant i-e synchroniser le flux lu par le player et le flux consommé par la CS. Ce pb potentiel de synchronisation se retrouve d'ailleurs pour un périphérique USB asynchrone, alors que pour un USB synchrone c'est l'inverse: l'horloge est donnée par le bus, et c'est le DAC qui se synchronise dessus.

Ainsi pour illustration de la première question on pourrait prendre deux convertisseurs USB->spdif, l'un synchrone l'autre asynchrone, et tenter de mesurer en quoi la qualité du spdif délivré diffère.

La mesure serait effectivement un plus, si quelqu'un à le matos, qu'il n’hésite pas à se joindre à nous, je ne l'ai pas.
Je pense que la question du buffer sur la carte son ou dans le DAC asynchrone est clé. Si on arrive a bien confirmer qu'il y a un buffer et que l'horloge du DAC Asynch ou de la carte son est seul maîtresse (ce dont je suis sûr à 99% pour de DAC), la manière dont il est alimenté (donc tout ce qui se passe dans le CPU, la ram, le chipset and co) n'a aucune influence (sauf création d'un trou qui sera très audible). Tu confirmes à 100% la présence de horloge + buffer dans une carte son et un DAC Asynch ?

J'ignore volontairement le mode synchrone USB car je lui trouve des défauts importants (le synchrone justement) et l'asynchrone se démocratise. Et puis le sujet me semble assez large comme ça .

y a pas de pll sur les CS ??

La PLL sert à remettre en forme un signal numérique un peu crado donc quelque chose qu'on retrouve en entrée (d'un DAC ou d'une carte son pour la partie ADC qui est hors suejt ici). D'ailleurs, la présence de PLL et leur caractéristiques ne sont pas toujours clairement indiquées dans les specs des DACs. Une idée pour un autre topic dédié à ce suejt ?

@Java: je n'arrive pas à bien cerner l'objectif de ton topic, interessant par ailleurs ?
est-ce juste de décrire un mode de fonctionnement d'un dac en sortie de pc ?
ou est-ce de trouver les points qui peuvent expliquer des différences percues/mesurées entre 2 dac en sortie de pc ?

Je sais que le première post n'est pas super clair, je suis en train de revoir avec le staff pour améliorer ça.
Le but des de comprendre comment le signal numérique est généré du logiciel jusqu'à l'entrée du DAC en comprenant ce qui se passe dans les différents couches (sauf si on arrive à démontrer qu'une couche n'a pas d'impact à cause d'un élément en aval comme le cas du buffer expliqué ci-dessus). On peut aussi comparer à la mesure si qqun a le matos pour le faire. Je ne cherche pas à expliquer quoi que ce soit sur les différences perçues car le sujet est assez complexe comme ça pour ne pas en plus rajouter ce qui presque à coup sûr part en débats stériles. Mais pour ceux que ça tente, ouvrez un topic dédié aux différences perçues.

Le juge de paix ne serait il pas tous simplement de mesurer les signaux carré sortant le PCM des SPDIF corréler à une mesure du jitter selon un protocole viable (Dunn ?) ainsi qu' une mesure du ripple et son influence sur les deux autres mesures ?

Mesurer et comprendre le fonctionnement interne sont deux critères objectifs qui permettent une fois bien compilés, aprtagés et compris de tirer des conclusions. Les deux sont bienvenus, inutile de les opposer.

TVC Audio prône depuis le départ de la source un signal carré de qualité. Influence ??? Sachant que les convertisseurs actuels remettent en forme ce signal, quel intérêt ? https://sites.google.com/site/tvcaudio/

Seconde question et pas des moindres, peut on vraiment déterminer un seuil objectif des mesures reproduites et en tirer un aspect tangible de nos écoutes subjectives ?

Pour le signal, oui c'est pourquoi on parle PLL dans le topic.
Pour la seconde question, on sort du sujet car on se situe après le DAC, on rajoute encore une complexité (le chip du DAC, son alim' et tout ça). En ce concentrant sur le PC et le signal numérique, on arrivera à se faire une idée sur l’influence des softs et du hard PC, c'est déjà pas mal.

[JAVA Alive]

Sur la plupart des cartes son, je pense, il y a une horloge dédiée. C'est une petite boîte métallique perdue parmi les autres composants soudés sur la carte. Comme un condensateur, sauf que cela n'a pas la forme d'un condensateur. Il y a un quartz à l'intérieur.
C'est elle qui est maîtresse du timing lorsqu'on joue de l'audio sur PC. C'est ainsi que sur les logiciels de lecture de DVD standards, comme c'est la carte son qui décide de la vitesse de lecture, l'image gagne ou perd une trame de temps en temps, parce qu'elle n'est pas synchronisée avec l'horloge de la carte vidéo.

Quelqu'un saurai développer ? On n'a le même pb potentiel avec l'audio ? Ca semble se régler très simplement avec un petit buffer et ensuite un système où la carte demande au driver les bits pour remplir le buffer. Pour moi c'est LE point à creuser car il élimite potentiellement tout ce qui est lié au soft, l'OS, le CPU, la ram, etc.

Il est d'ailleurs tout-à-fait possible d'utiliser l'HDMI comme sortie audio numérique si la carte vidéo comporte des drivers audio. C'est une option que l'on n'a pas abordée

Non, j'ai volontairement réduit au coax et USB asynch pour simplifier. Le HDMI doit être proche du coax dans le principe, non ? je propose de se le garder sous le coude.

Je ne te suis pas, si tu as des sources à ce propos ça m'intéresse ?
richarpe parle d'une mesure en sortie de DAC, dans ce cas le jitter de l'horloge de conversion provoque l'apparition de fréquences supplémentaires sur le signal audio, un peu comme de l'intermodulation. Voir par exemple http://www.stereophile.com/reference/19 ... index.html (page 2).

Lien super inétressant, lu en diagonale uniquement. A suivre ...

n gros l'UAA stock dans des memoires et possède une seule horloge à 24 MHz (voilà pourquoi 90% des cartes son s internes sont à 48KHz d'échantillonnage), tout driver est connecté à cette horloge directement.

Tu peux développer. Qu'appelles-tu driver "connecté à une horloge" ?

Le chemin réellement suivi par les données est bien plus compliqué que cela si on veut regarder les détails. Chaque ligne de code du logiciel est susceptible d'aller chercher les données en ram pour les envoyer dans le CPU se faire déplacer, additionner, recopier etc. Il faudrait suivre individuellement le chemin de chaque signal électrique dans chaque piste de chaque puce... Il y a une mémoire tampon dans le disque dur, il y a conversion des données magnétiques des plateaux du disque au format SATA avant même d'atteindre la carte mère où elles seront gérées par des puces dédiées (southbridge ?), puis réception en RAM avant même d'être mis à disposition de l'OS (?), qui pourra les déplacer avant même de les envoyer au logiciel de lecture, donc aller-retour CPU, CPU qui comporte lui-même deux niveaux de mémoire cache interne...
Autant essayer de suivre la trajectoire de chaque goutte d'eau dans un orage.

Oui, là c'est clair qu'on n'arrive pas à suivre mais pour moi ce "chemin" ne peut pas influencer.
A un moment, les bits de l'échantillon sont mis en RAM car ils sont le résultat d'un calcul (lecture du disque, éventuelle décompression) effectué par le CPU et il les met en RAM. Ensuite, le contrôleur va lire directement en RAM via DMA (direct memory access) ou alors une fonction du driver est appelée et là je sèche.
Mais l'amont (production des bits en RAM) en peut pas jouer sur le résulta final (à bit égaux) sauf peut être à utiliser plus où moins le CPU et à influence les horloges fournies par l'OS si tant est qu'elles entrent en jeu. Tu es d'accord là dessus ?

[JAVA Alive]

Un exemple où on voit très bien une horloge (oscillator en anglais) : http://www.diyaudio.com/forums/pc-based ... ice-2.html
C'est le petit rectangle noir à côté du chip audio qui est estampillé 24,576

[Pio2001]

Sur la plupart des cartes son, je pense, il y a une horloge dédiée. C'est une petite boîte métallique perdue parmi les autres composants soudés sur la carte. Comme un condensateur, sauf que cela n'a pas la forme d'un condensateur. Il y a un quartz à l'intérieur.
C'est elle qui est maîtresse du timing lorsqu'on joue de l'audio sur PC. C'est ainsi que sur les logiciels de lecture de DVD standards, comme c'est la carte son qui décide de la vitesse de lecture, l'image gagne ou perd une trame de temps en temps, parce qu'elle n'est pas synchronisée avec l'horloge de la carte vidéo.

Quelqu'un saurai développer ? On n'a le même pb potentiel avec l'audio ? Ca semble se régler très simplement avec un petit buffer et ensuite un système où la carte demande au driver les bits pour remplir le buffer. Pour moi c'est LE point à creuser car il élimite potentiellement tout ce qui est lié au soft, l'OS, le CPU, la ram, etc.

Je n'ai pas compris. Quel problème potentiel ? Avoir l'audio qui n'est pas synchronisé avec l'horloge de l'audio ??

Mais l'amont (production des bits en RAM) en peut pas jouer sur le résulta final (à bit égaux) sauf peut être à utiliser plus où moins le CPU et à influence les horloges fournies par l'OS si tant est qu'elles entrent en jeu. Tu es d'accord là dessus ?

Tu sais, dans certaines sorties casques, on entend le mouvement du pointeur de souris ! Ca fait bzzzz quand il se déplace.
Il faut mesurer.

[JAVA Alive]

e n'ai pas compris. Quel problème potentiel ? Avoir l'audio qui n'est pas synchronisé avec l'horloge de l'audio ??

Ok, on est d'accord, rien à voir avec choucroute.

Tu sais, dans certaines sorties casques, on entend le mouvement du pointeur de souris ! Ca fait bzzzz quand il se déplace.
Il faut mesurer.

Parasitage de la partie analogique liée à l'activité CPU ou du bus souris ?
Jamais entendu ce phénomène en numérique, même avec des sorties AC97 ultra bas de gamme.

[Denis31]

Bonjour JAVA Alive,

J'ignore volontairement le mode synchrone USB car je lui trouve des défauts importants (le synchrone justement) et l'asynchrone se démocratise. Et puis le sujet me semble assez large comme ça .

Allons bon mais quels sont donc ces défauts justement ? le principe ne te plait pas certes, mais quelle(s) différence(s) au niveau du spdif sortant ?

Mais l'amont (production des bits en RAM) en peut pas jouer sur le résulta final (à bit égaux) sauf peut être à utiliser plus où moins le CPU et à influence les horloges fournies par l'OS si tant est qu'elles entrent en jeu. Tu es d'accord là dessus ?

Cette influence est bien réelle, cf. l'exemple de perturbation cité par Pio et qui est très facile à mesurer. Le fait que tu "ne l'ai jamais entendu en numérique" ne signifie pas qu'il ne soit pas là !

[Gandalflux]

Pour répondre au question posé :

L'horloge de la machine est au niveau du CPU l'OS ce base dessus donc les logiciels suivant leur implémentation avec l'OS d'ou le faite que en OverClocking ou Underclocking on c'est rendue compte qu'un test (benchmark) d'une heure ne durée pas vraiment une heure

Pour le traitement son ( après avoir passé les couche OS ) normalement on exploite l'horloge de la carte son. donc les différences ce sentirons suivant quel programme est ce que ut utilise.

Pour revenir au dernier posts parrue depuis la réponse de Java Alive à mes posts, je dirais qu'il y a 2 coté la partie applicative et la partie Hard.

En effet vosu parler tous de Jitter mais il n'y a pas que ça .

LEs différence sont en effet beaucoup plus "quantifiable" sur la partie logiciel que la partie HARD.

Une application comme VLC, ou MPC, ou Foobar "traversera de manière différentes l'application et ses couche ISO dans ce cas le traitement fera un plus grand voyage pour arriver jusqu'a la carte son et ce voyage peux détérioré le signal et là à l'oreille on l'entendra facilement.

D'ou le faite que "vous" les Pro Hifi passé en ASIO afin d'avoir le moins de latence possible mais comme tous drivers il y a différent chemin et différent traitement suivant le drivers utilisé et donc le hard que nous utilisons.

Outre cela les WASAPI-iste by passe la couche audio de windows mais idem je me demande si il n'y a pas des différence sur comment bypasser et par ou faire voyager le signal

Comme dis sur un autre topic travaillé sur le Hard me semble de la masturbation cérébral on va gagné peut être des micro % d'évolution audiophile Filtrer le signal interne avoir une alimentation de meilleurs qualité sur un PC passé à un SSD au lieu d'un HDD classique ect.. pour entendre vraiment les différence j'pense qu'il faut que tout le reste soit vraiment au TOP enceintes, amplification.

Sachant que sur le PC toutes alimentation est retravaillé par la Carte mère qu’apporte une nouvelle alimentation au niveau informatique pure elle va apporter un courant plus propres au sens ou il y auras moins de pic ce sera plus stable ect.. mais ça en cas d'utilisation forte de la machine.

si la machine ne consomme pas trop ne fait pas des pic de monté en charge il n'y a pas de raison que l'alim subisse de grosse charge aussi .

donc pour éviter de partir dans tous les sens et pour répondre ( de mon avis ) au question du 1er post :

Les sources possibles de différences :
- les parasites (bruit electromagnétique)
- le Jitter : http://en.wikipedia.org/wiki/Jitter

Les parasites peuvent être là oui on il une incidence si importante que ça je ne pense pas de nos jour sle matos est bien et mis eà parts avoir une chaine très TTTHDG je en pense pas que la différence audiophile soit là.

Le Jitter dépendras du coté hard et de la Carte son à mon avis et non de l'alimentation, ou de l'emplacement des fichier à lire ).

Le soft de lecture :
1- Accéde aux fichier sur disque ou réseau.
2- converti en mémoire vive le fichiers compressé en PCM
3- appelle les fonctions du driver pour lui passer les bits
4- comment est géré le flux d'un point de vue temporel ? C'est le driver qui demande au soft de passer les bits ? C'est le soft qui "pousse" ?

1 Entre différent type de réseau ( Wifi - CPL - Ethernet etc.. ) le TCP-IP n'engendre pas de différence sauf que si le signal est perturbé il faudra plus de travail pour recrée le paquet réseau et donc plus de risque d'avoir des micro erreur . pour les SSD et HDD aucune différence sauf le faite que l'un est mécanique et donc peux perturbé plus son environnement est ce quantifiable audiophilement parlant je ne pense pas non plus ça reste pour moi ultra minime ( masturbation cérébrale expression que j'aime bien Hii Hii )

2 idem je ne voie pas l'apport que ça peux avoir

3 là oui certainement tous les drivers ne sont pas logé à la même enseigne

4 mais je comprend pas cette histoire de soft qui demande de passer par les bits ....

L'OS :
- en charge de la gestion des processus (priorité, etc)
- en charge de la gestion de la mémoire (alloue la mémoire vive, contrôle les accès à cette mémoire)
- interruptions matérielle est logicielles : joue un rôle ?

Oui et non : si tu fait travailler lourdement ton PC oui si tu est en utilisation écoute musical non

Le driver :
1- comment envoit-t-il les bits à la carte où au contrôleur USB ?
2- joue-t-il un rôle dans le domaine temporel ?
3- est-ce qu'il inclu du code pour le processeur de la carte son ou du contrôleur ?
4- le driver inclu lui-même un buffer (du moins l'Asio).

1 Je ne sais pas comment mais oui ça peux lourdement jouer
2 Ho que oui c'est minime mais ça peux tout foutre en l'air
3 oui sinon on aurais pas d'ASIO ou de WASAPI pour allez au plus direct
4- si ce n'est pas le drivers ce sera le Hard qui le fera voir les deux.

La carte son :
1- intègre une horloge pour la génération du signal spdif ?
2- accède à la mémoire vive en DMA (direct mémory access) sans passer par le CPU ?
3- intègre un buffer matériel dans lequel "tape" le générateur du signal spdif ?

1 normalement oui toutes
2 là ça dépend des drivers etre de la carte son sans drivers la carte son en sait pas comment ni ou allez chercher les informations.
3 je pense que c'est en effet le cas sur toutes les carte son du marché actuellement et depuis longtemps

La tramsission spdif :
1- contient le signal d'horloge. Généré par quelle horloge ?
2- le DAC a systématiquement un PLL (ou équivalent) en entrée ?
3- ce qui ferai que la qualité du signal spdif de la carte son n'a aucun impact ?

1 généré par la Carte son
2 PLL .. alors pardon mais bon nombre de vos abréviation de pro Hifiste me sont inconnue
3- sauf que le contrôleur SPDIF peux beaucoup jouer si optique l'opto-électronique peux jouer et coax idem un mauvais chipset et c'est des erreur potentiel en plus non ?

Le contrôleur USB / la communication asynchrone :
1- le DAC est maître de la connexion et c'est lui qui pilote l'échange.
2- l'échange est par paquets, c'est à dire qu'il ne peut être source de Jitter, il va bien plus vite que le flux en entrée du chip de conversion, il a des processus de contrôle forts et redemande les paquets en cas d'erreur. Pas de perte de bits possible.
3- le DAC a un buffer mémoire
4- le DAC a une horloge qui, avec le buit ambiant, peut être seule responsable du jitter.

1 en toute logique oui PC ou pas
2 pas de perte possible normalement mais perturbation du signal qui ferais que le contrôleur dois re-calculer les paquets pour comprendre ce qu'il y de dans n'est pas impossible.
3 j'espères bien
4 oui je pense

L'alim' (et autres composants physiques) :
1- peut jouer un rôle pour fournir un courant stable aux composants critiques (comme l'horloge de la carte sont)
2- peut jouer un rôle dans le buit electromagnétique

1 oui et non il fournira un courant propres à l'alim qui elle retraiteras ce courant pour tous les composant du PC
2 comme tous ce qui touche à l'électricité oui

Après est ce vraiment quantifiable ....

Le bruit (et les façons de le réduire) :
1- une alim de qualité
2- un boitier métalique ? (pour éviter le rayonnement du boitier)
3- l'under-clocking CPU : permet de réduire énormément la consommation CPU en baissant sa fréquence de fonctionnement (de 10 à 30% environ) mais surtout son voltage. Impact non linéaire, à priori au caré, sur la consommation CPU.
4- l'under-clocking des BUS : on peut aussi baisser la fréquence des bus. Des avis sur ce point ?

1 Enfin trouver une alim si nul que tu entends la différence de nos jour j'ai des doutes. surtout que comme dis c'est la carte mère qui principalement va fournir l’énergie à la carte son
2 oui comme tous ce qui aide au blindage mais ne serais pas mieux avec de l’aluminium et une protection interne ? quizz des vibrations si ventillo ect...
3 oui et pb sur les couches ISO haute ( couche 5-6-7 voir 6-7 ) pour la partie applicatif après pour al partie HARD si tu modifie l'horloge du CPU et des BUSS donc tu modifie tout a voir comment c'est géré ça risque d'être folclo ( on parle des couches 4-5 soit impacté ) je ne pense pas que ça impact les couche 2-3 qui sont géré à mon avis directement par le chips réseaux et donc qu'importe l'horloge de la machine
4 que 3

[WhyHey]

y a pas de pll sur les CS ??

La PLL sert à remettre en forme un signal numérique un peu crado donc quelque chose qu'on retrouve en entrée (d'un DAC ou d'une carte son pour la partie ADC qui est hors suejt ici). D'ailleurs, la présence de PLL et leur caractéristiques ne sont pas toujours clairement indiquées dans les specs des DACs. Une idée pour un autre topic dédié à ce suejt ?

oui et non.
là je parle d'un PLL d'horloge, c'est donc un mécanisme qui permet à un composant d'etre asservie à une horloge externe en se calant dessus.
Mais dans un PC, la partie de la CS possède sa propre horloge et il n''y a donc pas de PLL, c'était avant la mise en place de UAA qu'il y avait des PLL sur les CS.
Par contre certaines CS externes ont des PLL.

[WhyHey]

@Java: je n'arrive pas à bien cerner l'objectif de ton topic, interessant par ailleurs ?
est-ce juste de décrire un mode de fonctionnement d'un dac en sortie de pc ?
ou est-ce de trouver les points qui peuvent expliquer des différences percues/mesurées entre 2 dac en sortie de pc ?

Je sais que le première post n'est pas super clair, je suis en train de revoir avec le staff pour améliorer ça.
Le but des de comprendre comment le signal numérique est généré du logiciel jusqu'à l'entrée du DAC en comprenant ce qui se passe dans les différents couches (sauf si on arrive à démontrer qu'une couche n'a pas d'impact à cause d'un élément en aval comme le cas du buffer expliqué ci-dessus). On peut aussi comparer à la mesure si qqun a le matos pour le faire. Je ne cherche pas à expliquer quoi que ce soit sur les différences perçues car le sujet est assez complexe comme ça pour ne pas en plus rajouter ce qui presque à coup sûr part en débats stériles. Mais pour ceux que ça tente, ouvrez un topic dédié aux différences perçues.

quel DAC Java ?

[JAVA Alive]

quel DAC Java ?

Peu importe puisqu'on en s'intéresse qu'à ce qui se passe avant, sauf en ce qui concerne la présence de PLL dans le DAC où il serai effectivement sympa d'avoir des infos car c'est rarement fourni par la doc constructeur.

L'horloge de la machine est au niveau du CPU l'OS ce base dessus donc les logiciels suivant leur implémentation avec l'OS d'ou le faite que en OverClocking ou Underclocking on c'est rendue compte qu'un test (benchmark) d'une heure ne durée pas vraiment une heure

Ca ma parrait très étrange. Tous les overclocking ou presque se font su rle coef multiplicateur, on ne fait donc que faire fonctionner un CPU donné comme un modèle au dessus ou au dessous. Il ne doit y avoir aucun impact, je ferai petit dev pour le vérifier.

Pour le traitement son ( après avoir passé les couche OS ) normalement on exploite l'horloge de la carte son. donc les différences ce sentirons suivant quel programme est ce que ut utilise.

Ben si on est bit perfect (donc les logiciels ne jouent pas sur les bits) et qu'en plus l'horloge est hardware (donc le logiciel ne joue pas sur le jitter), en quoi le logicel pourra avoir encore une influence ? A part le bruit éventuel, je ne vois pas ...

LEs différence sont en effet beaucoup plus "quantifiable" sur la partie logiciel que la partie HARD.

Une application comme VLC, ou MPC, ou Foobar "traversera de manière différentes l'application et ses couche ISO dans ce cas le traitement fera un plus grand voyage pour arriver jusqu'a la carte son et ce voyage peux détérioré le signal et là à l'oreille on l'entendra facilement.

D'ou le faite que "vous" les Pro Hifi passé en ASIO afin d'avoir le moins de latence possible mais comme tous drivers il y a différent chemin et différent traitement suivant le drivers utilisé et donc le hard que nous utilisons.

Si on compare des logiciels qui ne sont pas bit perfect, effectivement il y aura des écarts, c'est pourquoi j'ai proposé de ne parler que du bit perfect (qui est un résulta très facile à atteinte, même avec des softs gratuits).
Pour la hifi, le but de l'ASIO où équivalents, n'est pas d'avoir une faible latence mais d'avoir du bit perfect. La latence est liée essentiellement à la taille des buffers, et en hifi il vaut mieux un gros buffer (donc une grande latence). Une faible latence ne sert à ma connaissance qu'à synchroniser différents instruments de musique entre eux (genre du WAV et du midi par ex) et ne sert donc qu'aux musiciens et studios. Tu es d'accord sur ce point ?

En effet vosu parler tous de Jitter mais il n'y a pas que ça .

Dasn le cas d'une lecture bit perfect, je ne vois plus que le Jitter et le bruit sur le signal numérique. Vois-tu d'autres facteurs ?

Comme dis sur un autre topic travaillé sur le Hard me semble de la masturbation cérébral on va gagné peut être des micro % d'évolution audiophile Filtrer le signal interne avoir une alimentation de meilleurs qualité sur un PC passé à un SSD au lieu d'un HDD classique ect.. pour entendre vraiment les différence j'pense qu'il faut que tout le reste soit vraiment au TOP enceintes, amplification.

Je suis bien d'accord, et idem pour moi concernant le logiciel + OS + driver (tant qu'il est bit perfect) mais ce n'est pas l'avis de tout le monde, d'où le fait que j'essaie de recueillir le plus d'info techniques sur le sujet.

Sachant que sur le PC toutes alimentation est retravaillé par la Carte mère qu’apporte une nouvelle alimentation au niveau informatique pure elle va apporter un courant plus propres au sens ou il y auras moins de pic ce sera plus stable ect.. mais ça en cas d'utilisation forte de la machine.

Pour être un fan d'overclocking, peux t'assurer que les alim' ne se vallent pas. Autant, il y a une offre assez large de bonnes alims, autant il reste des modèles à proscrire, notamment la plupart des alims intégrées aux boitier ou PC tout faits de marque (compaq, HP, etc). Il suffit de regarder les voltages faire le yoyo avec OCCT par exemple, même avec un CPU à fréquence normale.
Après oui, c'est moins flagrant avec uen utilisation CPU faible.

Les parasites peuvent être là oui on il une incidence si importante que ça je ne pense pas de nos jour sle matos est bien et mis eà parts avoir une chaine très TTTHDG je en pense pas que la différence audiophile soit là

Oui, je suis d'accord. J'ai fait des tests en lançant des calculs lourds pendant l'écoute de la musique, je n'ai pas perçu de différence (mais c'est subjectif, je suis hors sujet ). Si qqun peut faire des mesures ...

Le Jitter dépendras du coté hard et de la Carte son à mon avis et non de l'alimentation, ou de l'emplacement des fichier à lire

Yes ! Prouvons-le.

1 Entre différent type de réseau ( Wifi - CPL - Ethernet etc.. ) le TCP-IP n'engendre pas de différence sauf que si le signal est perturbé il faudra plus de travail pour recrée le paquet réseau et donc plus de risque d'avoir des micro erreur . pour les SSD et HDD aucune différence sauf le faite que l'un est mécanique et donc peux perturbé plus son environnement est ce quantifiable audiophilement parlant je ne pense pas non plus ça reste pour moi ultra minime ( masturbation cérébrale expression que j'aime bien Hii Hii )

2 idem je ne voie pas l'apport que ça peux avoir

Je suis d'accord.

3 là oui certainement tous les drivers ne sont pas logé à la même enseigne

Faut creuser. QQun a des infos ?

4 mais je comprend pas cette histoire de soft qui demande de passer par les bits ....

J'essaie de comprendre comment les bits arrivent au contrôleur USB ou à la carte son à partir du moment ils sont en RAM. Où sont les buffers, qui appelle qui pour pomper ou pousser les bits vers l'étape suivante, etc.

1 en toute logique oui PC ou pas
2 pas de perte possible normalement mais perturbation du signal qui ferais que le contrôleur dois re-calculer les paquets pour comprendre ce qu'il y de dans n'est pas impossible.
3 j'espères bien
4 oui je pense

1. Pas dans le cas d'un signal coax ou USB asynch. Le signal produit par le PC est envoyé au chip quasi en direct (modulo une PLL). by the way une PLL aservit une horloge par une autre horloge avec un amortissement. Ca sert notamment à remettre en forme un siganl numérique crados.
2. En asynchrone, il n'y a pas de recalcul en cas d'erreur, le DAC redemande au PC de renvoyer ce qui n'est pas bon comme le ferai un disque dur externe par exemple.

3 oui et pb sur les couches ISO haute ( couche 5-6-7 voir 6-7 ) pour la partie applicatif après pour al partie HARD si tu modifie l'horloge du CPU et des BUSS donc tu modifie tout a voir comment c'est géré ça risque d'être folclo ( on parle des couches 4-5 soit impacté ) je ne pense pas que ça impact les couche 2-3 qui sont géré à mon avis directement par le chips réseaux et donc qu'importe l'horloge de la machine

Comprends pas, je ferai un test avec un tit bout de programme vite fait mais je doute qu'il puisse y avoir un impact.

Ouf !

[JAVA Alive]

Bonjour JAVA Alive,

J'ignore volontairement le mode synchrone USB car je lui trouve des défauts importants (le synchrone justement) et l'asynchrone se démocratise. Et puis le sujet me semble assez large comme ça .

Allons bon mais quels sont donc ces défauts justement ? le principe ne te plait pas certes, mais quelle(s) différence(s) au niveau du spdif sortant ?

Mais l'amont (production des bits en RAM) en peut pas jouer sur le résulta final (à bit égaux) sauf peut être à utiliser plus où moins le CPU et à influence les horloges fournies par l'OS si tant est qu'elles entrent en jeu. Tu es d'accord là dessus ?

Cette influence est bien réelle, cf. l'exemple de perturbation cité par Pio et qui est très facile à mesurer. Le fait que tu "ne l'ai jamais entendu en numérique" ne signifie pas qu'il ne soit pas là !

Le défaut de l'USB synchrone sera celui du COAX à ceci près : l'horloge du contrôleur USB sera en général moins adaptée à la production de flux 44, 48, 96, etc.

Peux-tu détailler l'influence (sauf bruit lié à l'activité CPU) des calculs en RAM quand, au final, le signal envoyé au DAC est mis en forme à partir d'un buffer (sur la carte son ou sur le DAC) et une hrologe dédiée (idem, sur la carte son ou sur le DAC) ?