Suite, mais pas fin, des aventures du Slampler !

Slampler monté - cc by-nc-sa

L'intégration du joystick au pédalier est terminée. L'ajout des pièces de tuyauterie en PVC, pour loger les interfaces, lui donne un petit air d'arme secrète soviétique. Déco à prévoir en conséquence.

Slampler monté - cc by-nc-sa

Le circuit imprimé du joystick n'était pas totalement détruit après ies premiers tests. Il restait 6 contacts opérationnels... juste assez pour y brancher tous les switchs. La leçon en est qu'il ne faut pas souder sur les pistes, qui se décollent, mais sur les points de soudure existants.

Composants du slampler - cc by-nc-sa

L'ensemble des composants a un peu de mal à rentrer, surtout à cause du long câble USB du joypad. Avantage, rien ne bouge à l'intérieur. Inconvénient, la place est maintenant terriblement comptée alors que j'envisage de remplacer l'atroce dongle C-sound par une interface Behringer UCA-202. Il faudra probablement déplier et insérer le câble à l'intérieur du tuyau des switchs pour gagner de la place.

Slampler assemblé - cc by-nc-sa

Le NSLU2 ne dispose que de 28 MiB de RAM. Combien de samples, de quelle longueur, peut-on loger ? En y stockant des samples mono sur deux octets à 44100 Hz, cela donne 88200 octets par seconde et 10 MiB permettent de loger 113 secondes, soit, pour 15 samples, 7 secondes en moyenne par sample.

Je dois largement dépasser cette taille car il y a parfois des trous dans la reproduction audio, probablement parce que le programme swappe un peu (4 MiB en swap après exécution) et que l'écriture est coûteuse sur une clef USB. Et puis il n'y a pas de secret, il faut réduire la taille des samples. La durée totale de mes samples actuels étant de 141 secondes, cela représente dans les 12 MiB en interne; il faudrait donc descendre à 8 MiB soit dans les 90 secondes. FAUX ! CF. infra. J'aurais aussi pu conserver les samples sur disque et les lire à la volée, ce qui serait concevable en n'en lisant qu'un seul à la fois, mais je voulais pouvoir en lire plusieurs en même temps.

Code du slampler en mode debug - cc by-nc-sa

Cela signifie aussi qu'il faut vraiment tuer les démons comme hald et udevd pour gagner quelques MiB en mémoire. Il ne sera alors plus possible de monter automatiquement une clef USB supplémentaire contenant les répertoires 0/, 1/ et 2/ allant se mettre par dessus ceux d'origine de /data, mais qu'elle ne peut être prise en compte qu'au boot.

Pour l'instant, on reste sur un déclenchement simple où le sample ne s'arrête pas avant la fin. Le choix se fera à la prochaine répétition... en janvier. Si cela change, l'architecture devrait aussi changer pour lire les samples directement depuis le disque puisqu'il sera alors assez difficile d'en déclencher plusieurs en gardant le pied appuyé...

Edit La situation est plus grave que ça. J'ai été intrigué par un core dump de 30 MiB. En me connectant en ssh au Slug pendant que ./slampler tournait, la commande top donne cette taille dans la colonne VIRT (mémoire virtuelle). Bref, le programme swappe à mort. Solutions :

  • Réduire encore plus drastiquement la taille des samples (mais c'est pas drôle) ;
  • Réduire l'empreinte noyau (mais ça m'amuse moins que dans mon jeune temps, surtout les tests sur une machine headless) ;
  • S'arranger pour que les samples courants sortent de la swap quand on sélectionne une banque de sons (là, j'ai une idée).