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

[JAVA Alive]

Bonjour,


Il est difficile d'expliquer les différences perçues entre les différentes solutions bit perfect.
Alors légende ou phénomène explicable ?

L'objectif du topic est de tenter de détailler le fonctionnement technique d'un PC (hardware et software) lorsqu'il alimente un DAC en numérique.

Afin de simplifier ce sujet complexe, je propose ne de s'intéresser qu'aux liaisons USB asynchrones et spdif et aux drivers Asio et KS.
J'écarte aussi tous les sujets mécaniques du type vibrations, etc.

Je vais décomposer le sujet comme suit :
Sources de différences
Software : le soft de lecture, l'OS, le driver
Hardware : l'alim', la ram, le CPU, le chip USB, la carte son

Subjectivisme vs objectivisme : SVP, ce topic se veut volontairement réduit aux critères objectifs. Ceci inclut le raisonnement théorique et les mesures.
Merci donc d'éviter ici les débat sur les "j'entends ça" ou "j'entends pas ça".

Afin de rentre le lisible résultat de nos discussions, je vais compiler les informations ou questions sans réponses au fil de l'eau dans ce premier post.
Si des points ne sont pas clairs ou font débat, je les remonterai aussi dans ce post.
Pas de conclusions pour l'instant, je pense qu'il vaut mieux décrire précisément le foncitonnement d'un dispositif avant de tenter de conclure.

Passons au concret :

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

Le soft de lecture :
- Accéde aux fichier sur disque ou réseau.
- converti en mémoire vive le fichiers compressé en PCM
- appelle les fonctions du driver pour lui passer les bits
- 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" ?

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 ?

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

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

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

Le contrôleur USB / la communication asynchrone :
- le DAC est maître de la connexion et c'est lui qui pilote l'échange.
- 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.
- le DAC a un buffer mémoire
- le DAC a une horloge qui, avec le buit ambiant, peut être seule responsable du jitter.

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

Le bruit (et les façons de le réduire) :
- une alim de qualité
- un boitier métalique ? (pour éviter le rayonnement du boitier)
- 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.
- l'under-clocking des BUS : on peut aussi baisser la fréquence des bus. Des avis sur ce point ?

[rha61]

AMHA , tu prends une carte son pro ou semi-pro , type EMU , Lynx , RME , les problematiques dont tu parles ont été prises en compte ( du moins celles susceptibles de dégrader le signal ) et tu peux te concentrer sur des choses plus audibles ( filtrage des enceintes , équa pour optimiser le couple enceintes/pièce etc ...

edit : je viens de voir que tu as déjà un DAC , je pense que les sorties SPDIF des marques que je cite sont irréprochables

[dinococus]

AMHA , tu prends une carte son pro ou semi-pro , type EMU , Lynx , RME , les problematiques dont tu parles ont été prises en compte ( du moins celles susceptibles de dégrader le signal ) et tu peux te concentrer sur des choses plus audibles ( filtrage des enceintes , équa pour optimiser le couple enceintes/pièce etc ...

edit : je viens de voir que tu as déjà un DAC , je pense que les sorties SPDIF des marques que je cite sont irréprochables

+1

[JAVA Alive]

Hello,

Mon objectif n'est pas d'améliorer mon système mais de tenter de décrire les principaux processus qui entrent en jeu dans la production d'un flux numérique via un PC afin d'apporter un peu de clarté aux sujets du type "WAV sonne miux que FLAC", "JPlay améliorer le son" ou "Daphile sonne mieux que JRiver" qui me laissent un peu pantois ...

Concernant les cartes son dont vous parlez, avez-vous des précisions techniques sur le moyen d'éviter des problèmes en amont (genre clock + buffer intégrés) ?

[dinococus]

Jitter: vieille lune audiophile et affaire réglée depuis au moins trois décennies.

general-haute-fidelite/a-voir-le-mythe-du-jitter-t30035813.html?hilit=jitter

[JAVA Alive]

Hello, je connais cette excellente video et je suis tout à fait en phase avec ce qui s'y dit.
Mais mon propos ici n'est pas de conclure, du moins pas pour l'instant.
Je cherche avant tout à décrire précisément le fonctionnement complet de la génération du signal pour savoir si tel ou tel élément peut avoir théoriquement un impact sur le signal en entrée du chip convertisseur.

Edit : j'ai changé le titre et surligné l’objectif afin d'être plus clair.

[Gort'h]

Démarche intéressante que je souhaite suivre.
@dinococus:Oui et ? La demarche ne se resume pas au jitter.

[SELTG]

Bonsoir,

il n'y a pas vraiment besoin de se monter le bourrichon!

experience perso: EMU 0404 USB sur un PC pas cher sous XP (fanless, disque SSD) : installation sans aucun probleme avec les softs standard fournis + Foobar decodant des fichiers Flac stockés sur un serveur Windows dans la cave

resultat: son nickel vers un ampli classe A Sugden + enceintes Dynaudio 52SE ou un Stax SR202

meme chose avec un Teac UD501 choisi pour decoder du DSD

Oublié toutes les angoisses métaphysiques sur jitter et autres subtilité qui auraient pu pourrir la vie, le cas échéant, si on les avait rencontré, ce qui n'a pas été le cas .

Le son est nickel, et on peut se consacrer à ecouter la musique

Cdt

[dinococus]

Démarche intéressante que je souhaite suivre.
@dinococus:Oui et ? La demarche ne se resume pas au jitter.

Démarche reposant sur des présupposés non étayés par des mesures corréllées à une audibilité possible.

Software : le soft de lecture, l'OS, le driver
Hardware : l'alim', la ram, le CPU, le chip USB, la carte son

Donc mesures mais de quoi et audibilité mais de quoi ?

[JAVA Alive]

Hello,

j'ai bien précisé que l'auditibilité, bien que ce soit au fond la seule chose qui compte, n'est pas le sujet ici.

Ici, je souhaite décrire précisément la façon dont le signal numérique est généré par un PC.

Notamment, quelle est la source d'horloge puisque c'est un élément essentiel dans la génération du signal.

[dinococus]

Salut,


En spdif, le signal contient le signal de synchro.

En usb, je ne vois pas en quoi une horloge intervient.

D'autant qu'avec un signal numérique, la conversion se fera par la CS, le pc n'a rien à faire à ce niveau et seule l'horloge de la CS sera active.

[JAVA Alive]

Oui, j'ai déjà écrit tout ça dans le premier post.
Maintenant, par exemple, dans une sortie qu'est-ce qui génère le signal d'horloge ? Est-ce que le CPU joue un rôle là dedans ?

[dinococus]

Oui, j'ai déjà écrit tout ça dans le premier post.
Maintenant, par exemple, dans une sortie qu'est-ce qui génère le signal d'horloge ? Est-ce que le CPU joue un rôle là dedans ?

En spdif, le signal contient le signal de synchro.

In the S/PDIF serial audio data interface used to get data from CD, LD, DAT, DCC, MD, and PC soundcards to external DACs or digital recorders the clock is transmitted along with the audio data as part of the bi-phase mark encoding used. The absolute stability of this clock from the source varies depending on how good the designers were, the parts are, and the adjustments is

http://www.audiocraftersguild.com/AandE ... itter2.htm

En usb, je ne vois pas en quoi une horloge intervient.

[dinococus]

qui est capable de caractériser la dégradation sonore introduite par l'hrologe du pc en spdif ?
qui est capable de caractériser la dégradation sonore introduite par l'horloge de la cs lors de la conversion DA ?

[JAVA Alive]

En spdif, le signal contient le signal de synchro.

Oneagain : oui. je le rajoute en toutes lettres. La question est de savoir qu'est-ce qui le génère. Un horloge sur la carte son ? Le CPU rentre en jeu ? Le chip de la carte son ?

En usb, je ne vois pas en quoi une horloge intervient.

Oui, déjà expliqué.

Le contrôleur USB / la communication asynchrone :
- le DAC est maître de la connexion et c'est lui qui pilote l'échange.
- 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.
- le DAC a un buffer mémoire
- le DAC a une horloge qui, avec le buit ambiant, peut être seule responsable du jitter.