jzu

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.

Suite, mais pas fin, des aventures du Slampler !

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.

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.

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.

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.

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

Après le Phaseur Arduino, l'étape suivante était logiquement un système embarqué sous Linux afin de pouvoir gérer assez de RAM pour des effets comme l'echo et, peut-être, la reverb, en plus du flanger. Enfin, un vrai système d'exploitation avec un compilateur et un serveur SSH ! Ça change de l'IDE limité et des transmissions série de l'Arduino. Parfois, j'aime mes aises. Et une vraie carte-son permet de s'affranchir des bricolages d'I/O analogiques et d'obtenir un rapport signal-bruit correct.

Parmi tous les matériels compacts pouvant tourner sous GNU/Linux, le Linksys NSLU2, alias Slug, est un choix logique parce qu'il est très largement supporté et qu'il comprend 2 ports USB. Plusieurs distros pour processeur ARM sont disponibles dont SlugOS/LE, qui ne m'a pas convaincu (trop compliqué à customiser, surtout alors que je pensais encore utiliser jack) et Debian. Le seul vrai inconvénient de Debian est l'ajout obligatoire d'espace disque supplémentaire, ce qui implique d'utiliser un des ports USB pour une clef de 2Go. La carte-son choisie est un dongle USB appelé C-sound, compatible usb-audio, trouvé sur eBay pour 4 €.

Le contrôleur ? Une wah chinoise à 16 € (+fdp) dépouillée de son électronique et un peu bricolée pour pouvoir se servir réellement du switch. N'importe quelle wah mécanique fera l'affaire, en évitant de préférence les wah chinoises comme la mienne qui ne sert qu'à prototyper. Les Morley, Behringer et autres pédales à commande optique sont donc à oublier pour l'instant. Le potentiomètre de 100 kΩ est connecté à un convertisseur 15 broches analogigue -> USB. Sa résolution de 7 bits n'est ni plus ni moins pathétique que les joysticks USB habituels mais les potards de ceux-ci ne sont pas compatibles. Il faudrait aussi que je retrouve ce fabricant anglais de convertisseurs analogique-numérique pas trop chers, qui ont une bien meilleure résolution.

Ok, il faut trois ports USB au total, donc ajouter un hub. Pas grave car il peut être passif, mais le joystick doit être connecté en direct sinon il marche très mal (un hub actif n'y change rien). Deux câbles USB vont donc de la pédale au Slug.

Ensuite, quelle couche logicielle attaquer ? Jack est tentant sur le papier mais, sérieusement, il n'y a ici rien à multiplexer et ses capacités « temps réel » dépendent avant tout de la couche ALSA sous-jacente. Malgré l'étrange avis du tutoriel de l'API ALSA concernant le full-duplex (In a word: JACK), on peut parfaitement lire et écrire sur la même carte-son.

Le code, sous GPL, est structuré en gros en :

• Thread séparé du joystick ;
• Initialisation de la carte-son en full-duplex ;
• Boucle de traitement avec l'enchaînement d'effets ;
• Diverses fonctions de gestion des indicateurs lumineux, d'affichage de debug, gestion des signaux, etc.

Dans les données, on notera surtout

• procbuf, le buffer circulaire où le signal est traité ;
• joyval, indiquant la position du potard de la pédale, dont il faut intégrer les variations pour éliminer les fluctuations engendrant des distorsions ;
• sinus, un tableau de valeurs pre-calculées pour pallier l'absence de FPU sur cet ARM.

On compile le source unique par :

$ gcc -g -Wall -lasound -lthread -o slab slab.c

et c'est tout. Si l'exécutable résultant est lancé par root, il permet en plus de commander les petites lumières du Slug qui indiquent quels effets sont enclenchés. Le flag -d fait afficher des messages de debug.

ALSA ne se laisse pas programmer facilement. Comme le rappelait déjà Alan's clob en parlant de ses efforts sur Gnuitar, il faut en passer par une palanquée de fonctions de bas niveau quand, la plupart du temps, on voudrait simplement ouvrir une carte-son avec des paramètres par défaut. Heureusement, ALSA fournit des variantes suffixées par _near pour ajuster les paramètres en interne si ceux qui ont été passés ne correspondent pas exactement à ce qu'accepte la carte.

L'echo et le flanger fonctionnent plutôt bien. Il faut intégrer la valeur du joystick de manière différente dans les deux effets pour ne pas voir apparaître d'altération. Pourquoi ? Parce que je ne sais pas m'y prendre, probablement.

La distorsion modélise plus ou moins un étage de sortie en push-pull d'ampli à lampes. Plutôt moins que plus, hein. Disons qu'il génère un bon paquet d'harmoniques tierces grâce à une fonction de transfert en quart d'onde sinusoidale, qu'on applique récursivement pour accentuer l'effet.

Le gros problème est la latence, dans les 22 ms, en partie due au bus USB auquel est raccordé la carte-son. Ce délai est perceptible (il gêne le jeu) sur les effets non temporels comme la distorsion ; beaucoup moins sur les effets d'ambiance où la précision est moins cruciale. L'USB n'est pas le seul coupable car j'observe aussi des latences avec la carte-son d'un vieux portable IBM 240 sur lequel tourne le programme.

En conditions réelles, on doit pouvoir sélectionner deux effets par les poussoirs rouges situés devant la pédale. Un troisième, plus petit, situé juste au-dessous d'eux, permet de réinitialjser le programme - en fait de l'interrompre, le système le relançant par une boucle dans /etc/rc.local - au cas où une série de write_underrun engendre un délai énorme (une seconde) que l'on ne peut plus faire disparaître : il faut resetter toute la stack ALSA. Je ne maîtrise pas encore tout de l'API, d'où peut-être ce délai étonnant qui apparaît au playback quand, lors des tests, le traitement s'effectue aux dépens des I/O.

La latence de base et l'absence de FPU limitent sérieusement les possibilités. Il faudrait tester avec un système du type PC embarquant une carte-son intégrée mais cela reviendrait beaucoup plus cher que les 140 € de l'ensemble. Un vieux portable comme l'IBM dont il est question plus haut pose des problèmes potentiels de fiabilité (disque dur, à remplacer par de la SSD ?) et de solidité mécanique (boîtier plastique) qui interdisent son utilisation sur scène. Et la latence n'y disparaît pas totalement, loin de là (qu'en dit le projet Gnuitar ?). Je recherche surtout une manière de lire les trames USB au plus bas niveau pour démiauler les données brutes et les réinjecter directement après traitement. Sans trop d'espoir, mais à vrai dire sans trop de motivation non plus : quand le système sera complètement intégré, d'ici quelques soudures, il fera malgré tout exactement ce qui lui était demandé au départ, et je pourrait l'intégrer à mon pedalboard pour remplacer la Cry Baby qui remplace l'airFX.

Les photos !

Le Slug et la carcasse de wah :

Les éléments, de haut en bas - NSLU2, hub sur lequel est monté clef USB et carte-son, convertisseur joystick, carcasse (sans les boutons) :

L'intégration dans le boîtier :

Les samples !

Premier essai. Clairement, cette pédale souffre, il faut faire quelque chose.

Ça marche ! Son clean, en direct sur une console de mixage.

Avec une fuzz devant, on peut jouer avec la résonance pour obtenir une mélodie par-dessus les accords. La résolution imparfaite du convertisseur USB donne des notes discrètes au lieu d'un portamento continu.

Les liens !

• Linux sur disque flash
• Install Debian sur NSLU2
• Bouton Reset et mode de mise à jour
• OpenEmbedded
• SlugOS & OpenEmbedded
• Amélioration d'un système embarqué
• Low latency HOWTO

Update: English translation avalaible at http://jzu.blog.free.fr/index.php?pages/Le-Phaseur

L'airFX prenant trop de place sur le pédalier, il avait giclé au profit d'une wah de base, mais j'avais toujours besoin de cet effet de flange malade qu'on peut entendre par exemple sur Youpi Youpi Yeah (la chanson) - enfin, moins maintenant, mais bon - et, après tout, pourquoi ne pas bricoler un effet numérique ? Il existe déjà une pédale se voulant open source dont le manque de succès est peut-être dû à son prix élevé, dans les $300. On peut baisser les coûts en utilisant un Arduino, par exemple, si on n'a pas besoin de trop de mémoire ni de définition, et puis ça peut être cool d'architecturer soi-même tout le système. Il faut quand même faire un peu d'électronique, et savoir optimiser son code car on ne dispose là que d'un pauvre micro-contrôleur ATmega168 à 16 MHz avec quelques kilo-octets pour le programme et 1 kilo-octet pour les données, y compris la stack. Juste de quoi piloter un lave-vaisselle. Ou fabriquer un effet de déphasage lo-fi.

Le déclic est venu d'un article d'Instructables où, même si les effets n'avaient pas trop d'intérêt et s'il s'y glissait deux ou trois erreurs, son auteur, kylemcdonald, posait toutes les bases nécessaires que ce soit au niveau matériel ou logiciel. Ma solution est maintenant un peu différente sous ces deux aspects mais n'aurait jamais vu le jour sans cet article.

En attendant le circuit commandé aux USA, j'ai commencé par tester mes idées de « flange variable » avec Audacity pour valider l'algorithme à employer en décalant un signal de quelques millièmes de seconde et en faisant varier ce décalage. Le colis reçu, on commence le boulot d'intégration avec l'adaptation des entrées-sorties audio. En entrée, il faut 5 volts alors que le signal d'une guitare est de l'ordre de quelques centaines de millivolts. En sortie, c'est l'inverse. Il faut donc un étage d'amplification comme un ampli op (le LT1006 convient pour 5 volts) en entrée et un diviseur de tension en sortie. L'entrée analogique autorise 10 bits mais, pour obtenir une sortie d'une résolution au moins aussi correcte, il faut combiner deux sorties numériques 8 bits en PWM en ajustant les résistances de sortie pour que l'une soit d'une valeur 256 fois supérieure à l'autre. Enfin, on peut obtenir 5 volts à partir de 9 volts avec un régulateur de tension sur un radiateur. Quelque chose comme ça, les parties en pointillés étant optionnelles :

A posteriori, je vois bien que le circuit d'entrée est buggé et que les filtres passe-bas ne sont pas nécessaires. Mais il a suffit à obtenir du son au bout de quelques essais difficiles, avec le proto du circuit d'adaptation sur un breadboard.

Les premiers essais avec le prototype complet - dont une vieille pédale italienne nullissime recyclée pour l'occasion - donnent ce sample. Attention aux oreilles sensibles.

Et finalement, on peut embarquer une version définitive dans la vieille wah. La correction du circuit électronique donne un meilleur résultat du point de vue de la saturation mais le son devient bien moins intéressant malgré le sample and hold involontaire (interférences au niveau du multiplexeur d'entrées analogiques audio et potentiomètre ?)

Le code du Phaseur, sous licence Artistic 2.0, est rébarbatif et simple en même temps. Rébarbatif en raison de la proximité du matériel qu'aucune librairie n'isole du programmeur (« Cachez ces registres que je ne saurais voir »). Simple car l'algorithme consiste à mélanger l'échantillon courant avec ce qu'on a écrit dans le buffer circulaire juste un peu plus tôt, selon la position de la pédale. Tout se passe dans loop().

À suivre. Car, même si un autre effet est prévu sous Linux avec des possibilités de traitement de qualité CD et de la mémoire a gogo, l'Arduino reste une solution efficace - car sans système d'exploitation - si on se contente de 8 ou 10 bits de résolution. Une fois que l'électronique d'adaptation sera au point et que le son obtenu sera correct, il suffira de décaler l'offset de la polarisation et de monter le gain pour obtenir l'effet cradingue du premier sample qui plaît tant à certains (et terrorise les autres).

Il y a quelgues années, Warren m'avait parlé de son airSynth qu'il avait acheté pour des queues de cerises car personne n'en voulait. Il m'a donné envie de tester l'airFX, qui est la version effet pour DJ. Mais avec une guitare.

C'est un de ces engins bizarres qu'Alesis sort régulièrement pour les poubelliser trois ans plus tard. Ici, nous avons un gros socle plat surmonté d'un dôme contenant des capteurs infrarouges permettant de moduler trois paramètres de l'effet sélectionné, selon la position de la main dans l'espace. Il comprend 49 présélections accessibles par l'espèce de grosse molette, non modifiables mais les réglages en 3D compensent un peu cette limitation.

Oooh, on dirait qu'il y a de quoi s'amuser, j'en veux un, j'en veux un... Facile, il n'intéresse personne. J'ai donc eu un des derniers exemplaires chez Thomann, au tarif de déstockage. On en trouve encore aujourd'hui pour moins de 100 € sur la baie et ailleurs.

Il a fallu réaliser l'adaptation à la guitare, d'abord par un petit boîtier contenant 3 jacks (1 in, 2 out) et 2 interrupteurs (mono/stéréo, on/bypass). Au lieu de la main, j'agitais le pied au dessus du dôme - pas pratique - jusqu'à l'arrivée d'un socle en bois. Même après, il fallait toujours se baisser pour actionner l'interrupteur. Solution : un switch fugitif monté sur un pied de meuble, lequel intègre aussi les jacks et des potentiomètres d'adaptation du niveau.

En groupe, je ne me servais plus que d'un seul patch, une sorte de flanger où le LFO est remplacé par le positionnement du pied au-dessus du dôme.

L'airFX a maintenant disparu de mon pedalboard de scène pour cause de place manquante, remplacé temporairement par une Cry Baby en attendant une pédale numérioue home-made en cours de réalisation qui reproduirait ce fameux flanger. On en reparle bientôt.