Car je ne veux pas critiquer les devs du pingouin mécanique, mais y'a du réellement vaudou là dessous... Je suis pas sur d'avoir bien compris... En fait pour stocker N sons dans le tux, il faut (attention, on s'accroche) :

1. Lire le "sample rate" de chaque fichier audio. Information contenue dans le header du fichier wav (qui est constitué de 44 octets), sur 4 octets, en position 24.
2. Si le sample rate n'est pas très exactement de 8khz, il faut convertir le sample avec la commande sox source.wav -c 1 -r 8000 -b cible.wav.
3. Il faut ensuite regarder en position 40, la taille de la "charge utile" codé sur 4 octets. Chose étrange, le chiffre est inférieur à la réalité, c'est à dire tailleFichier-44.
4. Ensuite il faut merger tous les wav's en un seul. Pour cela, on récupère le header du premier wave, sauf la taille (40 octets donc, faut suivre . On réserver 4 octets (pour la futur taille) et on ajoute à la queue leu-leu tes charges utiles (tout sauf les 44 premiers octets) de chacun des samples.
5. Et là commence le vaudou, le naïf aurait pu croire qu'il faille insérer la taille avec la somme de toutes les tailles... Oui mais non... En fait il faut insérer tailleDansHeader=sommeTailles+0.07*sommeTailles (au petits malin qui veulent factoriser, je rappelle que l'on est en arithmétique entière . Pourquoi .07 ? aucune idée...
6. Bref, on insère la valeur ainsi trouvée et on se dit c'est fini. Ben non, car tant que la taille physique du fichier est inférieur à tailleDansHeader-44, on ajoute 12 espaces à la suite des données !!!
7. C'est pas fini, il faut ensuite réinitialiser la mémoire du tux, pour cela, on s'accroche, il faut d'abord envoyer la commande qui indique au Droid le nombre de sample qui vont arriver.
8. On attends 10 secondes !!!
9. On envoi à Tux un premier index en 0x400... Pourquoi, je sais pas, c'est comme si on définissant un premier sample "blanc"
10. Puis on envoi les N indexes suivant, en incrémentant à chaque fois avant de la taille (la vraie, celle du header d'origine) du sample en prenant bien soin de faire une pause de 100ms entre chaque envois...
11. Enfin, pour ceux qui se demandaient comment envoyer les données elles-même au Tux, ben c'est tout con, on envoi notre super WAV précédemment fusionné... dans la carte son USB avec un aplay -D hw:0,0 merged.wav...

J'avoue que je ne m'attendait pas à un truc aussi délirant.. Je subodore que le coup de 0.07 et du padding avec des espaces à la fin permet au firmware de comprendre qu'il doit arrêter de stocker...
Peu importe, aidé du code python de l'API d'origine et de celui de tuxgi, on y arrive. Mais serieux, c'est pas clair du tout à lire le Python...

En tout cas pour ceux qui veulent savoir comment la même chose peut maintenant être réalisée en Java :

C'est sur, une fois que le gros est caché dans l'API, c'est plus simple A noter que l'objet WaveFile converti tout seul les samples au bon format.

Ban ben vala, je suis content, j'ai saoulé tout le monde, je vais me coucher