jzu

Aller au contenu | Aller au menu | Aller à la recherche

Tag - Slampler

Fil des billets - Fil des commentaires

Slampler Reboot

Le Slampler a fait des siennes. En fait, le NSLU2 n'a pas aimé les arrêt-marche à répétition. Ça a été l'occasion d'une réinstallation complète en se servant toujours de ce document. Après plusieurs heures d'installation à cause des lenteurs d'écriture sur la clef USB, le système était de nouveau opérationnel. Il a suffit d'installer quelques packages supplémentaires pour retrouver une machine totalement fonctionnelle :

# apt-get install gcc make libasound2-dev libasound2

C'est plus propre, du coup. L'installation antérieure comprenait un maximum de packages inutiles car ils servaient aux tests et au développement, de jackd à emacs. Tout compris, le système prend maintenant 360 Mo d'espace disque. Une clef de 512 Mo peut donc suffire en laissant plus de 100 Mo de libre pour les samples par défaut, ceux qui seront joués si aucune autre clef USB n'est insérée dans le port libre.

Un nouveau programme gère le montage de ce volume supplémentaire car un automounter standard comme autofs ne permet de monter un disque à la volée que quand un accès se produit, sans intervenir sur les processus. datamount, lui, scrute régulièrement /proc pour y regarder si /dev/sdb1 existe et s'il est monté. Il monte ou démonte la clef si besoin est en tuant au passage le processus slampler, qui est immédiatement réanimé par init.

Les systèmes de fichiers sont montés en lecture seule pour pouvoir couper le jus sans avoir peur de tout borker - ce qui m'est arrivé plus d'une fois. Les répertoires /tmp et /var/run sont des montages en ramfs puisque leur contenu est par nature volatile et que le système ne serait pas content s'il ne pouvait pas y écrire. Sauf que le réseau ne monte pas pour une raison inconnue (ah, les joies des machines headless) et qu'il faut une bidouille horrible dans le /etc/rc.local pour configurer correctement eth0 :

mount /dev/sda2 / -o rw,remount
ifconfig eth0 192.168.0.106
sleep 1
mount /dev/sda2 / -o ro,remount

Le dongle C-Sound (ou 3D Sound) est abandonné pour cause de bruit de fond vraiment trop épouvantable. C'est aujourd'hui un boîtier ART qui pilote le son en attendant peut-être un UCA 202.

L'absence du joystick est gérée à peu près correctement et on peut le brancher alors que le programme est en train de tourner. Surtout, un thread supplémentaire permet de contrôler le slampler par STDIN. Pratique pour les tests. Un autre est en préparation pour contrôler un clavier USB par l'interface HID, ce qui permettra d'utiliser ces pédales-ci ou celles-là.

Les samples sont maintenant lus à la volée au lieu d'être stockés en RAM, ce qui était l'erreur principale de la version antérieure : le processus se mettait à swapper en saturant le bus USB. Les 44 octets d'en-tête de chaque fichier WAV sont quand même lus au démarrage pour connaître la taille et les caractéristiques des samples.

Tout le code a été placé sur Github for your lurking pleasure (et plus si affinités).

Au fait, en me baladant parmi les divers projets audio de Github, entre un gazillion de mixers, de streamers et de wrappers Javascript pour HTML5, je suis tombé sur convolute, un programme combinant plusieurs sons par convolution. On prend un son, on le transforme par un autre et on en obtient un troisième qui n'a qu'un lointain rapport avec les deux premiers. Le dénommé encryptio a même fixé un bug d'utilisation de la librairie kissfft qui se produisait sur mes machines, qu'il en soit remercié. La moitié des samples joués aujourd'hui par le Slampler proviennent de ce programme.

Slampler, suite

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).

Slampler

Le Slampler, Slug Sample Player, est né avec la formation d'un nouveau groupe, sur les cendres des Knou. À la première répétition, on aurait voulu envoyer des samples comme ceux que Paul avait insérés sur ses maquettes enregistrées avec Ableton Live. En général, cela signifie acheter un pédalier sampler/looper comme un Boss RC-50 ou un Boomerang, mais on ne trouve pas grand-chose en dessous de 400 € si on veut plusieurs déclencheurs, et les fonctionnalités de boucle et d'enregistrement en direct ne sont pas nécessaires. Non, il fallait simplement quelques switches au pied, chacun lançant son échantillon, éventuellement répartis en banques à travers lesquelles on peut cycler grâce à un dernier poussoir.

Son of Slab

Rien de plus simple en partant du Slab puisqu'il suffit d'en prendre les parties qui assurent la sortie audio, la gestion du joystick, et d'y ajouter une gestion simplissime des fichiers d'échantillons. On a donc N fichiers de nom quelconque par répertoire nommé numériquement (0, 1, 2...) pour chaque banque de son, et hop. Il suffit de presser un bouton de joystick pour que le son correspondant soit reproduit.

La carte-son est toujours l'horrible petit dongle C-sound à quelques euros pièce. Elle semble suffire à la tâche, surtout dans un contexte de répétition ou de petit concert... mais on en reparlera plus loin.

Slampler en studio - © 2010 Delphine 13

Prototype avec la pédale contenant l'interface audio, le Slug et le joypad


Le code

Le code est sur Github et rien de vraiment notable n'a changé depuis le Slab hormis l'initialisation de la carte-son. Elle passe maintenant par la fonction snd_pcm_set_params() qui simplifie tout. À l'époque, j'avais dû lire une doc obsolète où cette fonction ne figurait pas encore. Le point notable est qu'elle accepte de plus un paramètre latency. Je ne le retrouve pas dans les primitives ALSA alors que ce paramètre est décisif pour le temps se réponse. Dans l'exemple pcm_min.c, il est fixé à 500000 en millonnièmes de secondes, et le sample met effectivement une demi-seconde à se déclencher. 500 et 5000 donnent une sorte de grésillement au playback et 50000 (50 millièmes de seconde) envoie un son correct quasiment instantanément. Il faudra donc revoir l'initialisation du Slab puisque ce paramètre additionnel pourrait corriger les divers problèmes de latence observés.

Là où le Slab utilise un buffer circulaire pour gérer l'audio, le Slampler emploie autant de pointeurs qu'il existe de switchs déclarés. Dès qu'une variable d'état change depuis le thread du joystick suite à l'activation du sample, un de ces pointeurs est affecté au short * du sample, puis un certain nombre de trames sont copiées vers *playbuf par addition et le pointeur est incrémenté à chaque itération. À la fin du sample, le pointeur est remis à NULL.

Le code est directement portable d'une Debian à une Ubuntu et de ARM à Intel. Pas essayé sur une Fedora ou une OpenSuSE (sur un IBM zSeries non plus, d'ailleurs).

Les données audio

Le répertoire des données est indiqué par un #define dans le source et peut être monté sur un système de fichiers à part comme celui d'une clef USB ou d'une carte SD. Dans ce cas, il faut bien entendu bricoler le fichier /etc/fstab pour y insérer une ligne comme

/dev/sdb1 /data vfat default 0 0

si le source contient

#define DATADIR /data

Les fichiers échantillons seront donc dans les répertoires /data/0, /data/1, etc.

Leur format est obligatoirement s16le à 44100, mono ou stéréo. La fréquence est fixée car on ne peut pas s'amuser à convertir les flux audio à la volée avec un processeur à 266 MHz. La commande qui suit convertit tout fichier audio non compressé au bon format :

# sox src.wav -c 1 -b 16 dst.wav rate -h 44100 dither -s

Pour convertir un fichier MP3 ou OGG en WAV, il suffit de lancer

# mpg123 -w fichier.wav fichier.mp3

À noter, un petit quirk des systèmes de fichiers évolués comme les ext*fs : l'ordre d'insertion dans un répertoire n'est pas celui dans lequel les entrées de fichier seront ensuite lues par readdir(). Ce n'est pas le cas des FAT des clefs USB où le premier fichier copié dans un répertoire vide sera le premier à apparaître dans la liste. Celui-ci sera alors affecté au switch de gauche, le deuxième au suivant, etc.

Chaque échantillon est stocké en RAM en mono quel que soit son format d'origine pour optimiser la place. Il est converti en 2 canaux au moment du playback car certaines cartes son n'acceptent pas de signal mono, et son amplitude est divisée par deux pour pouvoir mixer les signaux de samples différents sans trop de saturation. Un mécanisme transforme le dépassement de capacité en simple écrêtage.

Le système

Comme pour le Slab, le socle est une Debian ARM pour pouvoir éditer/compiler/tester sur le NSLU2 lui-même. Les démons inutiles comme hald sont coupés.

Il faut insérer une ligne dans le fichier /etc/inittab comme par exemple chez moi :

sl:23:respawn:/home/slug/slampler/slampler

Elle démarre un processus slampler et le relance chaque fois ou'il s'arrête. telinit q force le processus init à relire ce fichier si on (dé)commente cette ligne pour passer d'une configuration de production à une configuration de développement et vice-versa.

Le programme tourne en tant que root ce qui lui donne les bons droits pour allumer et éteindre les LED du NSLU2 selon la banque de sons sélectionnée.

Pied au plancher

Les joysticks et les joypads que je connais peuvent comporter jusqu'à 10 boutons. Il suffira donc de souder aux contacts de ces boutons des fils allant à des poussoirs fugitifs pour les commandes au pied, le tout intégré dans un boîtier plat, un demi-tuyau en PVC ou une gouttière en alu, pour obtenir l'interface de conmande.

Jusqu'à 8 sons peuvent être activés simultanément puisque 8 switchs sont définis dans le code plus celui de banque. Cela donnerait un pédalier à 9 poussoirs, donc d'au moins 80 cm de long si on les espace de 10 cm. Un peu long pour mon goût : je me contente de 5 poussoirs de samples plus un de banque, espacés de 8 cm, ce qui donnera un peu plus de 50 cm avec les marges sur les côtés.

Pédalier du Slampler - cc by-nc-sa

Le pédalier en construction


Pour le prototype, les contacts d'un Logitech Precision seront soudés à 7 fils (1 pour le commun) courant vers un tuyau en PVC de 40 mm de diamètre, calé par deux quarts de tuyau dans le sens de la longueur pour le stabiliser, dans lequel sont percés les trous recevant les poussoirs. Ceux-ci porteront les fils électriques soudés à des fils de faible section, eux-mêmes soudés aux contacteurs du joypad. La fiabilité est le point faible du proto. Il faudra probablement un tuyau de plus grand diamètre pour héberger tout le foutoir branché au Slug : intérieur du joypad, carte-son, clef USB et hub passif.

Tout cela sera possible une fois que je serai arrivé à souder correctement les fils sur le circuit du joypad. Pour l'instant, j'ai surtout réussi à griller deux contacteurs...

Résultat

En répétition, avec un joypad actionné à la main puisque le pédalier n'était pas encore soudé, l'ensemble s'avère utilisable à un détail près. La très mauvaise qualité de l'interface provoque un hiss assez perceptible à volume de groupe. Il faut changer de carte son mais je ne connais pas les interfaces pas chères actuelles (comme la Behringer UCA 202), ou insérer une noise gate bas de gamme en sortie comme la Harley Benton de chez Thomann à 25 euros (ne pas prendre la Behringer, qui ne marche pas de l'avis général).

Slampler en action - © 2010 Delphine 13

Portrait de l'artiste en jeune geek


D'autre part, un bug dans le code actuel provoque parfois le défilement de plusieurs samples à la suite quand on change de banque pendant qu'un échantillon tourne encore. C'est facilement corrigeable, soit en coupant les samples en train de tourner quand on passe à la banque suivante, soit en gérant les structures de donnéss un peu différemment.

Enfin, faut-il simplement lancer un sample et attendre qu'il se termine, ou bien ne le jouer que le temps que le switch correspondant reste enfoncé ? C'est actuellement la première solution qui est mise en œuvre mais il serait facile de tenir compte de l'état courant des switchs. Comme d'habitude, à suivre.