1.1 Le système d'exploitation

1.1 Le système d’exploitation

Les systèmes d’exploitation ont fait de considérables progrès ces dernières années tout comme les performances du matériel. C’est manquer d’objectivité que de prétendre que les performances d’une machine d’entrée de gamme des années 2010 ne sont pas propres à satisfaire les critères des lecteurs dématérialisés. Les processeurs ont fait des bonds en avant considérables et stagnent en matière d’innovation ces dernières années en proposant des traitements multi cœurs (Core 2, i5, i7) satisfaisant parfaitement à nos besoins, même en entrée de gamme.

Mon conseil en la matière sera d’utiliser Windows 7 en version 64 bits qui dispose d’un noyau fort bien conçu et proposant une architecture interne permettant à des pilotes audio de fonctionner dans les meilleures conditions possibles à ce jour. Il est également à noter que la distribution, la simplicité et la popularité des systèmes d’exploitation Microsoft ™ ont guidé fortement le sens de mon travail dans la mesure où je souhaitais m’adresser au plus grand nombre et proposer une solution adaptée ou convenant aux personnes souhaitant utiliser leur PC à d’autres fins (multimédia, bureautique, etc.).

[Note Avril 2012 : Version 2.5, la publication de Windows 8 n'est pas encore officialisée, elle fera l'objet de sections complémentaires séparées d'ici quelques mois, le temps d'en avoir un retour concret]

Nous sommes maintenant en Janvier 2014, il est temps de mettre ces informations à jour. Windows 8 est maintenant relativement stable avec une version 8.1 disponible pour le grand public. Windows 8 reprend les fondamentaux de Windows 7 en la matière et sa version 64 bits pourra être mise en oeuvre

1.1.1 L’audio et le système d’exploitation

Un des éléments cruciaux dans la chaîne de reproduction est la méthode d’accès offerte aux applications pour dialoguer avec les périphériques de son. Ces dernières années, les premiers systèmes Microsoft, comme Windows 95/ME ou XP étaient peu performants en la matière et ont donc laissé la voie libre aux applications sous Linux ou sur plateforme Mac où l’architecture est très bien pensée pour le traitement audio, photo et vidéo.

Sur Windows XP par exemple, le système d’API WaveCyclic reposait sur une procédure programmée faillible, déclenchée entre le périphérique et le système. WavePCI - également obsolète – nécessitait, quant à lui, une surveillance continue du port. Ces mécanismes introduisent une latence importante en produisant au final une gigue incontrôlable.

La tentative de correction de tir avec Microsoft Windows Vista a été un bon début, mais l’ensemble n’a pas convaincu, le système en lui-même présentant de multiples défauts et une lourdeur d’administration. Pour dialoguer avec le pilote audio, Windows Vista met par exemple à 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 perfect », mais reste en théorie parfaitement maîtrisé en matière de temps de traitement.

Windows 7 à cet effet a apporté un grand plus en effectuant la synthèse au niveau des processus système et des éléments ergonomiques apportés à l’utilisateur final.

Dans le cadre d’une utilisation audiophile, deux alternatives sont possibles en matière de route d’accès. Toutes deux permettent d’associer une priorité plus importante au chemin de reproduction audio, d’assurer une latence très faible (inférieure à 20ms) et de différer l’exécution des demandes non prioritaires au système du système.

WASAPI - Windows Audio Session API (Au sujet de WASAPI) :

WASAPI est la pile d’API native Microsoft offrant un chemin direct vers le pilote de périphérique audio. Dans son mode partagé, le flux est émis par l’application de lecture et mixé par le système avant d’être déposé au pilote audio. En mode exclusif, le flux est remis directement au pilote de périphérique.

Il reste cependant soumis aux contraintes des API Microsoft et donc potentiellement « interruptible » par tout autre processus que Microsoft aurait considéré comme prioritaire dans la hiérarchie des processus. De plus l’échange ne se fait pas directement via échange mémoire mais passe par des API pour déposer et lire les données relatives au flux audio.

WASAPI repose principalement sur une API Microsoft appelée WaveRT. 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, la latence est par conséquent réduite au minimum. Le mécanisme d'échange s'effectue en règle générale par écriture rotative sur un tampon en mémoire partagé entre périphérique et système.

Kernel Streaming (Microsoft, 2010) :

Ce mode a tout pour être idéal, puisqu’il coupe toutes les routes pour donner directement accès aux zones de mémoire tampon d’échange entre l’application et le périphérique audio.

Le code du pilote dépose donc directement les informations sans passer par le mixeur ou les API WASAPI. Le temps de latence est donc minimal, la gigue minimisée, le contrôle est total sur l’horloge d’émission.

Le risque est cependant présent d’avoir affaire à un pilote imparfait. Dans ce mode, des gels du système ne sont pas impossibles avec des pilotes immatures.

Note : suivant la conception de la carte mère et de ses composants, il peut arriver, surtout avec les ordinateurs portables, que certains périphériques bloquent le système d’exploitation pendant quelques millisecondes lors du déclenchement des IRQ, ce qui peut entraîner des pauses dans la lecture audiophile. C’est notamment le cas des éléments intégrés sur une carte mère Wi-Fi ou Bluetooth de qualité moyenne. Dans la mesure du possible, si le médium de transport n’est pas utilisé, il convient de le désactiver dans le panneau de configuration de l’ordinateur (Wi-Fi, réseau filaire Ethernet, Bluetooth ou Firewire).