INF3990 : Projet de conception d un logiciel...

Département de génie informatique et génie logiciel

INF3990 : Projet de conception d’un logiciel embarqué

Exigences techniques de conception d’un lecteur MP3

nouveau genre

Complément au document de demande de

proposition no. H2013-INF3990

Version 1.3

Philippe Proulx, ing., chargé de laboratoire Simon Marchi, ing., chargé de laboratoire

Jérôme Collin, ing., M. Sc. A., responsable

Février 2013

École Polytechnique de Montréal

Caractéristiques techniques (DDP no. H2013-INF3990) J. Collin, P. Proulx, S. Marchi

École Polytechnique de Montréal Février 2013 2

Table des matières

Table des matières ................................................................................................................... 2 But du document ..................................................................................................................... 3 Perspective de l’étendue du produit ....................................................................................... 3 Aperçu du LMNG ...................................................................................................................... 4 Système .................................................................................................................................... 6

Matériel .................................................................................................................................. 6 Logiciel ................................................................................................................................... 6

Décodage MPEG ...................................................................................................................... 7 Librairie de décodage ............................................................................................................. 7 Décodage ............................................................................................................................... 7

Traitement de signal ................................................................................................................ 9 Égaliseur à bandes ................................................................................................................. 9 Intégration de l’égaliseur à bandes au décodage MP3 ..........................................................10 Préamplificateur et volume ....................................................................................................11 Écrêtage ................................................................................................................................11 Mixage mono .........................................................................................................................12 Balance .................................................................................................................................13 Résumé .................................................................................................................................14

Interface usager ......................................................................................................................15 Aperçu de l’écran ..................................................................................................................15 Division : live .........................................................................................................................17 Division : player .....................................................................................................................17 Division : EQ..........................................................................................................................18 Division : SA ..........................................................................................................................18 Division : playlist ....................................................................................................................18 Interrupteurs à glissière .........................................................................................................20 Afficheur LCD ........................................................................................................................20 Habillages .............................................................................................................................20

Communication réseau ..........................................................................................................25 Protocole d’application ..........................................................................................................25 Liste des listes de lecture ......................................................................................................25 Liste de lecture ......................................................................................................................26 Fichier MP3 ...........................................................................................................................26 Enregistrement d’une liste de lecture .....................................................................................26

Interface Web du serveur .......................................................................................................28 Modularisation du code source .............................................................................................29

Peu importe le langage ..........................................................................................................29 Exemples de modules ...........................................................................................................30 Truc pour modulariser ...........................................................................................................30

Contenu des livrables .............................................................................................................31 Livrable 1 ...............................................................................................................................31 Livrable 2 ...............................................................................................................................31

Aspects complémentaires ......................................................................................................32



But du document

Le présent document complète l’appel d’offre H2013-INF3990 en précisant les exigences

techniques dont les soumissionnaires devront tenir compte pour présenter des propositions

conformes. Ces exigences sont surtout regroupées en trois catégories qui sont la description

logique du fonctionnement du système en général, les interfaces et les tests à effectuer. Les

propositions devront détailler et démontrer comment ces exigences pourront être rencontrées.

Elles devront également servir de point de départ à l’élaboration du calendrier des diverses

tâches à réaliser.

Perspective de l’étendue du produit

Pour la phase 1 du projet, TV4K désire que le prototype soit réalisé sur puce FPGA Xilinx

Virtex-5. L’idée derrière le choix d’une puce FPGA est de permettre des mises à jour matérielles

rapides et nombreuses en cours de développement du prototype tout en permettant d’exécuter

des logiciels de plus en plus puissants, eux aussi en cours de développement. Éventuellement,

TV4K désire « figer » un design final dans plusieurs milliers d’ASIC afin de réduire les couts de

production durant la seconde phase du projet.

Le lecteur MP3 devra impérativement pouvoir se connecter à Internet pour aller y chercher les

fichiers à lire. Dans la phase 1 de prototypage, la connexion câblée, et non sans-fil, pourra être

utilisée pour fins de démonstration.

L’interface usager demandé par TV4K est précisée plus bas. Tout de même, l’entrepreneur

pourra soumettre des propositions de lui-même aux représentants de TV4K en vue d’améliorer

la proposition de base.

Pour ce contrat, TV4K recommande que les étapes de développement se déroulent sur la carte

Genesys de Digilent. Éventuellement, une carte de circuit imprimé très petite pourra être

envisagée durant la seconde phase du projet.



Aperçu du LMNG

Cette section décrit le LMNG (Lecteur MP3 Nouveau Genre) en surface. Les sections suivantes

décrivent en détails les fonctionnalités attendues.

Le LMNG est un lecteur MP3 dont les sources audio (fichiers MP3) sont distantes. La couche

physique du réseau n’est pas encore établie (ce pourrait être une connexion au réseau

cellulaire ou simplement à des réseaux sans-fil domestiques), mais s’assurer d’une connexion

TCP sur IP sera assez pour nos besoins.

Le schéma ci-dessus montre l’appareil envisagé de l’extérieur ainsi que son éventuel réseau.

Évidemment, le réseau Internet (« les tuyaux ») ne sera pas nécessaire pour une utilisation sur

réseau local avec une connexion 802.11, mais il est à considérer malgré tout.

Le schéma illustre les quatre transferts bidirectionnels différents qui peuvent avoir lieu entre le

LMNG et le serveur LMNG (qui conserve les fichiers et répond aux requêtes). Ces échanges et

le protocole d’application sous-jacent seront bien explicités dans les prochaines sections.

Le décodage MPEG (plus spécifiquement MPEG-1 Layer III, ou MP3) sera fait en temps réel

pendant la lecture audio. Le téléchargement sera toutefois indépendant, c’est-à-dire qu’un

fichier MP3 devra être complètement tamponné en mémoire vive avant d’être décodé et lu.

Cette contrainte permettra à TV4K d’accélérer énormément son développement logiciel tout en

ayant peu d’impact sur les utilisateurs, un fichier MP3 typique étant très rapidement téléchargé

avec les connexions modernes aux réseaux informatiques.

Ajouté au décodage se trouvera une panoplie d’éléments de traitement audio, notamment un

égaliseur à bandes. Ce filtre essentiel permet aux utilisateurs de compenser pour la qualité de

leurs hauts-parleurs en modifiant la réponse fréquentielle du signal décodé. Il est alors possible

d’augmenter les basses ou les hautes, d’imposer une courbe « rock » ou de diminuer

l’amplitude de certains instruments limités à quelques bandes. Tous les lecteurs audio

possèdent un minimum d’égaliseur et le LMNG ne fera pas exception. Il possèdera aussi un

préamplificateur, un mixeur mono facultatif, puis des contrôles de volume et de balance audio.



Au niveau de l’interface, le LMNG sera muni de 7 boutons poussoirs et de 2 interrupteurs à

glissière. Il sera possible de contrôler l’entièreté de l’appareil avec ces quelques entrées. La

sortie se fera sur un petit moniteur dont la résolution sera VGA (640 px par 480 px) ainsi que

sur un afficheur LCD. Puis, comme c’est souvent le cas avec les appareils embarqués, le

LMNG sera également muni d’un port série interne de débogage (RS-232) pour le

développement, mais ces broches ne seront pas accessibles à l’utilisateur final.

Le LMNG offrira aussi aux utilisateurs la possibilité de télécharger des habillages (skins) pour

son interface. Ceux-ci devront être téléchargés à l’aide d’un ordinateur personnel et envoyés

sur la mémoire Flash du LMNG grâce à une connexion USB qui a été développée par TV4K

lors d'un précédent projet et qui sera rendue disponible au contractant pour la réalisation du

présent projet.



Système

Cette section décrit le système envisagé. Il s’agit ici d’un logiciel s’exécutant sur un système

embarqué muni d’un FPGA.

Matériel

Tel qu’énoncé précédemment, les périphériques disponibles sur le système sont ceux de la

carte de développement Digilent Genesys. Celle-ci est munie d’un FPGA Virtex-5 XC5VLX50T

de Xilinx, lequel contiendra la logique nécessaire à l’exécution de l’appareil (bus, processeurs,

pilotes, intermédiaires logiciel/matériel, etc.). TV4K suppose que l’équipe de développement est

déjà familière avec l’environnement de développement de Xilinx. L’environnement de

développement recommandé est Xilinx ISE DS 13.2.

TV4K compte initialement utiliser les cores déjà développés par Xilinx. Le système doit être

muni, au minimum, des ressources suivantes :

au moins un processeur MicroBlaze proprement configuré pour le contexte (aucun FPU,

entre autres);

un accès à une mémoire vive de 256 MiB;

un accès à une mémoire Flash de 32 MiB;

un accès à l’interface réseau et à un tampon de paquets;

un pilote pour contrôler l’interface HDMI (vidéo);

un pilote pour contrôler l’interface AC’97 (audio);

un pilote pour contrôler l’interface RS-232;

7 boutons poussoirs et 2 interrupteurs (avec interruptions) en entrée;

un afficheur LCD en sortie;

deux compteurs dynamiques.

TV4K ne compte pas inclure d’unité de calcul de nombres à virgule flottante dans ses

processeurs pour réduire la consommation de son système en surface logique.

La fréquence d’horloge du système peut se situer entre 75 MHz et 100 MHz, selon ce que la

surface permettra avec les ressources susmentionnées. TV4K recommande de commencer le

développement à 75 MHz et d’augmenter cette valeur si elle ne convient pas.

Logiciel

TV4K précise ces seules contraintes logicielles :

produire un ou plusieurs exécutables statiques au format ELF;

utiliser le système d’exploitation xilkernel pour le développement du système;

utiliser la librairie lwIP en mode sockets (de pair avec xilkernel) pour toute

communication réseau.

Les langages C et C++ peuvent être utilisés pour réaliser la partie logicielle, quoique TV4K

recommande C++ pour bien modulariser l’architecture conçue.



Décodage MPEG

Le décodage MPEG est la raison d’être du LMNG et devra être approché avec minutie par

l’équipe de développement. Plus spécifiquement, le LMNG doit supporter parfaitement le

décodage de trames MPEG-1 Layer III. Les fichiers portant ces trames sont rituellement

nommés « fichiers MP3 » par l’homme et la femme de la rue; nous adhérons à ce vocabulaire

pour le reste du document.

À noter que le décodage MPEG est considéré indépendant du rendu audio dans ce document.

Celui-ci sera couvert dans une section subséquente. Le décodage, de façon grossière, prend

en entrée un flux MP3 et produit les échantillons destinés à l’interface audio.

Librairie de décodage

Dans toutes ses valeurs altruistes et ses convictions les plus profondes de changer le monde,

TV4K demande un minimum de code source libre dans ses plus récents produits. Évidemment,

le LMNG n’échappe pas à cet impératif.

La librairie libre libmad permet un décodage de haute qualité en utilisant un minimum de

ressource et une architecture logicielle relativement minimaliste. À tout le moins, cette librairie

convient parfaitement aux besoins du LMNG. TV4K ne désirant pas débourser les importantes

redevances que nécessiterait l’achat d’une licence commerciale de libmad, sa version GPL sera

utilisée. Ceci signifie évidemment, selon les termes de la GPL, que tout le code source que

vous produirez devra à son tour être ouvert. TV4K n’a pas d’objection à cette modalité.

La librairie libmad peut être téléchargée de son site Web officiel. Notez que celle-ci possède

son propre mécanisme de décodage et vous devrez le décortiquer afin de l’utiliser correctement

et de pouvoir y injecter les fonctionnalités du LMNG qui demandent une modification du flot de

décodage MPEG. La librairie est habituellement archivée avec un exemple minimaliste

montrant le décodage d’un fichier MP3 dans un environnement supportant les systèmes de

fichiers et une bonne allocation dynamique (voir minimad.c).

libmad est très configurable. En comprenant correctement la hiérarchie de ses fichiers sources,

vous pourrez certainement repérer comment la configurer pour qu’elle réponde de façon

optimale aux besoins du LMNG. Notamment, libmad intéresse particulièrement TV4K pour sa

possibilité de ne pas utiliser de nombres à virgule flottante, évitant ainsi l’ajout à priori inutile

d’un FPU au processeur configurable utilisé. Un FPU est effectivement assez couteux en

termes de surface et peut indirectement réduire la fréquence d’horloge maximale du système.

libmad permet d’utiliser des nombres à virgule fixe (qui sont en fait des entiers ordinaires).

Décodage

Concernant le LMNG, les fichiers à décoder proviennent du réseau (couvert dans une autre

section) et sont entièrement en mémoire vive avant le décodage. Vous devez ensuite fournir au

décodeur des petits blocs à décoder et celui-ci produira à son tour des petits blocs

d’échantillons audio à mettre en sortie. Vous devez donc vous organiser pour que le décodage

d’un petit bloc soit plus rapide que le temps de lecture audio du petit bloc précédent, au taux

http://www.underbit.com/products/mad/



d’échantillonnage de la pièce (qui sera toujours 44,1 kHz ou 48 kHz), ce qui est communément

appelé « temps réel ».

Une lecture audio qui n’est pas en temps réel parait immédiatement aux oreilles de l’utilisateur

puisqu’un silence s’insère entre les blocs lus pendant la fin du décodage du prochain bloc. Il

arrive également que les derniers échantillons soient lus en boucle au lieu d’un silence, ce qui a

pour effet audio une pièce qui semble ralentie. Dans tous les cas, l’expérience de l’utilisateur

est diminuée et TV4K tient absolument à éviter ce comportement.

Notez que le lecteur LMNG doit également pouvoir être mis en pause par l’utilisateur, ce qui a

pour effet d’arrêter complètement le rendu audio.



Traitement de signal

L’utilisateur moyen s’attend aujourd’hui à pouvoir, d’une façon ou d’une autre, modifier la

réponse fréquentielle du signal audio qu’il écoute de façon à corriger ou accentuer une certaine

plage. Plusieurs interfaces sont disponibles pour ce faire, notamment des prépositionnements

nommés (presets), comme « rock », « dance » ou « bass boost ». TV4K est toutefois désireuse

de rendre disponible un égaliseur à bandes avec son LMNG.

En plus de cet égaliseur, différentes fonctionnalités seront fournies avec le LMNG pour traiter le

signal en cours de lecture : un préamplificateur, une balance, une conversion stéréo vers mono

et un volume audio.

Égaliseur à bandes

Un égaliseur à bandes (aussi nommé « EQ » pour equalizer) accentue ou diminue les

fréquences d’une certaine bande. L’utilisateur a alors le contrôle sur plusieurs bandes

(généralement au moins huit pour un égaliseur assez flexible) et peut contrôler le timbre sonore

avec précision. Voici un exemple d’égaliseur à bandes sur le très célèbre lecteur audio pour

Windows, Winamp :

On voit ici 10 bandes, chacune contrôlant les fréquences « autour » de celles indiquées en bas.

Par exemple, la deuxième bande contrôle la puissance des fréquences autour de 180 Hz (bass)

et la dernière autour de 16 kHz (treble). En hauteur, ces sliders peuvent faire varier l’amplitude

de ces fréquences par -12 dB à +12 dB. Un signal à 0 dB est dit plat, ou flat; il n’y a donc ni

accentuation, ni diminution de puissance. L’origine mathématique est laissée en exercice au

lecteur.

La courbe ci-haut montre une réduction de puissance autour de 2,5 kHz. Ce n’est pas un

hasard : nous avons l’impression qu’une pièce sonne plus riche en fréquences en diminuant

l’intensité de ces fréquences puisque l’oreille humaine est plus sensible dans cette région :

Source : wikimedia.org



Il s’agit du résultat de l’évolution puisque la voix humaine se situe dans cette plage et notre

espèce a visiblement eu intérêt à mieux s’entendre au fil du temps.

L’égaliseur n’a pas comme seule utilité le rapprochement d’une courbe plate perçue par l’oreille

humaine; il est également très important pour pallier la réponse forcément imparfaite du

système de production audio utilisé (écouteurs, hauts-parleurs, etc.).

À noter que l’égaliseur peut être complètement désactivé par l’interface; aucune modification ne

doit alors être faite aux fréquences originales.

Intégration de l’égaliseur à bandes au décodage MP3

Par chance, le principe même du décodage MP3 fait usage de sous-bandes de fréquences.

C’est en réduisant le nombre de bits accordé au transport de certaines fréquences moins

importantes selon une analyse psychoacoustique que le standard MP3 réussit une bonne partie

de sa compression. Les valeurs de ces sous-bandes sont donc accessibles dans le décodeur :

après déquantification, avant IMDCT (algorithme mathématique qui passe de fréquences à un

signal dans le temps).

Dans le standard MPEG-1 Layer III, les blocs contiennent 32 sous-bandes de fréquences. TV4K

demande un égaliseur de 16 bandes. Le lecteur remarquera en observant la capture d’écran de

l’égaliseur de Winamp ci-haut que l’utilisateur peut contrôler 5 fréquences de 70 Hz à 1000 Hz,

puis les cinq suivantes couvrent un intervalle de 13 kHz. Il est en effet important que l’utilisateur

ait un meilleur contrôle sur les basses fréquences puisque la différence entre celles-ci est

beaucoup plus perceptible par l’oreille humaine qu’une même différence dans les hautes. Ceci

est dû aux zones de sensibilité sur la cochlée de l’oreille interne. Il sera donc nécessaire de

prioriser l’ajustement des basses fréquences.

TV4K demande le contrôle sur les sous-bandes suivantes :

Vous voyez ainsi la correspondance entre les sous-bandes à contrôler directement et le point

de contrôle accessible à l’utilisateur.

Toute modification doit être faite en décibels et -12 dB à +12 dB, comme Winamp, est un

intervalle intéressant. Les sous-bandes du MP3 inaccessibles directement par l’utilisateur

(comme les sous-bandes b, d et e) devront prendre une valeur à partir d’une interpolation

linéaire en décibels en prenant les deux voisins contrôlés comme référence. Par exemple, si la

sous-bande c est fixée par l’utilisateur à +4 dB (par le contrôle b) et la sous-bande f à -5 dB

(par le contrôle c), alors la sous-bande d sera à +1 dB et la sous-bande e à -2 dB (chacune des

valeurs de bandes étant alors espacées par 3 dB, d’où l’interpolation linéaire).

g h i j k l m n o p q r s t u v0 1 2 3 4 5 6 7 8 9 a b c d e f

d e f0 1 2 3 4 5 6 7 8 9 a b c

32 sous-bandes du MP3

16 contrôles de l’égaliseur



Nous laissons à l’équipe de développement le soin d’explorer les mathématiques impliquées

derrière les conversions vers/de décibels.

Une autre importante considération dans cette section est la notion de temps réel. Il sera

évidemment de rigueur de réserver un tampon pour les échantillons décodés afin qu’aucune

saccade ne soit perçue dans le son. Toutefois, comme les échantillons décodés ont déjà subi

l’égalisation, si le tampon est très grand – par exemple, 20 secondes d’échantillons décodés –,

alors la modification de l’égaliseur par l’utilisateur n’aura qu’un effet 20 secondes plus tard. Ce

délai n’est pas souhaitable pour une calibration précise par l’utilisateur. TV4K demande donc

qu’un délai de maximum 262 ms soit perçu entre la modification d’un paramètre de l’EQ et son

résultat audio. Le moins de délai possible ici est toujours souhaitable. 262 ms correspondent à

environ 10 trames MP3 décodées (au taux d’échantillonnage 44,1 kHz).

Préamplificateur et volume

Le volume audio est généralement un traitement audio minimal appliqué au signal à la toute fin

de la chaine. Il va de 0 dB à une valeur négative (-40 dB et moins). Le codec utilisé pour la

génération du signal audio réel, AC’97, permet de contrôler le volume à même la puce et il sera

intéressant d’utiliser ce service. AC’97 offre 32 valeurs possibles pour le volume.

La préamplification est indépendante du volume audio et permet de diminuer le gain d’un signal

beaucoup trop fort (pour pouvoir l’égaliser sans sortir de la plage dynamique). Il permet aussi

d’augmenter le gain d’un signal beaucoup trop faible. En effet, même avec un volume maximal

(0 dB), un enregistrement trop faible peut ne pas être assez fort; le préamplificateur permet

donc d’augmenter le gain avant l’amplification.

La préamplification n’a rien de sorcier : il faut simplement augmenter la puissance de toutes les

fréquences par une constante. Celle-ci, comme pour l’égaliseur à bandes, pourra varier de

12 dB à +12 dB.

La préamplification est activée lorsque l’égaliseur est activé, et désactivée sinon.

Écrêtage

Avec la préamplification et l’égaliseur à bandes arrive un problème : comme l’accentuation peut

être positive en décibels (contrairement au volume qui ne peut qu’être plat ou diminuer), les

échantillons peuvent dépasser la valeur maximale de la plage. Pour un signal typique entre -1.0

et +1.0, ceci signifie avoir des échantillons plus grand que +1.0 ou plus petit que -1.0. Dans le

cas d’AC’97, on parle d’échantillons en dehors de la plage signée sur 16 bits (-32 768 à

+32 767).

Il n’y a pas de solution simple à ce problème, c’est-à-dire que celles qui sont disponibles ont

toutes leurs avantages et leurs désavantages. Une solution qui produit un bon résultat audio est

de dynamiquement modifier la préamplification du signal, c’est-à-dire qu’en se rendant compte

que le signal est trop fort, on baisse un peu (automatiquement) la préamplification pour calibrer.

Cet algorithme, pour qu’il soit bien implémenté, demande beaucoup de logique et trop de temps

pour notre contexte.



Dans le cadre du LMNG, qui n’est pas un dispositif audio pour professionnels, un simple

écrêtage (clipping) sera suffisant.

Source : wikimedia.org

Comme le montre l’illustration ci-haut, il s’agit de ramener à ses limites un signal qui sort de

celles-ci. En termes plus simples : si un échantillon dépasse négativement -32 768, le ramener

à -32 768 et s’il dépasse positivement +32 767, le ramener à +32 767. Il faudra alors faire

attention aux débordements et aux types de données temporaires utilisés, sans quoi il y aura

wrapping et des résultats audio insoupçonnés.

L’écrêtage n’est pas ce qui sonne le mieux (il introduit indirectement au signal des fréquences

qui produisent une distorsion), mais le rendu est déjà mieux qu’en acceptant les débordements.

Mixage mono

Il pourrait arriver qu’un utilisateur souhaite convertir le signal stéréo d’une pièce MP3 décodée

vers un signal mono (même chose sur les deux hauts-parleurs). Les situations où cette

fonctionnalité est intéressante sont :

l’utilisateur possède une paire d’écouteurs et souhaite écouter une musique en même

temps qu’une autre personne; les deux personnes ont chacun un écouteur et veulent le

même signal dans les deux;

l’utilisateur branche son LMNG à une paire d’hauts-parleurs où un des deux est muet

(puisque défectueux) et souhaite obtenir tout le signal dans un seul.

Constatez par exemple la forme d’onde de la pièce Drive My Car des Beatles (1965),

enregistrée à l’époque folle où le stéréo était récent pour les consommateurs et exploité à ses

limites (s’apparente en fait à deux signaux mono à gauche et à droite) :



The Beatles – Drive My Car (1965)

Sur cette pièce, les voix sont des deux côtés, mais le piano est seulement à droite, tandis que la

basse, la guitare et la batterie sont seulement à gauche. Puis, pendant le solo de guitare, celle-

ci est seulement à droite. On voit donc l’intérêt d’un mix stéréo vers mono. Mais ce n’est pas

tout. Certains prétendent aujourd’hui que plusieurs pièces très stéréo sont meilleures lorsque

remixées en mono.

Pour mixer de stéréo à mono, il faut produire un signal audio qui est la moyenne arithmétique

des deux signaux indépendants du stéréo. Ce nouveau signal est envoyé de façon identique à

gauche et à droite.

Balance

La balance (à ne pas confondre avec le panning utilisé au cours de la production d’un mix) est

le contrôle des volumes relatifs à gauche et à droite. Celle-ci ne modifie pas le chemin des

échantillons, mais bien les volumes indépendants de chaque côté.

Le volume audio sert à diminuer l’intensité du signal produit des deux côtés, tandis que la

balance vient par la suite contrôler les volumes des deux côtés. Le codec AC’97 a la capacité

de modifier indépendamment les volumes à gauche et à droite.

La balance varie généralement de 100 % à gauche à 0 % à gauche, puis de 0 % à droite vers

100 % à droite. 0 % à gauche ou 0 % à droite sont équivalents et sont habituellement nommés

« centre ».

http://gizmodo.com/5216258/sorry-stereo-but-beatles-in-mono-rocks-a-lot-more



Résumé

Le flot de données suivant illustre un résumé du processus et ses conditions :

Bandes retrouvées par le

décodeur MP3

Écrêtage

Mix mono?

Volume & balance

Mixage mono

Trame MP3

Signal audio réel

EQ activé? Préamplification

ÉgalisationReste du décodage MP3

Oui

Non

Oui

Non



Interface usager

Le LMNG envisagé devra posséder :

7 boutons poussoirs;

deux interrupteurs à glissière;

un afficheur LCD (pour la phase de prototypage) et

un moniteur (résolution VGA : 640 px par 480 px).

L’interaction entre les contrôles et les vues est précisée dans cette section.

Aperçu de l’écran

TV4K demande que son LMNG supporte plusieurs habillages que n’importe quel utilisateur peut

soumettre en ligne. Un habillage, ou skin, est une apparence personnalisée de l’interface

usager. Le format des habillages est décrit dans une prochaine sous-section.

Afin de simplifier la tâche au développement, les emplacements de tous les contrôles et de

toutes les vues sur l’écran de résolution VGA sont prédéterminés. La création d’un habillage

correspond alors simplement à copier les bons pixels dans les bons rectangles du canevas.

Voici un aperçu des emplacements des contrôles et des vues, chacun étant identifié, dans un

canevas créé par l’équipe de design graphique de TV4K :



Le plus grand rectangle bleu (celui qui touche au noir) représente le canevas de 640 px par

480 px. Chaque élément de ce schéma a un identifiant textuel unique. Cette image est donnée

en référence, sans compression, avec ce document (fichier canvas_ref.png). Elle montre les

emplacements exacts de chaque élément.

Les boutons de l’interface servent la plupart du temps à se déplacer d’un contrôle à l’autre.

Dans toutes les divisions sauf live (voir plus bas), les boutons gauche/droite/haut/bas (mini-

joystick sur la carte de développement Genesys) permettent ceci, tandis que le bouton du

centre appuie sur un contrôle lorsque c’est possible (boutons et options).

Le lecteur se divise en cinq parties principales. Celles-ci sont décrites dans le tableau suivant.

Nom de la division

Préfixe Description Notes

Live live Correspond à un état de l’interface usager où les boutons sont réservés à des actions prédéterminées.

Le seul élément actif de cette division est le point de focus livefocus.

Player py Options du lecteur, paramètres audio et barre de progrès.

Les boutons d’options (pyopt*) peuvent être activés ou désactivés avec le bouton du centre. Les sliders pybar* (sauf pybarseeking) peuvent se faire contrôler, lorsqu’ils ont le focus, par les boutons gauche et droite. Les vues statiques pydig* indiquent le temps de lecture écoulé du fichier en cours. La vue pyst est réservée à un icone indiquant le statut de lecture (en lecture ou en pause).

EQ eq Égaliseur à bandes et préamplificateur.

Dans cette division, les boutons gauche/droite permettent de changer de contrôle. Les boutons bas/haut montent et descendent les valeurs du slider sélectionné (eqbar*).

SA sa Analyseur de spectre. Il ne s’agit pas d’une division où l’utilisateur a un contrôle, mais seulement d’une vue statique. Chacun des sliders sabar* montre l’intensité d’une bande de fréquence associée (expliqué plus bas dans ce document).

Playlist pl Liste de lecture en cours.

Les boutons pybtn* effectuent des actions, tandis que toute la zone playlist peut être utilisée de façon libre par l’équipe de développement pour réaliser la liste de lecture.



Les entrées des boutons gauche/droite/haut/bas/centre et d’un bouton additionnel (BTN1 sur la

carte Genesys) ne sont effectives que dans une seule division à la fois : celle qui a le focus. Le

focus peut être changé d’une division à l’autre par un bouton réservé à cet effet (BTN0 sur la

carte Genesys). Le focus boucle alors avec cet ordre sur les divisions :

1. live

2. player

3. EQ

4. playlist

Lorsqu’une division possède le focus, son identifiant de focus (les régions rouges sur le

canevas en référence) devient distinctif par rapport aux autres.

Les prochaines sous-sections décrivent chacune des cinq divisions de l’écran en détails.

Division : live

Lorsque cette division a le focus, les différents boutons effectuent des actions prédéterminées :

gauche : recule dans le décodage de la pièce en cours par un bond de 5 secondes

(revient au début de la pièce si le temps écoulé est plus petit que 5 secondes);

droite : avance dans le décodage de la pièce en cours par un bond de 5 secondes

(passe à la prochaine pièce dans la liste de lecture si la différence entre le temps total

de la pièce et le temps écoulé est plus petit que 5 secondes);

haut : passe à la pièce précédente dans la liste de lecture;

bas : passe à la pièce suivante dans la liste de lecture;

centre : permute l’état du lecteur entre « lecture » et « pause ».

Division : player

Dans cette division, l’utilisateur peut modifier les options du lecteur, puis ajuster le volume et la

balance audio. C’est également celle-ci qui indique le statut de lecture.

Le slider pybarvolume contrôle le volume audio. Celui-ci doit passer de muet (lorsque la poignée

est complètement à gauche) à 0 dB (lorsque la poignée est complètement à droite). Lorsque ce

contrôle a le focus, le bouton BTN1 le remet complètement à droite (volume maximal).

Le slider pybarbalance contrôle la balance audio. Celle-ci doit passer de 100 % à gauche

(lorsque la poignée est complètement à gauche) au centre (lorsque la poignée est au centre) à

100 % à droite (lorsque la poignée est complètement à droite). Lorsque ce contrôle a le focus,

le bouton BTN1 le remet au centre (balance centrée).

Les boutons d’options pyopt* sont décrits ainsi (l’action est faite par le bouton du centre) :

pyoptshuffle : active/désactive le mode aléatoire de la liste de lecture;

pyoptrepeat : active/désactive le mode répétition de la liste de lecture;

pyoptmonomix : active/désactive le mixage stéréo;

pyopteneq : active/désactive le l’égaliseur à bandes et la préamplification.



Les quatre chiffres identifiés par pydig* servent à afficher le temps de lecture en cours, à partir

de 0. Les vues pydig3 et pydig2 indiquent le nombre de minutes et pydig1 et pydig0 le nombre

de secondes. Chaque chiffre qui n’est pas utilisé doit être mis à 0.

L’icone pyst indique le statut de lecture audio. Une lecture en cours affichera un petit triangle et

une lecture en pause deux petites barres verticales. Au démarrage du LMNG, le statut est

initialement en pause.

Enfin, le slider pybarseeking montre le progrès de lecture audio dans la pièce. Lorsqu’il est au

début, la pièce commence et lorsqu’il est à la fin, celle-ci s’achève. L’utilisateur ne peut pas

avoir le focus sur ce contrôle, bien qu’il fasse néanmoins partie de la division player.

Division : EQ

La division EQ permet de contrôler l’égaliseur à bande et le préamplificateur. Tel qu’énoncé

précédemment, chacun des sliders ici a une plage virtuelle qui va de -12 dB (lorsque la poignée

est complètement en bas) à +12 dB (lorsque la poignée est complètement en haut). L’EQ doit

être initialement plat, c’est-à-dire que chaque poignée doit être centrée sur son slider.

Pour chacun des sliders, le bouton BTN1 remet la valeur à 0 dB (au centre).

Division : SA

L’analyseur de spectre (ou spectrogramme) montre à l’utilisateur l’intensité de chacune des

mêmes bandes que l’égaliseur contrôle. Il doit montrer le résultat après préamplification et

après égalisation, mais évidemment avant volume et balance. Il est nécessaire de faire la

moyenne des intensités des canaux gauche et droit ici.

L’affichage de la valeur sur chaque slider se fait aussi au moyen d’une poignée volatile en

hauteur. Celle-ci sera très mince (2 pixels) pour permettre un meilleur taux de rafraichissement.

La valeur doit aller linéairement (en décibels) de -80 dB et moins (complètement en bas) à

3 dB et plus (complètement en haut).

Il n’est vraiment pas nécessaire de mettre à jour l’analyseur de spectre à chaque trame MP3

décodée. Un taux de 3 Hz ou 4 Hz est parfaitement envisageable pour le calibre du LMNG.

Division : playlist

La liste de lecture est un espace où se trouvent listés les fichiers téléchargeables (ou

téléchargés). Cette liste peut être chargée du serveur LMNP, modifiée localement, puis

sauvegardée en tant que nouvelle liste sur le serveur. Toutes les opérations concernant le

protocole réseau sont explicitées dans la section appropriée du document (plus bas).

Les contrôles de la liste de lecture sont les suivants (appuyés avec le bouton du centre) :

plbtnshuf : rend aléatoire les items de la liste de lecture;

plbtnsort : ordonne en ordre croissant les items de la liste de lecture par nom de fichier;

plbtnsave : sauvegarde la liste en cours à distance;



plytnload : charge une liste distante en tant que liste en cours (écrase la liste en cours).

Tout l’espace marqué playlist est réservé à l’affichage de la liste de lecture. Dans cet espace,

TV4K laisse la responsabilité aux développeurs de trouver une façon d’organiser la liste. Un

mécanisme devrait être prévu lorsqu’il y a trop d’items (pagination, défilement, etc.).

Les chaines à afficher dans l’espace seront encodés en ASCII non-étendu sur 8 bits. Les items

doivent avoir ce format :

#. info temps

Ici, # identifie l’indice de l’item (à partir de 1) dans la liste de lecture. La sous-chaine info est

l’information (ou titre) tirée de l’entrée dans la liste de lecture M3U (décrite plus loin dans ce

document). Le temps total de la pièce (temps) doit être aligné à droite et au format mm:ss. Si la

chaine alignée à gauche déborde sur le temps total, le temps total doit avoir la priorité

d’affichage.

L’affichage de chaines de textes sur le canevas est également laissé à l’équipe de

développement. TV4K tient toutefois à souligner que plusieurs définitions de polices GPL

couvrant le jeu de caractères ASCII existent déjà en langage C dans la source de Linux. Plus la

taille de la police est petite, plus d’éléments peuvent entrer dans l’espace réservé à la liste de

lecture.

L’arrière-plan de l’espace playlist sera fourni par l’arrière-plan général de l’habillage. La

couleur de la police sera également fournie de façon à ce qu’elle contraste bien avec l’arrière-

plan.

L’item « en cours » est celui qui représente la source de la lecture en cours. Un seul item peut

être en cours. Un item sélectionné peut subir une modification parmi :

déplacement : monter ou descendre (si possible) l’item dans la liste, tout en demeurant

sélectionné;

suppression : retrait définitif de l’item de la liste.

Un seul item peut être sélectionné à la fois, mais l’item sélectionné peut également être l’item

en cours. L’utilisateur du LMNG doit pouvoir différencier, d’une façon ou d’une autre, les quatre

états possibles :

normal;

en cours;

sélectionné;

la combinaison en cours et sélectionné.

L’utilisateur doit aussi pouvoir passer facilement aux boutons plbtn*. Nous conseillons le

bouton droite pour ce faire, quoique le bouton BTN1 puisse aussi être utile si les boutons

gauche et droite sont utilisés pour le déplacement de l’item sélectionné. Évidemment, le bouton

BTN0, toujours réservé au changement de focus, ne peut pas être utilisé.

http://lxr.linux.no/linux+v3.7.6/drivers/video/console/



L’enregistrement et l’ouverture de listes de lecture devront montrer des sous-fenêtres (popups)

toujours dans la zone de la liste de lecture. Pour l’enregistrement, il faudra un mécanisme pour

que l’utilisateur puisse entrer du texte et accepter/annuler avec les 6 boutons accessibles. Le

jeu de caractère pour l’entrée de texte peut être limité aux 26 lettres minuscules et aux 10

chiffres.

Interrupteurs à glissière

Les deux interrupteurs à glissière de la carte ont toujours les rôles suivants :

SW0 : active/désactive le son (fonction mute);

SW1 : active/désactive l’ensemble du reste des entrées d’utilisateur (fonction hold).

Afficheur LCD

Seulement pour la phase de prototypage, l’afficheur LCD devra montrer le progrès de

téléchargement. Ceci permettra à TV4K de mesurer la vitesse de transfert maximale pratique

pour produire le tableau de spécifications du LMNG.

Le progrès devra être montré, pour chaque fichier MP3 téléchargé, en pourcentage du fichier

complet. Les détails concernant la communication réseau suivent dans une autre section.

Habillages

Un habillage spécifie ce que chaque région de l’écran VGA doit contenir, incluant les différents

états des boutons, les chiffres, les poignées des sliders, l’icone d’état, etc. Voici un exemple de

canevas du LMNG avec un certain habillage :



Un habillage est décrit simplement par une seule image Bitmap 24-bit. Celle-ci contient toutes

les parties de l’habillage à des positions spécifiées absolument par ces exigences.

L’habillage spécifie également trois couleurs, chacune grâce à un pixel de cette couleur dans

l’image Bitmap en question :

la couleur de la police de la liste de lecture;

une couleur qui contraste bien avec la couleur précédente (peut être utilisée pour créer

un arrière-plan pour un item sélectionné);

une couleur différente qui contraste bien avec l’arrière-plan de la liste de lecture et avec

la première couleur (peut être utilisée pour sélectionner l’item en cours de lecture).

Il n’est pas obligatoire d’utiliser les deux dernières couleurs si vous avez d’autres méthodes de

sélection.

Voici un exemple de Bitmap décrivant l’habillage montré ci-haut :

Un seul habillage peut être utilisé à la fois et il n’est pas possible de le modifier pendant

l’exécution du LMNG. L’image Bitmap en question est placée en mémoire Flash par l’utilisateur.

En tant que développeurs du lecteur, vous pouvez supposer que l’image est déjà en mémoire

Flash à l’adresse 0.

Afin d’améliorer la phase de développement, TV4K spécifie les positions et tailles de toutes les

régions d’un habillage à l’aide d’un fichier texte muni d’un format très simple. Ce fichier texte

(nouvelles lignes de type UNIX), nommé skinspec.txt, est fourni avec ce document. Il doit

absolument être utilisé puisqu’une révision de spécifications pourrait avoir lieu à tout moment

et la seule mise à jour de ce fichier par TV4K permettra au lecteur développé de s’y adapter

instantanément. Ce fichier peut être placé en mémoire Flash à l’extérieur de la région utilisée

pour l’image Bitmap de l’habillage.



Le format de skinspec.txt est le suivant. Les éléments en rouge sont des variables expliquées

dans le commentaire juste au-dessus. Lorsque des chaines littérales sont données avec

guillemets, la vraie valeur n’inclut pas les guillemets. Les positions et les tailles sont toutes

données en pixels. La position (0, 0) correspond au pixel en haut à gauche dans les images.

# une ligne débutant par "#" représente un commentaire jusqu’à la fin de la ligne # les lignes vides sont également autorisées # arrière-plan (occupe toujours tout le canevas de destination) # sx : position en X dans l’habillage # sy : position en Y dans l’habillage bg sx sy # points de focus # id : identifiant du point # sx : position en X dans l’habillage (hors focus) # sy : position en Y dans l’habillage (hors focus) # fsx : position en X dans l’habillage (focus) # fsy : position en Y dans l’habillage (focus) # w : largeur # h : hauteur # dx : position en X dans la destination # dy : position en Y dans la destination id sx sy fsx fsy w h dx dy # chiffres de la division player (pydig*) (sur une seule ligne) # 0sx : position du chiffre 0 en X dans l’habillage # 0sy : position du chiffre 0 en Y dans l’habillage # 1sx : position du chiffre 1 en X dans l’habillage # 1sy : position du chiffre 1 en Y dans l’habillage # 2sx : position du chiffre 2 en X dans l’habillage # 2sy : position du chiffre 2 en Y dans l’habillage # 3sx : position du chiffre 3 en X dans l’habillage # 3sy : position du chiffre 3 en Y dans l’habillage # 4sx : position du chiffre 4 en X dans l’habillage # 4sy : position du chiffre 4 en Y dans l’habillage # 5sx : position du chiffre 5 en X dans l’habillage # 5sy : position du chiffre 5 en Y dans l’habillage # 6sx : position du chiffre 6 en X dans l’habillage # 6sy : position du chiffre 6 en Y dans l’habillage # 7sx : position du chiffre 7 en X dans l’habillage # 7sy : position du chiffre 7 en Y dans l’habillage # 8sx : position du chiffre 8 en X dans l’habillage # 8sy : position du chiffre 8 en Y dans l’habillage # 9sx : position du chiffre 9 en X dans l’habillage # 9sy : position du chiffre 9 en Y dans l’habillage # w : largeur # h : hauteur # 3dx : position de pydig3 en X dans la destination # 3dy : position de pydig3 en Y dans la destination # 2dx : position de pydig2 en X dans la destination # 2dy : position de pydig2 en Y dans la destination # 1dx : position de pydig1 en X dans la destination # 1dy : position de pydig1 en Y dans la destination # 0dx : position de pydig0 en X dans la destination # 0dy : position de pydig0 en Y dans la destination pydig 0sx 0sy 1sx 1sy 2sx 2sy 3sx 3sy 4sx 4sy 5sx 5sy 6sx 6sy 7sx 7sy 8sx 8sy 9sx 9sy w h 0dx 0dy 1dx 1dy 2dx 2dy 3dx 3dy



# icone d’état de lecture de la division player # plsx : position en X dans l’habillage (lecture) # plsy : position en Y dans l’habillage (lecture) # pasx : position en X dans l’habillage (pause) # pasy : position en Y dans l’habillage (pause) # w : largeur # h : hauteur # dx : position en X dans la destination # dy : position en Y dans la destination pyst plsx plsy pasx pasy w h dx dy # boutons d’options (pyopt*) # id : identifiant du bouton d’option # sx : position en X dans l’habillage (sans focus, désactivé) # sy : position en Y dans l’habillage (sans focus, désactivé) # fsx : position en X dans l’habillage (focus, désactivé) # fsy : position en Y dans l’habillage (focus, désactivé) # esx : position en X dans l’habillage (sans focus, activé) # esy : position en Y dans l’habillage (sans focus, activé) # fesx : position en X dans l’habillage (focus, activé) # fesy : position en Y dans l’habillage (focus, activé) # w : largeur # h : hauteur # dx : position en X dans la destination # dy : position en Y dans la destination id sx sy fsx fsy esx esy fesx fesy w h dx dy # boutons (plbtn*) # id : identifiant du bouton # sx : position en X dans l’habillage (sans focus) # sy : position en Y dans l’habillage (sans focus) # fsx : position en X dans l’habillage (focus) # fsy : position en Y dans l’habillage (focus) # w : largeur # h : hauteur # dx : position en X dans la destination # dy : position en Y dans la destination id sx sy fsx fsy w h dx dy # sliders (*bar*) # id : identifiant du slider # sx : position de la poignée en X dans l’habillage (sans focus) # sy : position de la poignée en Y dans l’habillage (sans focus) # fsx : position de la poignée en X dans l’habillage (focus) # (toujours 0 pour sabar* et pybarseeking, doit être ignoré) # fsy : position de la poignée en Y dans l’habillage (focus) # (toujours 0 pour sabar* et pybarseeking, doit être ignoré) # w : largeur de la poignée # h : hauteur de la poignée # lowdx : position minimale de la poignée en X dans la destination # lowdy : position minimale de la poignée en Y dans la destination # hidx : position maximale de la poignée en X dans la destination # hidy : position maximale de la poignée en Y dans la destination id sx sy fsx fsy w h lowdx lowdy hidx hidy



# région de la liste de lecture (playlist) sur le canevas # w : largeur # h : hauteur # dx : position en X dans la destination # dy : position en Y dans la destination playlist w h dx dy # couleur de la police dans la liste de lecture # x : position en X du pixel montrant la couleur dans l’habillage # y : position en Y du pixel montrant la couleur dans l’habillage plfontcolor x y # couleur qui contraste bien avec la couleur de police ci-haut # x : position en X du pixel montrant la couleur dans l’habillage # y : position en Y du pixel montrant la couleur dans l’habillage plfontcolor2 x y # couleur qui contraste bien avec l’arrière-plan de la liste et plfontcolor # x : position en X du pixel montrant la couleur dans l’habillage # y : position en Y du pixel montrant la couleur dans l’habillage plfontcolor3 x y

TV4K rappelle que la librairie standard C fournit plusieurs fonctions très utiles au décodage d’un

tel fichier texte.

Notez particulièrement la région de la liste de lecture (commence par playlist dans

skinspec.txt) montre seulement où elle doit se trouver dans le canevas du LMNG. Il est

important de limiter le traçage que vous faites dans cette zone en vous servant de ces

informations.



Communication réseau

Cette section décrit les communications réseaux du LMNG et le comportement attendu. Le

LMNG peut effectuer quatre types de requêtes au serveur LMNG :

télécharger la liste à jour des listes de lectures disponibles;

télécharger une liste de lecture spécifique;

télécharger un fichier MP3 et

enregistrer une nouvelle liste de lecture.

Les prochaines sous-sections décrivent le protocole et chacune de ces requêtes.

Protocole d’application

Le protocole utilisé pour toutes les requêtes (et leurs réponses) est HTTP 1.1. TV4K suppose

que les développeurs possèdent une très bonne base en matière de protocole HTTP. Celui-ci

est bien évidement « sur » TCP/IP.

L’utilisation d’un serveur HTTP permet aux développeurs du serveur de réutiliser plusieurs

éléments de code source libre et d’avoir un très bon support à travers le temps puisque ce

protocole est probablement le plus utilisé de tous les temps en nombre de requêtes.

Il est très important de gérer les statuts de réponses HTTP, plus spécifiquement le fameux

statut 404 qui indique que la ressource demandée est introuvable. Dans ce cas exceptionnel,

l’opération effectuée peut être ignorée. Dans le meilleur des mondes, un message peut être

affiché à l’utilisateur.

Sur le serveur se trouvent servis aux LMNP principalement trois ressources :

une liste des listes de lecture située à l’URL /lol par rapport à la racine du serveur

(« lol » pour « list of lists »);

les listes de lecture, situées dans le répertoire /m3us par rapport à la racine du serveur;

les fichiers MP3, situés dans le répertoire /mp3s par rapport à la racine du serveur.

Liste des listes de lecture

La liste des listes de lecture est un simple fichier texte où se trouve la liste de toutes les listes

de lecture disponibles sur le serveur, accompagnées d’autres informations. On y retrouve une

entrée par ligne (nouvelles lignes de type UNIX). Le format d’une entrée est :

nom nb durée

où nom est le nom du fichier M3U (inclut l’extension .m3u, toujours sans espace, n’inclut pas le

répertoire /m3us), nb est le nombre de fichiers MP3 inclus par cette liste (minimum 1) et durée

est la durée totale de la liste en secondes.



TV4K demande que ces informations soient affichées lors de la présentation de cette liste à

l’utilisateur lorsqu’il appuie sur le bouton plbtnload.

Liste de lecture

Toutes les listes de lecture ont le format M3U étendu. Ce format est très standard et

particulièrement prisé dans la communauté Winamp. Il est très bien décrit sur cette page Web.

Ce format est idéal puisqu’il inclut le nombre de secondes de chaque pièce et un titre à afficher

dans une liste de lecture. Voici un exemple fictif :

#EXTM3U #EXTINF:181,The Beatles - I'm Only Sleeping beatsleeping.mp3 #EXTINF:187,Weird Al Yankovic - This is the Life everythingwrong.mp3 #EXTINF:481,Rebelution - R Way rebelrway15.mp3

Ici, les noms de fichiers seront toujours listés sans leur répertoire /mp3s sur le serveur.

Il faut faire attention aux titres : l’artiste n’est pas nécessairement séparé du titre par un trait

d’union; il s’agit d’une chaine complète à afficher telle quelle en tant que nom d’élément dans la

liste de lecture présentée à l’utilisateur.

Dans ce format, les lignes vides doivent être ignorées.

Fichier MP3

Un fichier MP3 peut être téléchargé comme n’importe quel autre fichier grâce à une requête

HTTP.

Enregistrement d’une liste de lecture

Lorsque l’utilisateur adapte une liste de lecture téléchargée en modifiant l’emplacement

d’éléments et en en supprimant, il doit avoir la possibilité d’enregistrer la nouvelle version de sa

liste sur le serveur LMNP. Tous les serveurs LMNP supportent cette requête.

Celle-ci doit être faite à l’URL /createList à partir de la racine du serveur.

Du côté HTTP, il s’agit d’une requête avec la méthode HTTP POST, dont voici les paramètres :

name : nom de la liste (sans extension .m3u), maximum 32 caractères;

list : une seule chaine représentant la liste ordonnée des noms de fichiers (avec

extension .mp3) séparés par des barres obliques (/);

username : nom d’utilisateur préalablement enregistré dans l’appareil;

http://forums.winamp.com/showthread.php?threadid=65772



password : mot de passe préalablement enregistré dans l’appareil.

Voici un exemple du contenu de la requête (sans l’entête HTTP) :

name=woohoo&list=yeah.mp3/rebelr15.mp3/wrong.mp3&username=babyphat69&password=ilovecats

TV4K permet que le nom d’utilisateur et le mot de passe soient enregistrés à même le code

source pour la phase de prototypage. L’entreprise tient aussi à souligner que les noms de

fichiers n’auront jamais d’autres caractères que ceux permis pour une URL, donc il est inutile de

prévoir un mécanisme de traduction pour ces noms.

La liste peut se terminer par un / (le dernier élément « vide » sera ignoré par le serveur).

Le corps de la réponse HTTP à cette requête par le serveur sera la simple chaine saved si la

sauvegarde a fonctionné et failed sinon.



Interface Web du serveur

Fourni avec le LMNP sera un logiciel implémentant un serveur HTTP et une interface Web de

gestion des listes de lecture et des fichiers MP3. Il sera alors possible pour l’utilisateur d’y

soumettre des fichiers MP3 et de générer dynamiquement, en ligne, des listes de lecture.

L’utilisateur pourra aussi soumettre des habillages afin de les conserver.

La version de l’interface Web fournie avec le serveur de test comporte également deux sections

montrant les journaux du serveur HTTP et de tcpdump, un outil analysant tous les paquets

réseaux échangés avec les LMNP. TV4K a mis ces journaux à la disposition des développeurs

avec l’espoir qu’ils aident au déverminage du projet.



Modularisation du code source

Tel qu’énoncé précédemment, l’utilisation de libmad en tant que décodeur MPEG impose au

LMNG une licence GPL et donc un code source ouvert. TV4K joue donc directement sa

réputation en mettant entre vos mains la réalisation de code source qui pourra être critiqué et

revu à travers toute la planète. Dans cette optique, l’entreprise est extrêmement soucieuse de la

qualité du code produit par l’équipe de développement.

Mis à part la syntaxe cohérente d’un fichier à l’autre et les commentaires pertinents, il est

impératif que le code source produit soit très modulaire. En ingénierie, il est toujours bon pour

la maintenabilité et l’amélioration éventuelle d’un produit qu’il soit constitué de plusieurs

modules très découplés. Imaginez si un consommateur devait changer de voiture chaque fois

que son démarreur était défectueux, ou encore s’il était impossible de changer les

périphériques de son ordinateur personnel (hum hum, Mac).

On entend par « module » une paire de fichiers .cpp/.hpp en C++ ou .c/.h en langage C.

Évidemment, une classe peut dériver d’une autre, mais l’architecture ne devrait quand même

pas être toute soudée ensemble. On peut retrouver les fichiers utils.h/utils.c, par exemple,

qui contiennent une kyrielle de helpers; c’est une dépendance acceptable et même conseillée

pour ne pas dupliquer de code.

Peu importe le langage

Que vous écriviez en langage C++ ou en langage C, il est toujours possible de modulariser.

Évidemment, c’est plus flagrant en C++ avec le concept des classes, mais constatez ces

analogies importantes :

Langage C++ Langage C

Classe Structure (struct) de contexte

Méthode publique Fonction (déclarée dans l’entête .h) qui prend au moins un pointeur vers une structure de contexte comme paramètre

Méthode privée Fonction déclarée statique (seulement dans le fichier .c) qui prend au moins un pointeur vers une structure de contexte comme paramètre

Attribut statique public Variable globale (déclarée extern dans l’entête .h et définie dans le fichier .c)

Attribut statique privé Variable globale déclarée statique (seulement dans le fichier .c)

Patrons (templates) Dupliquer les fonctions à la main en faisant attention ou abuser du préprocesseur

D’autres concepts plus propres à la programmation orientée objet sont également possibles en

langage C, mais plus obscurs (héritage en incluant une structure comme attribut d’une autre ou

polymorphisme en créant ses propres tables virtuelles).

Dans tous les cas, on ne devrait pas retrouver des dizaines de variables globales un peu

partout dans le code produit. Chaque fois qu’il y a un contexte, une structure ou une classe doit



être pensée, conçue et utilisée. Imaginez toujours que vous pourriez avoir plusieurs instances

de chaque module (et même du projet au complet!).

Exemples de modules

Voici quelques exemples de modules envisageables. Pour tous ceux-ci, nous imaginons une

seule classe (une seule paire de fichiers indépendants, mis à part certaines fonctions générales

externes utiles ou une composition nécessaire) :

accès à chaque périphérique (un module par accès); on pense aux entrées utilisateur,

aux sorties, à AC’97, à la sortie vidéo, etc.;

décodage Bitmap et découpage dans une image;

chaque décodage des différents formats de fichiers textes (skin_spec.txt, liste de

listes, M3U);

gestion HTTP (synthèse de requêtes, analyse d’entêtes des réponses, séparation du

corps et de l’entête, etc.);

cache de fichiers MP3;

gestion de l’affichage;

lecteur (l’état du projet au complet);

liste de lecture;

entrée dans une liste de lecture;

formatage de chaines (temps au format mm:ss, etc.);

mathématiques liées aux traitements audio.

Il n’y a pas de raison, par exemple, que les algorithmes permettant la gestion du protocole

HTTP soient entremêlés d’appels à la librairie lwIP et vice versa, ni que le décodage Bitmap et

le découpage d’images se fasse à même le décodage d’un habillage en même temps que celui

de skin_spec.txt.

Si vous misez dès le départ, en équipe, sur un bon design de modules, la division de tâches

deviendra très évidente et votre code sera totalement réutilisable, un must dans la communauté

des sources libres.

Truc pour modulariser

TV4K propose, par expérience de son département de recherche et développement en

informatique, la technique suivante pour achever une modularisation exemplaire.

Pour chaque module supposé indépendant identifié dans le problème, développez et testez les

classes/fonctions dans des projets indépendants d’Eclipse CDT ou de Visual Studio sur un PC.

En effet, il n’est pas nécessaire de développer les modules dans Xilinx SDK si ceux-ci sont

supposés être découplés du reste du projet. En développant dans un IDE indépendant, vous

serez naturellement assurés que votre code est réutilisable et qu’il est assez portable pour ne

pas dépendre de composantes spécifiques à Xilinx.



Contenu des livrables

TV4K demande deux phases de développement, chacune aboutissant à un livrable fonctionnel

selon les critères explicités dans cette section des exigences techniques.

Livrable 1

Pour le livrable 1, évalué le vendredi 29 mars 2013, TV4K s’attend aux fonctionnalités

suivantes :

gestion complète de l’habillage, mais sans action :

o décodage de skin_spec.txt et d’une image d’habillage;

o focus sur les quatre divisions;

o focus sur tous les contrôles individuels :

o déplacement d’un contrôle à l’autre et d’une division à l’autre avec les boutons :

lorsqu’un contrôle a le focus, afficher son ID avec les 16 caractères

disponibles sur l’afficheur LCD;

o aucune chaine de texte (ne pas implémenter l’intérieur de la liste de lecture);

intégration de libmad

téléchargement, puis décodage et lecture (simultanée au décodage) d’un seul fichier

MP3, ce qui implique :

o aucune liste de lecture à implémenter;

o le nom du fichier MP3 à télécharger peut être écrit directement dans le code

source;

o pas de mode « pause » à gérer : téléchargement puis lecture immédiate;

o pas de mise à jour du temps, de l’icone de statut ou de la barre de progrès de

lecture dans la division player;

o affichage de la progression en pourcentage sur la première ligne de l’afficheur

LCD pendant le téléchargement;

fonction mute;

fonction hold.

Livrable 2

Au livrable 2, évalué le mardi 16 avril 2013, vous devez terminer le projet, ce qui implique, par

rapport au livrable 1 :

gestion complète de la liste de lecture :

o affichage de chaines de texte dans l’interface;

o téléchargement de la liste des listes et présentation du choix à l’utilisateur;

o chargement/enregistrement d’une liste spécifique;

o modification de la liste en cours (déplacement/suppression d’items);

actions de tous les contrôles de l’interface et des boutons lorsque la division live a le

focus;

tout le traitement audio;

spectrogramme.



Aspects complémentaires

Le serveur de test est Jupiter, à l’adresse IP 132.207.89.2 pour les Genesys. Ceci signifie, par

exemple, que l’URL de la liste des listes de lecture est, du point de vue d’une carte de

développement :

http://132.207.89.2/lol

Le serveur de test écoute sur le port TCP standard du protocole HTTP. L’interface Web du

serveur LMNP est accessible à partir des postes de travail de développement par l’URL

http://jupiter.info.polymtl.ca/.

http://jupiter.info.polymtl.ca/

INF3990 : Projet de conception d un logiciel...

Documents

Transcript of INF3990 : Projet de conception d un logiciel...