A la base j’avais constaté une consommation CPU excessive lorsque XBMC affiche le menu : un minimum de 70% constaté via top en ssh (pour ne pas utiliser l’interface graphique) lorsque le menu l’accueil est affiché. La faq* de raspbmc souligne qu’utiliser XBMC pour afficher le taux CPU ( avec un bargraphe) serait justement la cause d’une surcharge.
Ce que je ne comprends pas c’est ce « plein régime sur cet écran justement, quand d’autres écrans comme la sélection d’un épisodes lui reste en dessous de 50%.
Quelle sont les traitements particuliers du menu d’accueil, le logo XBMC ?, l’effet de brouillard qu’il y a autour du logo ?
J’utilise le thème quartz, visiblement dénudé pour minimiser la consommation sur le raspberry.
On m’a proposé d’essayer d’overclocker la CPU avec raspi-config***. Seulement je n’ai pas cet utilitaire dans raspbian. Mais XBMC propose lui-même ce tuning via le plugin dédié dans les menus extension->programme.
Je n’ai pas overclocké à fond ( mode fast ), mais rien n’a changé et je crois que cela ne changerait rien, j’ai l’impression que XBMC exécute un traitement aussi vite qu’il peut.
Une note de blog suggère de configurer XBMC pour utiliser un algorithme** de rafraîchissement optimisé ( dirty regions ), mais que cela ne suffit pas, il faut également paramétrer la synchronisation verticale sur « Pendant la lecture seulement ».
J’ai beau positionner le fichier et l’option, rien ne change je suis toujours à 100% sur le menu principal (mais ça descend).
J’ai alors tenté une mise à jour via le plugin raspbmc en sélectionnant la version Gotham,
mais au redémarrage grosse suprise : un son complètement brouillé s’est fait entendre, et pas d’audio sur la lecture d’un fichier. Et toujours 100% sur le menu.
J’ai alors utilisé rpi-update**** pour mettre à jour le système pour voir si cela le remet d’aplomb. Ca a marché, enfin j’ai maintenant des sons normaux sur la navigation dans les menus, et l’audio fonctionne sur la lecture d’un fichier.
Mais j’ai toujours 100% sur le menu d’accueil, et autour de 40% lorsque je fais de la lecture vidéo.
La température CPU affiche 60°C (commande /opt/vc/bin/vcgencmd measure_temp).
J’ai ensuite essayé de baisser le taux de rafraichissement a 50Hz et définit une résolution de 720p, mais sans résultat.
J’ai en dépit installé strace pour essayé de déterminer dans quoi xbmc passe son temps :
pi@raspbmc:~$ sudo strace -p 665 -q -c
% time seconds usecs/call calls errors syscall
—— ———– ———– ——— ——— —————-
60.40 0.164389 1 265764 clock_gettime
21.19 0.057657 6 10003 gettimeofday
15.55 0.042315 1 35205 ioctl
1.91 0.005208 1 10294 10002 read
0.90 0.002461 4 652 futex
0.05 0.000129 0 564 poll
0.00 0.000000 0 233 227 open
0.00 0.000000 0 6 close
0.00 0.000000 0 4 munmap
0.00 0.000000 0 282 _llseek
0.00 0.000000 0 30 nanosleep
0.00 0.000000 0 4 mmap2
0.00 0.000000 0 177 172 stat64
0.00 0.000000 0 5 fstat64
0.00 0.000000 0 2 getdents64
0.00 0.000000 0 2 fcntl64
—— ———– ———– ——— ——— —————-
100.00 0.272159 323227 10401 total
On voit que XBMC passe la majorité de son temps à .. récupérer la date, pour balancer ensuite des ioctl().
Si je relance strace sans les statistiques je constate un nombre d’appel important sur des read et des ioctl, outre les fonctions clock_gettime:
read(14, 0xbeb69730, 4112) = -1 EAGAIN (Resource temporarily unavailable)
read(13, 0xb6f05000, 4096) = -1 EAGAIN (Resource temporarily unavailable)
ioctl(11, 0x400cc404, 0xbeb6a7dc) = 0
ioctl(11, 0x400cc404, 0xbeb6a684) = 0
Il me reste encore le mode trace de xbmc.
* http://www.raspbmc.com/wiki/user/frequently-asked-questions/.
** http://stackoverflow.com/questions/14194111/dirty-regions-on-xbmc-on-raspberry-pi
*** http://elinux.org/RPi_raspi-config
**** https://github.com/Hexxeh/rpi-update
