NO to software patents - come to brussels on 14 april

logo-tuxbox

Bonjour et bienvenue sur le site de Boxound, le jukebox libre sous Linux.

MAJ : 2003-09-06 18:45

Pour me joindre : adresse

logo_linux_user

Accueil Présentation Fabrication du boitier Capteur infra rouge la FAQ les liens

FAQ :

1 - Je trouve cette initiative intéressante mais n'est ce pas moins cher d'acheter une chaîne hifi qui intègre le support des mp3 ?

CJ : L'idée de base est de disposer d'un support dont la taille n'est limité que par "le portefeuille", en clair la taille de ton disque dur.

IT : faudrait prévoir un port USB aussi car j'ai entendu de nouveaux supports qui commencent à apparaître, format type porte clé et se branchant sur un port usb...

CJ : Si tu achètes un lecteur de CD supportant le MP3, tu seras limité à 650 voir 700MO de MP3 sur ton support. De plus, si ta philosophie du libre t'interdit d'utiliser le format MP3 car non libre et que tu préfères l'OGG, ton lecteur ne te servira à rien, car il n'est pas évolutif. Les solutions de baladeurs sont toujours limités par leur capacité mémoire. Néanmoins, rien n'empêche de prévoir le support de produits USB pour peu que les drivers existent déjà sous Linux.

IT : 5*700 si tu as la chance de disposer d'un chargeur 5 cd :)
Tu as regardé les projets de ce genre sur freshmeat ? avec la chaîne de recherche "jukebox" il y a trois projets qui apparaissent...

CJ : Le BoXound utilise autant que faire ce peu, des produits ouverts et libres. Ce choix garanti l'interopérabilité du BoXound et son évolutivité. De plus, rien n'empéche de le faire évoluer dans un second temps vers un lecteur Divx ou DVD. Tout ceci me direz vous correspond à un pc classique. Je vous répondrai oui, mais....
- BoXound ne possède pas d'écran mais un afficheur LCD
- BoXound ne possède pas de clavier mais une télécommande infrarouge et quelques touches comme pour une chaine hifi
- BoXound sera plus silencieux qu'un PC

IT : Tu peux aussi mettre plusieurs cartes son pour permettre de brancher sur les enceintes de différentes pieces et mettre une carte réseau pour commander le lecteur mp3 par interface web et puis pourquoi pas du streaming aussi ... enfin les possibilités sont vastes... en tout cas je suis a priori intéressé par ce projet...

CJ : Quant au coût, c'est effectivement une bonne question qui mérite réflexion.

2 - Bruit du ventilateur :

http://www.materiel.net/details_EDEN-ESP800.html et http://www.ldlc.fr/fiche/PB00013670.html

JYB : Pas mal tout ça. Les défauts selon moi restent le bruit du ventilo et le temps que le système met à booter (à moins que l'apm/acpi soit parfaitement géré auquel cas on s'en fout).
Pour rester sur le MP3 (pas libre bwah caca) il y a la méthode ultra simple de ces jeunes gens : http://www.slimdevices.com/
Pas de support vorbis là-dessus puisque le décodeur libre de xiph utilise du calcul flottant (ils ont une version en fixed-point qu'ils vendent). Si une version fixed-point libre du décodeur pointe le bout de son nez un jour cela resoudra (grammaire ?) pas mal de problèmes pour ceux qui tentent de faire un support ogg vorbis sur riovolt ou archos jukebox (et même iPod). (Tout ceci modulo le fait que ce soit déjà fait et que je ne soit pas au courant)

CG : Le ventilateur est un éternel problème mais si on choisit de ne pas prendre un processeur trop puissant, il a moins besoin d'être refroidi. Si le disque dur n'est pas très rapide, il chauffera moins et donc des ventilateurs ne seront pas nécessaires.
Donc en fait, il faut prendre juste assez puissant pour faire ce qu'on veut et on devrait trouver un équilibre entre bruit/puissance.

CJ : Tout a fait d'accord. J'ai ouïe dire que certaines cartes mères permettent de diminuer la fréquence du processeur et donc son échauffement ce qui permettrait de supprimer le ventilateur non?

AF : heuu ... les cpu qui ne nécessitaient pas de ventilateurs, c'étaient les 486 (et encore ...). je doute que les générations suivantes puissent tourner très longtemps sans aucun ventilateur.

GG : Hé bien les C3 (le processeur de VIA, pas la voiture de Citroën) peuvent tourner sans ventilateur, avec juste un bon radiateur.

CJ : Je m'aperçois que je n'étais pas assez clair. Je parlais de supprimer le ventilateur, source de nuisance sonore, mais en aucun cas le radiateur, car depuis la fin de 486, la dissipation thermique est telle que le radiateur et la pâte thermique sont obligatoires. Les ventilateurs ont été ajoutés sur les radiateurs pour augmenter les performances de ceux-ci sans en augmenter la taille, quoique pour le P4....
Certains processeurs offrant de bonne performances ne nécessitent aucun ventilateurs, voir même radiateur car leur consommation et par voie de conséquence dissipation est très faible (<5W pour le StrongArm) contre 60W!!! il me semble pour les P4.

VM : Pour le MIPS équipant mon EasyMate 800 sous WinCE, c'est 0,25 W !!!!! A propos, j'ai un noyau Linux qui tourne dessus, avec support de la console, pour ceux que ça intéresse. Seul inconvénient majeur, il ne gère pas le bouton de StandBy => le pingouin tourne jusqu'à extintion des feux (batterie à plat) ce qui n'est pas pratique en usage nomade. Je n'ai pas eu le temps de me pencher dessus depuis de nombreux mois ...

KS : J'avais monté un lecteur MP3 avec un Compaq Deskpro P75 et 8 Mo de RAM. A l'usage, je me suis rendu compte que c'était le CDROM qui faisait vraiment beaucoup trop de bruit. D'un côté on ne peut pas se passer de leur super-vitesse, mais le bruit, c'est vraiment chiant quand on écoute de la musique...
Cependant, vous pouvez regarder si votre lecteur de CDROM répond aux IOCTL de changement de vitesse (c'est vrai pour un graveur, c'est vrai pour un lecteur SCSI, mais les firmware pour lecteur IDE n'ont pas l'air de tenir compte de cette command. En effet, SONY que j'avais monté dans la station, ce n'était pas le cas...).
Si vous êtes partant pour un tel projet, je suis des votre pour vous offrir mon expérience (et mes sources qui sont GNU mais qui sont seulement sur mon disque) dans ce domaine bien que n'ayant pas le temps de m'y consacré pleinement.

Autres questions en vrac :

OP : Au-delà des considérations de coût et de place, il faudra aussi bien penser au fonctionnement effectif de la solution : l'infra-rouge est supporté par GNU/Linux, mais pas tous les chips (du moins je pense).

CJ : De toute façon, la gestion infra rouge demandera de jouer du fer à souder, donc on peut choisir le chipset en fonction de ce que l'on recherche (fréquence, format, sensibilité....) créer le typon, puis le diffuser sur un site. Voir même reprendre une solution libre déjà existante

OP : Certaines cartes embarquent de l'infra-rouge par défaut. Ca peut être une solution intéressante (perso, j'ai rien contre le fer à souder, j'en ai même un à deux mètres cinquante, mais c'est pas trop user-friendly...).

CJ : Les cartes intégrant l'IR utilise quel type de protocole, avec quelle porteuse... et le plus important est-ce compatible avec une télécommande?

OP : L'IR est standardisé, le IR-Howto explique ceci (et même comment utiliser un port série pour faire joujou avec ça...).

OP : Comment les applis récupèrent _automatiquement_ les commandes de l'utilisateur (de la conf' en perspective) ?

CJ : Il y aura une interface homme machine à concevoir, c'est certain, avec quel langage (objet ou pas) autant de questions qui sont en suspens pour l'instant car j'en suis simplement à la phase réflexion, grande idée et recherche sur le net.

OP : Avant de développer, il faudra voir très sérieusement si des applis n'ont pas déjà ce genre de chose intégrée, ou si certaines pouvaient être patchées plus simplement que d'autres. Quand à une ihm, avec un module lcd, autant avoir du mode texte et un bon "pilote d'écran". Je sais pas si des graphismes apporteront tant de confort. En plus, l'intéret du mode texte, c'est qu'on peut scripter beaucoup de choses et faire des moulinettes en perl ou shell....

CJ : Le graphisme n'est intéressant que dans le cadre d'un bargraph, autrement le texte est bien suffisant (nom artise, nom album, nom du morceau et sa durée)
Le perl a déjà été utilisé dans un projet similaire

OP : Il y aura donc peut-être une base de départ.

OP : Quelle sera la méthode pour ajouter des données (CD audio / CD de mp3/ CD d'ogg / moulinettes automatiques pour n'avoir que des formats ogg (car libre) au final) ?

CJ : Pour le proto : par réseau tout simplement avec un partage NFS Par la suite, cela dépendra du produit final avec lecteur CD, on peut prévoir une moulinette de conversion type GRIP mais c'est assez gourmand en resource et ça fait chauffer le silicium.... Si pas de lecteur pour cause d'encombrement, ou de chaleur, on peut voir du coté de l'usb. Malgrè tout la solution du réseau est assez sympa car elle permet en plus une diffusion du son vers divers autres machines.

> Pour le proto : par réseau tout simplement avec un partage NFS

OP : Arrggghhhh ! C'est toujours contexte troll ? :)
C'est effectivement une solution, mais certainement pas la plus simple. On risque de plus se faire c#ier pour faire fonctionner le proto en NFS (rien que la config, c'est coton, avec un écran lcd, ca va être terrible) que d'implémenter direct un truc "mieux" et "simple" (si c'est un proto, on met un lecteur cd, et on lit ce qu'il y a dessus ???).

CJ : Bon un serveur FTP? car le BoXound est le serveur NFS sur lequel on vient mettre les morceau et n'est pas le client car trop casse co####e.

OP : Mouuuuais ! Le "problème" est la disponibilité d'un accés réseau (c'est pas simple, ni possible chez tout le monde) mais aussi la sécurité. Tout le monde peut lire/écrire ???

> Par la suite, cela dépendra du produit final avec lecteur Cd, on peut prévoir une moulinette de conversion type GRIP mais c'est assez gourmand en resource et ça fait chauffer le silicium....

Il y aura de la ressource cpu, même avec un celeron 400. En plus, il n'aura que ça à faire, et la charge CPU dépend aussi de vers quoi on veut faire la convertion (un système "presque complexe" mais efficace serait de transformer en une cible A, qui demande peu de ressource (man cp), et avoir un truc qui, lors de la 1ere _vraie_ lecture en profite pour faire la transfo vers la cible finale tout en jouant. Ca demande du script, mais c'est jouable (sans jeu de mots)).

CJ : Va falloir que tu m'en parles plus de ce concept

OP : C'est (sauf erreur) une adaptation (de plus) de la théorie du moindre effort : on a deux espaces distincts :
- un où on positionne tout ce qui est configuré.
- un où on dispose les données nouvelles, en attendant de les positionner dans l'espace ci-dessus.
Plutôt que de tout configurer directement, on le fait "quand c'est nécessaire". Ainsi, on extrait les cd audio vite fait, en wav (cdda2wav, il y a peut-être d'autres solutions) et quand on joue pour la première fois, les concepteurs auront pensé à utiliser un logiciel qui sait jouer du wav (pour cette fois) tout en convertissant en ogg (pour la suite). Le fichier ogg est alors placé "où il faut" et le wav subit un "rm" assassin, gnark gnark gnark...

>Si pas de lecteur pour cause d'encombrement, ou de chaleur, on peut voir du coté de l'usb. Malgrè tout la solution du réseau est assez sympa car elle permet en plus une diffusion du son vers divers autres machines.

OP : Le problème, c'est que tout le monde n'a pas de réseau à la maison. Pour un proto, ça va, mais pour un usage plus généraliste, c'est pas super...

CJ : Mouais, sur ce coup là, tu as raison

OP : Comment migrer quand on change de disque dur (c'est moins urgent, je suis d'accord) ?

Cj : Bonne question pour le produit final, pour l'instant c'est au stade du hack, mais ce point doit être pris en considération.

OP : le système aura besoin de temps pour booter, comment le gérer vis-à-vis de l'utilisateur (ça doit rester court).

CJ : Très bonne question : un amateur pour développer un bios ;c)))) ou encore plus trollesque qui veut participer au developpement d'une carte mère avec un processeur type strongarm avec gestion d'un réseau 10/100, d'une carte son, d'IR, d'un afficheur LCD, d'un DD ...... mais c'est moins évolutif. Plus conceptuel, j'ai trouvé sur internet quelqu'un qui boote en 15s son lecteur, c'est qu'il y à surement des possibilités.

> Très bonne question : un amateur pour développer un bios ;c))))

OP : Confirmé : ça trolle dur ce soir.

> ou encore plus trollesque qui veut participer au développement d'une carte mère avec un processeur type strongarm avec gestion d'un réseau 10/100, d'une carte son, d'IR, d'un afficheur LCD, d'un DD ...... mais c'est moins évolutif

OP : Mais si c'est fait, ça devient le "standard". En fait, le système doit ressembler à une appliance (aka boite noire) du coup ceci ne poserait pas de problème, si ce n'est le coût de développement (je n'ai pas chiffré, mais c'est au-dessus de nos moyens, me semble-t-il).

CJ : Et un projet pour supelec ;c))  non c'est trop troll.....

OP : Si tu as les entrées pour proposer ça, ce serait parfait.

> Plus conceptuel, j'ai trouvé sur internet quelqu'un qui boote en 15s son lecteur, c'est qu'il y à surement des possibilités.

Un noyau ultra-light avec des options de bios pour booter rapidement, ça peut le faire. Ceci dit, ma chaine s'allume en une seconde (au plus) on n'est donc pas vraiment dans les mêmes ordres de grandeur (aïe aïe !!!).

OP : le système devra être robuste pour résister à des reboot intempestifs (fsck risque d'être exclus cf ci-dessus).

CJ : Pour résoudre ce problème, il existe plusieurs solutions :
- les systèmes journalisés (ext3 par exemple)
- les montages de partition en RO
- une alimentation maintenant une tension le temps nécessaire aux bon démontage des partitions.

OP : Je pensais à une coupure de courant, par exemple... ce qui est plus problématique à bien de égards que la simple intégrité des données d'un système bien traité.
> Pour résoudre ce problème, il existe plusieurs solutions :
> - les systèmes journalisés (ext3 par exemple)

OP : Est-ce suffisant ?

> - les montages de partition en RO

OP : Ca, c'est sport! Bravo! Je reviens pas sur le thread de septembre sur la ml à propos de la possibilité de mettre une partition /etc en dehors de / mais c'est très très chaud. Certaines partie peuvent facilement être mises en RO, mais il faudra voir jusqu'où on peut aller...

CJ : Comme ça en lecture seule:  /boot,  /bin,  /dev car le système est figé,  /etc,  /home/mp3  répertoire en lecture seule, sauf en cas de copie,  /initrd ?????,  /lib,  /opt,  /root,  /sbin,  /usr et en Lecture écriture :  /mnt (mais rarement utilisé),  /proc est un répertoire virtuel,  /tmp (avec une purge à charge redémarrage),  /var pour cause de fichier log.
Donc à partir de là on pourrait créer plusieurs partitions en fonction du type d'accès.

> Comme ça en lecture seule: /boot
OP : On peut mettre son contenu à la racine...
> /bin
> /dev car le système est figé

Oooops !!! Kernel panic garanti : c'est pas parce que tu n'y as pas accès direct que c'est pareil pour tout le monde : les périphériques ont _besoin_ d'écrire. Par contre, un truc avec devfs serait élégant.
> /etc
> /home/mp3  répertoire en lecture seule, sauf en cas de copie

Là, c'est l'usine à gaz pour le gérer (surtout avec le réseau : on écrit quand on veut). On peut le mettre en lecture/écriture, avec de l'ext3, et une synchro du journal toutes les secondes.
>/initrd ?????
N'existera (probablement) pas.
> /lib
Et si on compilait en statique ?
> /opt
rm -Rf /opt
> /root
Pas besoin : root sera localisé comme il faut, ie dans / !!!
> /sbin
> /usr

Pour /usr, si on fait un truc "custom", je propose sa disparition pure et simple : les outils système dans /sbin, le reste dans /bin (c'est comme ça sur toutes les mini distribs, il y en a même qui suppriment /sbin).
> Lecture écriture : /mnt (mais rarement utilisé)
N'existera pas.
> /proc est un répertoire virtuel
> /tmp (avec une purge à chaque redémarage)

Ca (la purge) c'est dans les scripts d'init, le "problème" peut être contourné. Une super solution pour le faire est la suivante (attention, j'espère que tu n'es pas en train de digérer) : on créé un ramdisk, on le monte en tant que /tmp. Il faudra "juste" penser à un formatage (mais bon, ça fera dans les 50~70 Mo). Avantage : beaucoup beaucoup plus de rapidité. Par contre, il faudra de la ram.... mais ce n'est plus très cher.
> /var pour cause de fichier log
Il n'y aura vraissemblablement pas de logs...

> - une alimentation maintenant une tension le temps nécessaire aux bon démontage des partitions.

OP : Trop cher. En fait, ça revient à mettre un onduleur. Et puis très sensible à l'usure.

OP : <troll> on prend une distrib, ou on utilise Linux From Scratch, on compile, et on sort une image iso auto-installable ? </troll>

CJ : Dans un premier temps, je m'avoue incapable de me faire une LFS, et je me verrait assez bien partir sur une base debian épurée, pour finir par une LFS c'est plus fun ;c))

OP : Pour ça, je me demande même si une slackware, ou une mini-distrib reconfigurée ne serait pas le top. Même avec debian, il y aurait beaucoup de ménage à faire. On pourrait faire deux versions :
- BoXound "slack" pour les pères de familles.
- BoXound LFS pour les geeks. :)