Lecture dématérialisée, le pilote de son est-il si transparent qu'il le prétend ?
En matière de lecture dématérialisée, il existe un grand nombre de lecteurs proposant la lecture dite sans perte des morceaux musicaux. Chaque lecteur indique (ou non) sa capacité à reproduire le morceau avec exactitude, extrayant les informations du flux musical en temps réel et le postant au pilote de son associé de l'ordinateur.
M'étant livré à une petite expérience simple ces derniers temps pour mettre en évidence que chaque lecteur possède sa propre signature sonore, persuadé de ce fait, je décide donc de vous livrer quelques réflexion sur l'interface livrée par Microsoft sur ses dernières générations de système d'exploitation. Il s'agit de l'interface WaveRT.
Microsoft dit:
L'interface WaveRT a donc été conçue pour combler les problèmes de latence induits par le mixeur de son et le mécanisme DirecSound des versions précédentes de système d'exploitation. WaveRT permet en principe de s'affranchir des pilotes tiers ASIO et utiliser directement la pile sonore WASAPI.
L'interface WaveRT va beaucoup plus loin en matière de tunnel audio en proposant au périphérique de lire ou capturer des données audio sans l'intervention du pilote logiciel, la consommation de CPU système est ainsi extrêmement réduite et la latence réduite au minimum. Le mécanisme d'échange s'effectue en règle générale par écriture rotative sur un buffer en mémoire partagé entre périphérique et système. On reconnait ici le mécanisme d'ailleurs choisi par Naim dans son système HDX pour réduire au minimum les problèmes liés à la latence.
L'ancien système WaveCyclic reposait sur une procédure programmée et donc faillible déclenchée à intervalle régulier pour lire ou écrire dans la zone partagée. Le système WavePCI également obsolète quant à lui nécessitait une surveillance continue du port. Ces mécanismes introduisent une latence produisant donc une gigue incontrôlable.
Par le passé, sur les systèmes Windows XP par exemple, l'utilisation de WaveCyclic/WavePCI s'est vue implémentée sous l'acronyme KS (Kernel Streaming). Ce mode même s'il donne accès à un échange, n'est absolument pas optimisé puisqu'il :
Il est de la responsabilité du pilote de déterminer le nombre de cycles à attendre avant d'écrire de nouvelles données sans étouffer le buffer FIFO du périphérique de reproduction. La latence est d'ailleurs un paramètre fourni par le pilote et des interruptions matérielles sont générées si le buffer FIFO vient à déborder pour permettre au pilote d'ajuster sa vitesse de dépose.
Pour dialoguer avec le pilote audio Windows Vista par exemple met à disposition 2 types d'objets. Les objets LFX (traitements locaux tels que l'égalisation) et les GFX (traitements matériels). L'utilisation de LFX introduit donc un traitement qui fait que le flux n'est plus "bit true", mais reste en théorie parfaitement maîtrisé en matière de temps de traitement.
Lorsque l'on prend ces informations en compte, au final il est de la responsabilité de l'application d'écrire le flux de données à un rythme qui convient pour que le pilote puisse à son tour les délivrer. On peut également supposer que si l'application maîtrise mal les temporisations elle peut générer potentiellement une perte de données ou un décalage temporel à la reproduction. Comme tout ce traitement est programmé, on peut naturellement douter de l'infaillibilité du mécanisme hormis dans le cas où le périphérique matériel est confortablement doté de pile FIFO et de registre pour son contrôle.
Je soupçonne ces éléments d'être à l'origine des différences audibles perçues d'une application à l'autre sur Windows Vista ou Seven.
M'étant livré à une petite expérience simple ces derniers temps pour mettre en évidence que chaque lecteur possède sa propre signature sonore, persuadé de ce fait, je décide donc de vous livrer quelques réflexion sur l'interface livrée par Microsoft sur ses dernières générations de système d'exploitation. Il s'agit de l'interface WaveRT.
Microsoft dit:
L'interface WaveRT a donc été conçue pour combler les problèmes de latence induits par le mixeur de son et le mécanisme DirecSound des versions précédentes de système d'exploitation. WaveRT permet en principe de s'affranchir des pilotes tiers ASIO et utiliser directement la pile sonore WASAPI.
L'interface WaveRT va beaucoup plus loin en matière de tunnel audio en proposant au périphérique de lire ou capturer des données audio sans l'intervention du pilote logiciel, la consommation de CPU système est ainsi extrêmement réduite et la latence réduite au minimum. Le mécanisme d'échange s'effectue en règle générale par écriture rotative sur un buffer en mémoire partagé entre périphérique et système. On reconnait ici le mécanisme d'ailleurs choisi par Naim dans son système HDX pour réduire au minimum les problèmes liés à la latence.
L'ancien système WaveCyclic reposait sur une procédure programmée et donc faillible déclenchée à intervalle régulier pour lire ou écrire dans la zone partagée. Le système WavePCI également obsolète quant à lui nécessitait une surveillance continue du port. Ces mécanismes introduisent une latence produisant donc une gigue incontrôlable.
Par le passé, sur les systèmes Windows XP par exemple, l'utilisation de WaveCyclic/WavePCI s'est vue implémentée sous l'acronyme KS (Kernel Streaming). Ce mode même s'il donne accès à un échange, n'est absolument pas optimisé puisqu'il :
- génère à chaque transition entre le passage du mode usager au mode système des requêtes d'entrées/sorties
- bloque le système jusqu'à complétion de la requête avec tous les dangers inhérents
- consomme plusieurs cycles CPU pour les copies de données de et vers les buffers d'échanges
Pour dialoguer avec le pilote audio Windows Vista par exemple met à disposition 2 types d'objets. Les objets LFX (traitements locaux tels que l'égalisation) et les GFX (traitements matériels). L'utilisation de LFX introduit donc un traitement qui fait que le flux n'est plus "bit true", mais reste en théorie parfaitement maîtrisé en matière de temps de traitement.
Lorsque l'on prend ces informations en compte, au final il est de la responsabilité de l'application d'écrire le flux de données à un rythme qui convient pour que le pilote puisse à son tour les délivrer. On peut également supposer que si l'application maîtrise mal les temporisations elle peut générer potentiellement une perte de données ou un décalage temporel à la reproduction. Comme tout ce traitement est programmé, on peut naturellement douter de l'infaillibilité du mécanisme hormis dans le cas où le périphérique matériel est confortablement doté de pile FIFO et de registre pour son contrôle.
Je soupçonne ces éléments d'être à l'origine des différences audibles perçues d'une application à l'autre sur Windows Vista ou Seven.
Commentaires
Enregistrer un commentaire