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.
