Bonjour,
JAVA Alive a écrit: 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
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.
JAVA Alive a écrit: - 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" ?
C'est la carte son qui est maîtresse. Le logiciel de lecture se plie à son horloge et envoie les données quand on les lui demande.
JAVA Alive a écrit: 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 ?
Totalement inextricable. C'est une question de pluie.
JAVA Alive a écrit: Le driver :
- comment envoit-t-il les bits à la carte où au contrôleur USB ?
Je pense qu'il les envoie à l'OS, qui se débrouille.
L'OS comporte des drivers pour chaque port de la carte mère. A mon avis, ces drivers envoient les données à la carte mère, et ce sont les puces de la carte mère qui se chargent de convertir les données au bon format pour alimenter physiquement les fiches.
JAVA Alive a écrit: - joue-t-il un rôle dans le domaine temporel ?
Oui et non. Il n'est qu'un intermédiaire entre la carte son et le logiciel. Note qu'il existe des logiciels qui ont un effet néfaste sur le temporel. Aussi absurde que cela puisse paraître, VLC media player provoque du pleurage !
Il y a une explication : VLC a été conçu à l'origine pour lire des flux vidéo en streaming. Or, le streaming ne permet pas au récepteur d'obtenir l'horloge de l'émetteur. Les normes du streaming obligent donc les logiciels à opérer ce qu'on appelle de l'ASRC : Asynchronous Sample Rate Conversion. C'est un traitement qui consiste à modifier numériquement la vitesse du son afin de compenser dynamiquement la dérive entre l'horloge de l'émetteur et celle du récepteur. Cela opère par corrections successives lorsque le buffer est trop plein ou trop vide. La lecture est accélérée ou ralentie à la volée.
Or, cette gestion de la vitesse est impossible à désactiver dans VLC. Cela a été remonté aux équipes de développement par des utilisateurs qui se plaignent qu'il y a du pleurage sur les stations de radio internet, par exemple, alors que le lecteur de Youtube, lui, n'a pas de pleurage. En pratique, la synchro est inutile quand c'est de la vidéo à la demande, avec un flux descendant suffisamment rapide.
Malheureusement, VLC est un projet libre, et il ne s'est encore trouvé aucun volontaire pour ce travail.
JAVA Alive a écrit: - est-ce qu'il inclu du code pour le processeur de la carte son ou du contrôleur ?
Peut-être. Une table de mixage dédiée peut traiter le signal avant de l'envoyer à la carte. Des contrôles peuvent piloter à distance la carte : pour changer la fréquence d'horloge, par exemple.
JAVA Alive a écrit: - le driver inclu lui-même un buffer (du moins l'Asio).
Un buffer de plus ou de moins... quand on pense qu'il y en a déjà deux dans le CPU lui-même, et au moins un dans le disque dur...
JAVA Alive a écrit: La carte son :
- intégre une horloge pour la géénration du signal spdif ?
Cela dépend. Les bons modèles ont une horloge. Les plus médiocres utilisent l'horloge de la carte mère fournie à travers le port PCI, par exemple.
JAVA Alive a écrit: - accède à la mémoire vive en DMA (direct mémory access) sans passer par le CPU ?
Aucune idée.
JAVA Alive a écrit: - intègre un buffer matériel dans lequel "tape" le générateur du signal spdif ?
Certainement. Il faut bien convertir les données depuis le format PCI, ou USB vers le format S/Pdif, donc lire les premières avant de générer les secondes.
JAVA Alive a écrit: La tramsission spdif :
- le DAC a systématiquement un PLL (ou équivalent) en entrée ?
Oui.
JAVA Alive a écrit: - ce qui ferai que la qualité du signal spdif de la carte son n'a aucun impact ?
Oui. Comme expliqué par Jipihorn dans sa vidéo, l'horloge qui met en forme le signal, c'est celle qui est fournie par la PLL du DAC. Il dit que le jitter en amont est totalement éliminé. En réalité, il est "presque" totalement éliminé. Je ne sais pas s'il en existe une trace mesurable dans le signal de sortie.
Bruno Putzeys, de Philips, prétend que oui, Mais Dunn, Dennis et Carson, de Prism Audio, prétendent que ce qu'il mesure, c'est la modulation d'amplitude de l'alim, et non le jitter. Dans les deux cas, cela fait des petits pics au pied d'un grand dans l'analyse spectrale.
JAVA Alive a écrit: Le contrôleur USB / la communication asynchrone :
Pour ça et pour le reste, je suis ignare.