Valeur différentes retournées par amixer et alsamixer, l'explication :

No, both are correct.  You are dreaming too much on the world unified
percentage representation smile

The percentage in amixer has nothing to do with dB level.
It's just the percentage of the raw value range of that mixer
element.  Thus showing 89% is correct.  It's 10% down from 100%
(1% is because of the resolution of the raw values).

Now, alsamixer shows the percentage in a different way.  It's
explained well in the source code (alsamixer/volume_mapping.c), but
not mentioned in the man page, unfortunately.

* The mapping is designed so that the position in the interval is proportional
* to the volume as a human ear would perceive it (i.e., the position is the
* cubic root of the linear sample multiplication factor).  For controls with
* a small range (24 dB or less), the mapping is linear in the dB values so
* that each step has the same size visually.  Only for controls without dB
* information, a linear mapping of the hardware volume register values is used
* (this is the same algorithm as used in the old alsamixer).

The percentage representation in alsamixer corresponds to this
mapping, thus it's neither dB nor linear percent.

EDIT : + https://gitorious.org/alsa/alsa-utils/source/34bb514b5fd1d6f91ba9a7b3a70b0ea0c6014250:alsamixer/volume_mapping.c#L64

Todo sur mon dump pour ne plus avoir le warning

Parait que ça va plus vite que ack
à tester

Hier j'ai eu droit à la maj android 4.4 "KitKat". Parmi les nouvelles features, on retrouve le "podometre like" exploitable avec l'application Moves par exemple.

Je trouve le concept super sympa, l'application compte les pas, detecte lorsqu'on a pris un transport, lorsqu'on s'est arrêté et fait des petits graphs de la journée.

Au niveau de la vie privée je ne sais pas ce que ça donne.. surement pas top, donc je ne vais la laisser tourner longtemps.

A quand une app open source qui fait ça ? et qui envoie les données vers son propre server... avec génération de map openstreetmap..!

Je viens de remarquer que même en idle, XBMC mange pas mal de CPU.. Une solution pourrait être de l'arrêter/le démarrer à la demande comme Nico a fait (https://github.com/Sispheor/StartXBMC), mais j'ai trouvé ce petit script qui est bien sexy. Grâce à une commande (tvservice) on peut savoir si la TV est allumé ou non!
à tester donc

!/bin/bash

on_mode="0x120009"
while [ 1 ]
do
status=tvservice -s | awk {'print $2'}
if [ $status == $on_mode ]
then
echo "Detected hdmi signal - Starting xbmc . . ."
sudo service xbmc start
fi
sleep 1
done

Edit : ça ne marche pas avec ma TV :-( le code reste inchangé, tant pis. Du coup j'ai créé une page web toute simple qui, lorsque je la visite, permet de lancer xbmc.

Outils en ligne de commande pour trouver ce qui occupe de la place, bien pratique

• https://www.modmypi.com/raspberry-pi-camera/pibow-raspberry-pi-camera-mount

Incroyable ce speed run