Sujet: Quelques infos par rapport aux évolutions du firmware...

[MiKe]

Quelques infos par rapport aux évolutions du firmware...

La version 1.0.0 livrée le 28/02 comportait quelques bugs complémentaires liés au signal vidéo : sur la scart, l'image était "toute verte". Les devs de DUOLABS l'ont très vite constaté par eux même et ont corrigé le tir sur cette nouvelle version (c'est d'ailleurs la motivation principale de cette livraison).

Globalement, les retours que Doume ou moi leur avons fait ont été pris en compte, en particulier sur la partie fondation linux :

Le firm a été néttoyé des éléments superflus
A l'inverse, des éléments manquants ont été ajoutés

Le firm est donc plus compact (50 Mo environ sur la clef USB) et intègre les fonctions qui vont bien : bash en standard, VI fonctionne (ce n'était pas le cas), la coloration de l'affichage est activée dans busybox, les alias fondamentaux sont présents (ll....), le password est OK (il avait sauté aussi dans la version précédente).

Le support des lecteurs de cartes a été largement corrigé. Actuellement, il semble que les cartes NAGRA ne soient pas encore correctement supportées; Les devs livrent aujourd'hui une nouvelle mise à jours du firmware qui apportera peut etre une réponse à ce sujet. A minima, j'ai reçu hier un nouveau driver smartcard que je n'ai pas encore testé.

Côté zap, ENIGMA 2 bouffe tout le CPU de la bete. Ca pose de gros problèmes : lenteur de réaction à la télécommande notamment. Mais plus important : les autres process ont du mal à avoir du CPU, et ça génère des freeze d'images notamment en HD (Astra HD+ en clair).

Pourquoi ?

Parce que techniquement, tous les flux Audio/vidéo transitent par un process en mémoire (multi_feeder).

L'archi actuelle des drivers fonctionne suivant ce principe :

sur /dev/dvb/adapter0, on trouve les devices de SORTIE (video, pip, son, décryptage, demux liés à tous ces équipements) mais AUCUN TUNER.

sur /dev/dvb/adapter1, on trouve le tuner DVBS2 (un seul tuner supporté actuellement) avec son demux et un slot PVR pour enregistrer.

sur /dev/dvb/adapter2, on trouve le tuner TNT avec son demux et un slot PVR pour enregistrer.

Pour regarder le sat par exemple, l'OSD doit donc faire le tuning sur adapter1, configurer le demux d'adapter1 pour filtrer les PID vers le PVR associé...le flux filtré est donc dispo sur le PVR pour récupération.

Dans le meme temps, l'OSD va configurer le demux d'adapter0 pour qu'il route les packets vers chacun des décodeurs (audio, vidéo, teletext...). Mais ces packets n'arrivent de ... nulle part !

Le process multi_feeder doit ensuite recevoir une commande de bridging via une socket, pour lui dire de lire le flux présent sur adapter1/dvr et le réinjecter vers adapter0/dvr (en gros).

Le flux passe donc intégralement par la mémoire, et il faut du CPU pour le relayer.

Avec E2 qui boucle et pompe 100% du CPU, le multi_feeder a part moment trop peu de cycles CPU et il perd des paquets...donc perturbations image et son.

Cette architecture drivers ne satisfait pas Duolabs. Ils cherchent pour le moment simplement à la faire fonctionner correctement et, par la suite, il refondront l'intégralité des drivers pour gérer tout cela plus efficacement, mais pour l'heure ils n'ont pas la possibilité de tout refondre : c'est un projet plus long terme.

A préciser aussi : ST ne fourni plus le support du décryptage CSA en natif sur les CPU. Du coup, le décryptage est implémenté sur le FPGA intégré à la qbox. C'est en fait une très bonne chose : le fpga est très à l'aise à ce jeu.

Donc actuellement, le flux du tuner S2 est routé (en hardware) vers le fpga qui le décrypte intégralement, avant de le remonter vers les CPU.
Conséquence : le flux est totalement en clair au niveau demux, et donc le playback et le record sont bien sur des flux décrytpés.
Problème : le fpga actuel ne propose qu'un seul canal de décryptage. Donc on ne peut pas traiter plusieurs flux en meme temps. Sgroumf !

Tous ces points sont recensés chez Duolabs. Les solutions à terme sont actées : décryptage sur plusieurs slots dans le fpga, pour record / live des différents tuners, refonte des drivers pour éliminer le multi-feeder et la charge CPU inutile, etc etc...

Mais pour tout cela il faut du temps. Et donc actuellement, la QBOX HD, sur la base de ses drivers, n'exploite pas tout son potentiel matériel.

En gros, dans l'état actuel des choses, elle pourra utiliser un seul flux à un instant donné, donc pas de record sur le sat pendant qu'on regarde un flux tnt...en tout cas pas sans module pcmcia (dans ce cas la capacité de le faire dépend du module !).

Que penser alors de ce déco ?

Dualabs a clairement établi dans ses communications récentes :

Que le hard livré actuellement serait complété par la suite, avec une télécommande plus digne de ce nom (comme l'a fait DAGS pour les premier TGS100).

Que le wifi sera livré sous forme d'option (pas trop chere). Moi je m'en tappe : pas de wifi.

Que les drivers actuels sont de type BETA. Pour en discuter avec eux tous les jours, ils ont de bonnes idées pour la suite...mais qui dit idée ne dit pas nécessairement réalisation. C'est une question de "les croires ou pas".

Au quotidien, ils semblent réactifs. Il y a apparement une réelle volonté d'avancer. Ils sont à l'écoute.
J'ai suggéré à mon contact le montage d'un tracker : il a tout de suite été séduit. Ils l'utilisent (j'avais proposé la meme chose / fait la meme chose pour DAGS y a 3 ans, mais ils en ont jamais compris l'interret !)
Ce tracker est fermé / privé, mais Doume et moi y avons un compte pour y remonter des problèmes : ils les prennent en compte et les traitent. Si ça continu dans ce sens, c'est plutot encourageant.

En tout état de cause, comme tous les décos sur base ST qui annoncent Enigma 2 inside, la QBOX se heurte à l'absence d'une vraie couche de drivers compatibles Linux/DvbAPI, et Duolabs a du boulot pour arriver à un résultat, à cummuler aux inévitables problèmes de portage d'E2 sur autre chose qu'une DMM.

[caramel]

Salut Mike,


Merci pour ces infos, malheureusement cela confirme que Duolabs ne maitrise pas encore son produit.

D'après ce que tu as écrit il semblerait que Duolabs ne soit pas l'auteur du hard de la Q-BoxHD et qu'ils aient soustraité cette partie.

Bon je pense que Duolabs à du reprendre le taureau par les cornes et est entrain de se donner à fond pour nous sortir quelque chose qui tiendra la route.

Ce qui m'inquiète un peu c'est qu'ils vont livrer des Q-boxHD et je me demande comment ils vont faire pour reprogrammer le FPGA des versions livrés

Je suis assez impatient de m'en acheter une pour développer dessus mais pour le moment mettre 450 euro dans un matériel dont le hardware n'est pas fini me semble très risqué.

[MiKe]

Yop,

Concernant ces infos c'est AmadeusHF qui est l'auteur de cet excellent post.

Pour la partie hardware, je n'ai pas d'info à ce sujet, peut être que Doume ou AmadeusHF auront des choses à nous dire prochainement

[Doume]

A mon avis, le hardware est bien d'origine Duolabs (j'ignore si la fabrication est off-shore...)

C'est simplement conçu sur la base du chipset STMicro, mais avec une architecture Duolabs (ex : Diablocam embedded )

[jefjr]

Salut,

...
Je suis assez impatient de m'en acheter une pour développer dessus mais pour le moment mettre 450 euro dans un matériel dont le hardware n'est pas fini me semble très risqué.

J'étais également impatient mais je vais attendre que les principaux problèmes soient résolus.
J'espère avant la fin de l'année.

Merci à tous pour le retour d'infos.
@+

[AmadeusHF]

Le hardware est totalement maitrisé par Duolabs. Là n'est pas le problème. C'est leur hard et ils savent ce qu'ils en font.

Comme pour la plupart des (en fait TOUS LES) fabricants, ils savent faire du hard, mais ils pédalent dans la semoule dès qu'il faut faire du soft.

Prenons un peu de recul...

Sur les générations précédentes de chipset, les décos SD, on trouvait principalement des machines conçues sur une base de processeur IBM PowerPC 405 (la fameuse série des chipx STB 02500/03500/04500), qui équipent les DM de première génération jusqu'à la 7020.

IBM fourni avec sa license les sources complets de drivers unix compatibles LInux DVB API...même s'ils sont buggés, ils sont fournis. Donc les fabricant se la sont pété facile :
On fait notre hardware
On utilise les drivers d'IBM
On utilise le CDK Enigma 1

Avec tout ça, ils n'avaient pas trop à se casser la tete, mais du coup se sont aussi retrouvé piégés par les bugs des drivers d'une part, et d'E1 d'autre part : ils n'ont pas en interne de compétences SOFTWARE adaptées à de tels enjeux.

Nouvelle époque, nouvelle donne...IBM a jeté l'éponge pour cette génération de chipsets : ils n'ont pas d'équivalent à leurs fameux STB mais HD, H264, dual tuner...enfin tout ce qui fait qu'on peut vendre aujourd'hui. Donc ils ont annoncé à leurs clients qu'ils "reviendraient pour la prochaine génération" (Sarah Connor ? I'll be back !)

Du coup, tout le monde se tourne vers "autre chose". Le leader du marché actuellement c'est ST Microelectronics : ils ont de très bons chips, et ils ont la puissance de feu pour fournir du volume et noyauter tous les constructeurs...faut voir comment ils ont fait des pieds et des mains pour séduire les fabricants...

Mais ST ne fournie PAS l'équivalent de ce que fournissait IBM.

C'en est meme très loin !

Du coup, les marques se retrouvent "à devoir faire ce qu'elles ne faisaient pas"...à développer du soft, des drivers...sans en avoir les compétences ! Apprentissage sur le tas, cahotique, à la hussarde comme on dit.

Pareil coté dev alternatif : exit le CDK tout près, je checkout le CVS et ça compile ! Fini tout ça ! Ce genre d'environnement n'existe pas sur base de processeur SH4. Il faut assembler à la mimime tous les morceaux !

Tout cela explique la situation actuelle.

En dehors de DMM qui est parti sur du Mipsel sur Connexant, tous les challengers sont sur base STi 7109 ou ses dérivés...et donc logés à la même enseigne en ce qui concerne le soft.

La boite qui arrivera à proposer une vraie réponse en terme de drivers (réellement au points, réellement exploitables et qui bouffent pas 100% du CPU) compatibles API DVB...celle là aura fait un pas de géant vers le statut de concurrent sérieux de DMM.

Pour le moment, personne ne peut prétendre à ce titre...mais Duolabs semble avoir (à mon sens) une petite avance sur les autres.

[Macmaon]

Vraiment très chouette ton article.
Merci

[subsilver]

......mais Duolabs semble avoir (à mon sens) une petite avance sur les autres.

Salut,
Sans être aussi calé, n'étant qu'un simple utilisateur, mais ayant pas mal testé de terminaux, j'en arrive aussi à la même remarque, mais la route semble encore longue.   

[caramel]

Salut AmadeuxHF,

Si le problème de Duolabs c'est vraiment les compètences soft, pourquoi ne pas faire une section développement en ligne avec un accord de confidentialité par exemple ?

Perso je n'ai jamais vu un driver prendre 100% du cpu, pour moi ce n'est plus un driver à ce stade.

[Doume]

Perso je n'ai jamais vu un driver prendre 100% du cpu, pour moi ce n'est plus un driver à ce stade.

Ben moi, si, avec l'état actuel de la QBoXHD
Bon, c'est vrai, on peut pas appeler cela un driver....

Mais ils font tout pour y arriver

[AmadeusHF]

Si le problème de Duolabs c'est vraiment les compètences soft, pourquoi ne pas faire une section développement en ligne avec un accord de confidentialité par exemple ?

Avec quoi comme objectif ?

Et puis quel en serait l'interret pour Duolabs ? Eux comme les autres, ils ont besoin de maitriser leur produit. Et il n'existe pas de communauté à ce point structurée autour des décos sat pour mobiliser une énergie pour faire du soft : la plupart des personnes qui sont impliqués de manière très active sur le sujet sont payées par des marques pour le faire, donc ne sont pas là "par simple esprit communautaire". Un déco sat ce n'est pas Linux ou Firefox...et quand bien meme ça le serait, il ne faut pas oublier les entreprises qui cotisent sur les principaux projets OpenSource pour faire en sorte que ça avance...

[caramel]

L'objectif est très clair c'est de les aider au niveau soft puisque il semblerait, d'après vos dires,qu' ils ne maitrisent pas du tout cette partie.

Tu trouves cela normal toi (AmadeusHF), de faire tester des versions softs à des gens qui ne sont pas de Duolabs ? ils payent combien pour cela ? rien bien sur mais combien de temps vous y passer pour faire les tests que normalement les personnes payés sont censées faire.

Contrairement à ce que tu peux croire, il n'y a pas besoin de communauté structuré autour des décos pour faire du soft.

[subsilver]

....des gens qui ne sont pas de Duolabs ? .........combien de temps vous y passer pour faire les tests que normalement les personnes payés sont censées faire..

La passion tu connais  moi je passe minimum 4 à 5 heures par jour à tester, répondre, faire des copies écrans et tout ça pour quoi, pour le plaisir, pour aider les autres etc .. Et que ce soit Doumé, AmadeusHF, Mike, Nounours (pardon pour les autres) etc .. c'est tous pareil ont a des familles des jobs et tout ça sur le temps libre, on s'éclate. La récompense, c'est le plaisir de lire sur les forums, les gens contents, d'avoir la confiance de constructeur pour tester le matos, d'avoir des partenaires qui t'envoient aussi du matos etc .. Voilà comment ça marche.

 

[caramel]

Oui subsilver,

C'est exactement pour ca que je dis que  l'objectif c'est de les aider là ou ils ont des lacunes.

Maintenant je ne vois pas en quoi ce serait génant  pour Duolabs de fournir une partie des sources (notament la ou ils ont des soucis)  pour les aider, car de toute facon cela ne peut fonctionner qu'avec leur hardware.

Je crois quand même que l'interêt de Duolabs ou des autres socitétés d'ailleurs c'est de vendre un produit abouti et non pas un produit non fini comme c'est souvent malheureusement le cas pour les démos.

[subsilver]

...Duolabs de fournir une partie des sources (notament la ou ils ont des soucis)  pour les aider, car de toute facon ....

Salut, un truc que je ne comprend pas pourquoi tu ne vois pas avec eux directement ? Moi c'est ce que j'ai fait et je pense que pour AmadeusHF et Doumé c'est pareil, ..