Projet Aquosa

Titre du projet : Gestion de la Qualité de Service pour les applications temps réel Audio/Vidéo sous Linux.
Équipe : Émeraude (LIFL-IRCICA)
Lieu : IRCICA, Parc de la haute borne, Villeneuve d’Ascq
Encadrants : Julien Forget, Giuseppe Lipari
Étudiants : 1 binôme.
Environnement de travail : Linux, C

1 Intitulé

Gestion de la Qualité de Service pour les applications temps réel Audio/Vidéo sous Linux.

2 Le contexte

Les applications temps réel multimédia ont des contraintes temporelles souples. Généralement, elles se composent de plusieurs tâches concurrentes qui doivent être executées avant leurs échéances, sous peine de réduction de la qualité perçue du service par les utilisateurs.

2.1 Example I

L’application “Mplayer” permet de visionner sur un ordinateur des fichiers vidéo. Les “frames” vidéo et les “paquets” audio doivent être décodés puis affichés à l’écran ou envoyés à la carte son à un rythme bien précis. Le non-respect de ces échéances temporelles peut provoquer des défauts tels qu’une image qui saute ou se fige momentanément, un déclic ou un parasite dans le son, etc.

2.2 Example II

Pour produire de la musique de qualité professionnelle avec un ordinateur (MAO, Musique Assistée par Ordinateur), il est nécessaire d’utiliser des outils logiciels spécifiques. Par exemple, l’outil “JACK” (http://jackaudio.org/) permet de manipuler des flux (streams) audio en temps réel de manière très simple. Il est ainsi possible de faire de l’enregistrement audio multipiste et du MIDI simultanément.

Le traitement temps réel des flux audio est très sensible à la latence. Pour utiliser JACK de manière optimale, il est donc nécessaire de configurer le noyau pour une utilisation temps réel.

3 Le problème

Même en utilisant un noyau configuré pour le temps réel et un ordonnancement à priorités fixées, il n’est pas simple d’obtenir de bons résultats.

Un premier problème est que l’ordonnanceur temps réel requiert les droits d’administration du système (root). Par conséquent, si des processus avec des priorités temps réel s’exécutent sans jamais s’interrompre, les autres processus ne s’exécutent jamais : ils souffrent de “famine” (starvation). Un deuxième problème est qu’il n’est pas simple de choisir la priorité à affecter aux différentes tâches concurrentes temps réel.

Pour permettre à un utilisateur sans les droits d’administrateur d’utiliser les fonctionnalités temps réel, il faut empêcher qu’un processus obtienne le contrôle exclusif du processeur. Le nouvel ordonnanceur SCHED_DEADLINE, disponible sur le noyau Linux à partir de la version 3.14, à été conçu pour répondre en partie à ce problème. Avec SCHED_DEADLINE, il est possible de contraindre le temps d’exécution d’une tâche à respecter un “quota” correspondant à une fraction du temps d’exécution total du processeur. De plus, avec SCHED_DEADLINE l’utilisateur n’a pas besoin de spécifier les priorités des tâches (elles sont calculées par l’ordonnanceur).

Il est donc possible de construire une architecture middleware pour la gestion plus efficace de la qualité de service des tâches temps réel. Cependant, l’ordonnanceur est un outil bas-niveau qui nécessite un temps d’apprentissage conséquent pour un programmeur.

4 Objectifs

L’objectif de ce projet est de concevoir et de réaliser une architecture logicielle pour gérer la qualité de service des applications multimedia sur Linux, basée sur le nouvel ordonnanceur SCHED_DEADLINE.

Cet objectif final ambitieux dépasse vraissemblablement le cadre de ce projet. On propose donc de concevoir un ensemble de petits outils, chacun simple et extensible. Voici une première liste, qui pourra être revue en fonction de l’évolution du projet :

  • Un outil pour mesurer les temps d’exécution des tâches gérées par SCHED_DEADLINE. On peut utiliser le module sched_deadline_spy comme point de départ.
  • Un outil pour contrôler l’admission de nouvelles tâches temps réel. L’outil est un processus “daemon” qui s’exécute avec des droits “root” et s’interface avec les tâches. Si une tâche demande à être gérée par l’ordonnancer SCHED_DEADLINE, elle envoie une requête au processus daemon qui vérifie qu’il reste suffisament de
    quota processeur pour accepter la requête. Si la réponse est positive, la tâche est acceptée ; sinon, la tâche est rejetée.
  • Un outil pour adapter le quota des tâches à leurs besoins, en utilisant un “feedback controller” (par exemple, comme ici: AQuOSA).
  • Une application de ces outils à JACK ou MPlayer.

Date: 2014-09-08T17:39+0200

Auteur: forget

Org version 7.9.3f with Emacs version 24

Validate XHTML 1.0

Tweet about this on TwitterShare on LinkedInShare on Google+Share on FacebookEmail this to someone