DAPI

[Tutut]

Tu peux aussi utiliser la sortie composite, le connecteur d'extension est un 26 points et non 40.

Un article qui donne les bases pour l'écran :

http://binerry.de/post/25787954149/pcd8 ... spberry-pi

[fpp]

Hey, mais ya déjà les boutons sur l'écran, c'est génial !
J'achète ! Ca a l'air super pratique. Par contre, puisque tu l'as acheté, c'est une nappe IDE 40 broches non? Ca veut dire que le GPIO est du 40 broches? Histoire de connaître la compatibilité.
Et comment l'écran+boutons discutent? Quelle interface soft ils utilisent? Norme IDE ou ce qu'on veut? Si quelqu'un sait, ça serait super cool.

Non, rien à voir avec l'IDE, ça ressemble aux nappes des (très) anciens disques durs, mais c'est juste un ruban avec des connecteurs au bout pour se connecter sur la barrette GPIO du Pi. Il y a bien moins de broches.
Pour le protocole je ne connais pas bien mais c'est du très basique. Généralement c'est une bibliothèque en C spécifique à l'écran ou au type d'écran.
L'intérêt (pour moi) de celui-ci c'est qu'il a aussi une interface en Python.

[fpp]

1) faire marcher le son tout court sur la raspbian et vérifier que c'est mieux qu'un DAP actuel moyen, sinon c'est même pas la peine de continuer, n'est-ce pas? C'est-à-dire lancer VLC ou autre dessus hein.
2) Faire fonctionner le transfert synchrone/asynchrone en USB 16 bits/24 bits/chaipascombiendehertz via drivers USB, sans crack ni pop de jitter
3) Résoudre les interfaces homme machine : écran, puis les boutons
4) Playback du son : soft à coder en python avec gestion de l'écran en X ou en term tty, boutons en termcap ou en X, ergonomie à coder, utilisation des bibliothèques de décodage du son + tag ID3 et compagnie
5) Gestion de la batterie de type Li-ion ou LiFePO4 + rechargement
6) Choix de l'enclosure + form factor + finition

Je pense que tu as bien résumé les principaux points et dans le bon ordre, mis à part le 1) dont je ne vois pas l'intérêt (ou alors j'ai pas compris ce que tu voulais dire).
Pour 4) il y a diverses options. Certes on doit pouvoir tout faire de A à Z en Python, mais bonjour le boulot.
Dans un des liens que j'ai cités au début on voit la possibilité de faire tourner un "player" éprouvé (moc) en arrière-plan, et de simplement le piloter via une API Python. Du coup il ne reste plus "que" l'interface en mode texte adaptée à l'écran et aux boutons, c'est déjà moins Dantesque...

[fpp]

Merde le boulet, c'est pas celui-là... mais celui-là que tu peux acheter là

Holà Vic, quel drôle de choix ?!
Autant je comprenais celui du emsystech, autant celui-ci...
Certes il est pas cher mais tout rikiki aussi (tu vas faire tenir 7 lignes là-dedans ? :-)
Aussi, bonjour le travail d'intégration, de câblage, etc. Et j'ai pas vu de trace d'interface Python ou autre chose que C ?

Le emsystech est tout packagé au format exact du Pi, prêt à brancher sur le GPIO, boutons compris, et bien supporté côté soft.
Ça m'étonnerait qu'il consomme énormément plus, ça reste du monochrome.

Certes il coûte plus cher que le Pi lui-même, c'est son principal défaut... mais à mon avis 30€ pour le temps, l'énervement et les emm* qu'il ferait gagner, c'est donné :-)

[raf]

Merci fpp. Pour le point 1, c'est parce-que je n'ai jamais eu de RPI sous la main, et que j'ai envie de verifier, en faisant tourner la bete avec un DAC/amp connecte en USB si ca donne quelque-chose de bien en sortie. Car je suis tombe sur de nombreux posts ou ils parlaient de problemes avec l'USB. Mais apparemment, certains ont trouve une astuce pour y pallier (cf raspyfi). Ca serait mieux si on part de cette distrib alors on dirait.
Si on doit coder en C, pas de problemes, j'ai deja fait (mais faudra que je me remette a niveau, ca fait des annees que j'ai pas code).

[Vic]

Merde le boulet, c'est pas celui-là... mais celui-là que tu peux acheter là

Holà Vic, quel drôle de choix ?!
Autant je comprenais celui du emsystech, autant celui-ci...
Certes il est pas cher mais tout rikiki aussi (tu vas faire tenir 7 lignes là-dedans ? :-)
Aussi, bonjour le travail d'intégration, de câblage, etc. Et j'ai pas vu de trace d'interface Python ou autre chose que C ?

Le emsystech est tout packagé au format exact du Pi, prêt à brancher sur le GPIO, boutons compris, et bien supporté côté soft.
Ça m'étonnerait qu'il consomme énormément plus, ça reste du monochrome.

Certes il coûte plus cher que le Pi lui-même, c'est son principal défaut... mais à mon avis 30€ pour le temps, l'énervement et les emm* qu'il ferait gagner, c'est donné :-)

Oui tu as raison, c'était l'idée saugrenue d'Ony, et une question de budget ainsi que de positionnement des boutons. Mais hormis les sondages à effectuer en plus, ça revient pas au même niveau soft ?

[raf]

Y-a-t-il un gentil modo qui peut regrouper toutes les infos dans le premier post ? Ainsi que les tergiversations au niveau de l'écran + les liens d'informations d'implémentation. Histoire qu'on ait ça quelque part avant que le topic n'ait 50 pages.

Avoir les différents écrans permet de voir ce qui est le mieux (soit budget, soit praticité etc).

Merci.

[Wardormeur]

Jdcjdr mais si y'a un wiki, c'pas pour rien
http://wiki.tellementnomade.org/doku.ph ... rry_pi_mod

[raf]

Je connaissais pas. Bon ben, je sais ce qu'il me reste à faire

[Wardormeur]

Pour information, la 1ere page recupere le contenu du wiki : si le wiki est modifiée, la 1ere page l'est aussi

[manwalk]

Si ça c'est pas du talent

[fpp]

Merci fpp. Pour le point 1, c'est parce-que je n'ai jamais eu de RPI sous la main, et que j'ai envie de verifier, en faisant tourner la bete avec un DAC/amp connecte en USB si ca donne quelque-chose de bien en sortie.

OK, c'est donc bien que c'était pas clair :-)
Car pour moi ce que tu décris là relève de l'étape 2 dans ton message.
Du coup j'ai interprété l'étape 1 ("faire marcher le son tout court") comme "brancher un casque sur la prise jack du Pi et vérifier la qualité", ce qui me semblait sans intérêt dans le contexte du projet.
Reste que je ne suis toujours pas au clair sur la différence que tu fais entre l'étape 1 et l'étape 2 :-)

[fpp]

Oui tu as raison, c'était l'idée saugrenue d'Ony, et une question de budget ainsi que de positionnement des boutons. Mais hormis les sondages à effectuer en plus, ça revient pas au même niveau soft ?

Sais pas, pas plus enquêté que ça.
Mais justement pour le emsystech c'est clairement indiqué sur la page sans avoir à chercher (C et Python), pour l'autre je n'ai rien vu de tel.

Perso je n'ai plus touché au C depuis au moins 15 ans que je fais du Python, et il n'est pas question que je m'y remette :-)

[fpp]

Pour information, la 1ere page recupere le contenu du wiki : si le wiki est modifiée, la 1ere page l'est aussi

Ah, j'avais pas capté ça, excellent !
J'avais bien vu au tout début du topic que la page Wiki avait le même contenu que le premier post, mais j'ai pensé à un copier/coller :-)

Au passage, il y a DEUX pages Wiki sur ce sujet, dont une obsolète peut-être à supprimer :
http://wiki.tellementnomade.org/doku.ph ... rry-pi-dap

[fpp]

1) faire marcher le son tout court sur la raspbian et vérifier que c'est mieux qu'un DAP actuel moyen, sinon c'est même pas la peine de continuer, n'est-ce pas? C'est-à-dire lancer VLC ou autre dessus hein.
2) Faire fonctionner le transfert synchrone/asynchrone en USB 16 bits/24 bits/chaipascombiendehertz via drivers USB, sans crack ni pop de jitter
3) Résoudre les interfaces homme machine : écran, puis les boutons
4) Playback du son : soft à coder en python avec gestion de l'écran en X ou en term tty, boutons en termcap ou en X, ergonomie à coder, utilisation des bibliothèques de décodage du son + tag ID3 et compagnie
5) Gestion de la batterie de type Li-ion ou LiFePO4 + rechargement
6) Choix de l'enclosure + form factor + finition

A la réflexion, s'il se vérifie que 1) et 2) sont redondants ou à fusionner, je rajouterais bien un point supplémentaire quelque part avant le 5, suite à une remarque que j'ai faite il y a quelque jours :

X) déterminer le temps de démarrage de la solution hard+soft (de l'allumage jusqu'à la reprise du morceau précédemment en cours)
- en déduire si le DAPi peut fonctionner commodément en on/off au quotidien (comme un Clip par exemple) ou s'il doit rester en veille la plupart du temps (comme un smartphone par exemple)
- le cas échéant, évaluer l'impact sur l'autonomie et le dimensionnement de la batterie :-)