jzu - Tag - NSLU2
Un peu de tout et de rien, et beaucoup de n'importe quoi
2014-03-05T09:25:29+01:00
Jean Zundel
urn:md5:f3670f93ee9b6d0bf8c4b9dc5ac3c746
Dotclear
mpd
urn:md5:8bf86b5d38f0455e69aaa04d65563b76
2014-01-19T19:16:00+01:00
jean zundel
GNU-Linuxmedia centermpdNSLU2Raspberry PiXBMC
<p>Vous le savez, tout le monde le sait, un CD ne vit pas très longtemps. 20, 30
ans ? <a href="http://www.clir.org/pubs/reports/pub121/sec4.html">100 ans au maximum, paraît-il</a>,
mais en conditions optimales, c'est-à-dire stocké
dans un endroit dont l'hygrométrie et la température y sont strictement
contrôlées. La seule solution, hors le vinyl ? Les sauvegardes, de disque en
disque...</p>
<p>J'ai donc commencé à ripper tous mes CD (une vingtaine sont en fait déjà morts)
en vue de les coller sur un serveur. Cela s'appelle un media center. Oui, je
sais, ça existe depuis longtemps, sur tous les systèmes d'exploitation, et on
peut ainsi distribuer chez soi tant de la musique que de la vidéo, mais je ne
m'y étais pas attaqué pour plein de raisons. D'abord, la flemme, mais pas que.
Un ordinateur ronronnant en permanence dans le salon ? Et puis quoi encore ?</p>
<p>C'est quand le <a href="http://www.raspberrypi.org/">Raspberry Pi</a> est sorti que le concept a pris forme. À
l'origine, je n'en ai pris un que pour l'intégrer sur mon pedalboard en tant
que pédale d'effet, ce qui est en effet le cas aujourd'hui (on en reparlera
plus tard). Mais l'idée faisait son chemin et j'ai continué à ripper/encoder en
<a href="http://fr.wikipedia.org/wiki/Free_Lossless_Audio_Codec">FLAC</a> tous mes CD,
enfin le plus possible : actuellement, 350 sur 500. Tout est
mis sur un disque à part connecté à un vieux <a href="http://fr.wikipedia.org/wiki/NSLU2">Linksys NSLU2</a> (le même que
<a href="http://jzu.blog.free.fr/index.php?tag/Slug">celui du Slab et du Slampler</a>) sur lequel tourne un serveur NFS et où se trouvent déjà mes
sauvegardes.</p>
<p>Ensuite, l'application. Il suffisait dans un premier temps de prendre un
logiciel reconnu, tout en un, de connecter le RPi à la télévision par HDMI, de
tester avec quelques albums stockés en local, puis d'étendre le système par un
serveur de fichiers distant, une carte son externe, un petit écran dédié, une
télécommande, etc.</p>
<p><strong>XBMC</strong></p>
<p><a href="http://xbmc.org/">XBMC</a> était le choix logique. Un logiciel maintenu avec une grosse communauté
d'utilisateurs, un forum actif, tout qui va bien, on essaye, d'autant plus
qu'un port spécifique existe pour le Raspberry Pi : <a href="http://www.raspbmc.com/">raspbmc</a>.</p>
<p>Et ça marche presque bien dès le départ, en effet. Il faut simplement
configurer un peu le système en faisant monter le volume NFS par <code>/etc/fstab</code> et
régler différents paramètres dans l'interface utilisateur. Le son passe par le
câble HDMI donc chez moi sur la télévision. Dégueulasse, évidemment. Pas grave, on
passe à l'étape suivante, la carte son externe, en commençant par une
<a href="http://www.behringer.com/EN/Products/UCA202.aspx">Behringer à pas cher</a>.</p>
<p>Mais XBMC ne reconnaît pas la carte-son, car XBMC ne supporte pas
<a href="http://fr.wikipedia.org/wiki/Advanced_Linux_sound_architecture">ALSA</a>.</p>
<p>A priori, on peut comprendre : moi aussi, j'ai du mal à supporter ALSA. Par
exemple, je ne comprends toujours pas les détails de son architecture après
avoir écrit un player de samples et une pédale d'effets. M'enfin... c'est quand
même dommage pour un logiciel multimedia sous Linux de ne pas s'appuyer sur les
couches standard sous-jacentes. Je ne sais pas très bien ce qui s'est passé en
2013 mais le support de <a href="http://doc.ubuntu-fr.org/pulseaudio">pulseaudio</a> a été abandonné sans penser qu'il eût été
bien vu de conserver des fonctionnalités de base comme l'indépendance vis à vis
du matériel. Il en existe des versions appelées <em>omxbackport</em> utilisant <a href="http://fr.wikipedia.org/wiki/OpenMAX">OpenMAX</a>
(quelle bonne idée, personne ne s'en sert sous Linux), censé rendre la carte USB visible
dans l'interface. Sauf que non, alors il faut tweaker la conf ALSA (?) et
inhiber le chargement d'un module noyau (!) pour que la carte son soit
utilisée en lieu et place du DAC interne à base de PWM 1 bit. Apparemment,
certains y arrivent. Moi je n'ai réussi qu'à aiguiller le son de la télé vers
la carte son pendant 10mn, complètement par hasard, avant plantage. Impossible
de retrouver les bons réglages ensuite.</p>
<p>Bref, XBMC c'est de la merde.</p>
<p>J'aurais peut-être pu mieux me débrouiller, et puis il existe des forks
paraît-il mieux foutus comme <a href="https://plex.tv/">Plex</a>, mais en fait il n'y a pas que ce souci-là.
La gestion des vidéos ne m'intéresse pas vraiment alors que c'est un point fort
du logiciel, et surtout sa conception monolithique me gênait de plus en plus.</p>
<p>Alors que je commençais à en avoir vraiment marre de passer des heures à
chercher une solution à ce qui devrait être un non-problème, je me suis demandé
comment je ferais, moi. Après tout, je connais l'API ALSA, coder un système de
liste et de sélection des morceaux n'a rien de difficile... C'est l'articulation
entre les deux qui pose un problème d'architecture. Derrière l'interface
utilisateur, la gestion technique des flux audio s'effectue en arrière-plan, ce
qui oriente tout de suite vers un démon (ou un thread, mais mes interdits
religieux restent bien trop contraignants dans ce contexte applicatif),
communiquant par socket avec le front-end. Ce qui m'a fait penser à quelque
chose...</p>
<p><strong>Music Player Daemon</strong></p>
<p>Cela existe, évidemment. <a href="http://www.musicpd.org/">mpd</a>, repéré au cours de pérégrinations dans les
packages Debian, d'abord écarté car pas assez tout en un et d'un abord peu
engageant, mpd, donc, s'avère après réflexion parfaitement adapté. Le démon
fait son boulot discrètement. Il gère tous les formats de fichiers ainsi que la
carte son (par ALSA, heh). Une pléiade de clients, comme <a href="http://sonata.berlios.de/">Sonata</a>
et <a href="http://gmpclient.org/">GMPC</a> sous Linux ou
<a href="https://itunes.apple.com/us/app/mpod/id285063020">MPoD</a> sur iPhone,
permet de contrôler la lecture à distance autant
qu'en local. Il suffit de leur donner l'adresse IP du serveur et ça juste
marche.</p>
<p>Dernière étape... non, avant-dernière. L'écran pour se débarrasser de la
télévision quand on lance un client en local. Un projet de
<a href="http://www.kickstarter.com/projects/697708033/hdmipi-affordable-9-high-def-screen-for-the-raspbe">petit écran HDMI</a>
financièrement accessible existe sur Kickstarter ; en attendant,
<a href="http://www.amazon.fr/rotatif-moniteur-couleur-arri%C3%A8re-voiture/dp/B00AIJ1WLY/">les moins chers des écrans de recul</a>
pour voiture font 4"3 de diagonale, soit la taille
d'un smartphone, et coûtent dans les 20 €, mais il vaut mieux prendre
<a href="http://www.amazon.fr/Trois-Couleur-QC0000801-fr2-V1-Ecran-pour-Voiture/dp/B00AH7W1M6">un 7" comme celui-ci</a>
car l'interface composite rend difficile la
lecture des petits caractères.</p>
<p>Enfin, il ne restera plus qu'à greffer
<a href="http://forum.stmlabs.com/showthread.php?tid=5549">un capteur infrarouge aux broches du connecteur GPIO</a>
du Raspberry Pi pour commander la sélection des morceaux en local à la place de la souris actuelle.</p>
<p>Et les CD, et leur lecteur, iront se faire oublier à la cave.</p>
Slampler Reboot
urn:md5:84b41c55165f0f998116b6e2c03256c3
2011-04-23T23:44:00+02:00
jean zundel
DIYGNU-LinuxNSLU2SlamplerSlug
<p>Le <a href="http://jzu.blog.free.fr/index.php?post/2010/12/24/Slampler%2C-suite">Slampler</a> 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
<a href="http://www.cyrius.com/debian/nslu2/install.html">ce document</a>.
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 :</p>
<pre>
# apt-get install gcc make libasound2-dev libasound2
</pre>
<p>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 <code>jackd</code> à <code>emacs</code>. 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.</p>
<p>Un nouveau programme gère le montage de ce volume supplémentaire car
un automounter standard comme <code>autofs</code> ne permet de monter un
disque à la volée que quand un accès se produit, sans intervenir sur
les processus.
<code><a href="https://github.com/jzu/slampler/blob/master/datamount.c">datamount</a></code>,
lui, scrute régulièrement <code>/proc</code> pour y regarder si
<code>/dev/sdb1</code> existe et s'il est monté. Il monte ou démonte la clef
si besoin est en tuant au passage le processus <code>slampler</code>, qui est
immédiatement réanimé par <code>init</code>.</p>
<p>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 <code>/tmp</code> et <code>/var/run</code> sont des
montages en <code>ramfs</code> 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 <code>/etc/rc.local</code> pour configurer correctement
<code>eth0</code> :</p>
<pre>
mount /dev/sda2 / -o rw,remount
ifconfig eth0 192.168.0.106
sleep 1
mount /dev/sda2 / -o ro,remount
</pre>
<p>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
<a href="http://www.artproaudio.com/products.asp?type=90&cat=13&id=128">ART</a>
qui pilote le son en attendant peut-être un
<a href="http://www.behringer.com/EN/Products/UCA202.aspx">UCA 202</a>.</p>
<p>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
<code>STDIN</code>. 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
<a href="http://gamingmouse.com/weapon.php?pid=31">pédales-ci</a>
ou
<a href="http://www.usbfever.com/index_eproduct_view.php?products_id=1674">celles-là</a>.</p>
<p>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.</p>
<p>Tout le code a été placé sur
<a href="http://github.com/jzu/slampler">Github</a>
for your lurking pleasure (et plus si affinités).</p>
<p>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
<a href="https://github.com/encryptio/convolute">convolute</a>,
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é
<a href="https://github.com/encryptio">encryptio</a>
a même fixé un bug d'utilisation de la librairie
<a href="http://sourceforge.net/projects/kissfft/">kissfft</a>
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.</p>
Slampler, suite
urn:md5:6aba017f8abc4aa2752492e5db154e32
2010-12-24T17:09:00+01:00
jean zundel
DebianDIYGNU-LinuxmusiqueNSLU2OSSSlamplerSlug
<p>Suite, mais pas fin, des <a href="http://jzu.blog.free.fr/index.php?post/2010/11/25/Slampler">aventures du Slampler</a> !</p>
<p><a href="http://jzu.blog.free.fr/public/Slampler/Slampler5.jpg"><img src="http://jzu.blog.free.fr/public/Slampler/.Slampler5_m.jpg" alt="Slampler monté - cc by-nc-sa" style="display:block; margin:0 auto;" title="Slampler monté - cc by-nc-sa" /></a></p>
<p>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.</p>
<p><a href="http://jzu.blog.free.fr/public/Slampler/Slampler6.jpg"><img src="http://jzu.blog.free.fr/public/Slampler/.Slampler6_m.jpg" alt="Slampler monté - cc by-nc-sa" style="display:block; margin:0 auto;" title="Slampler monté - cc by-nc-sa" /></a></p>
<p>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.</p>
<p><a href="http://jzu.blog.free.fr/public/Slampler/Slampler3.jpg"><img src="http://jzu.blog.free.fr/public/Slampler/.Slampler3_m.jpg" alt="Composants du slampler - cc by-nc-sa" style="display:block; margin:0 auto;" title="Composants du slampler - cc by-nc-sa" /></a></p>
<p>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 <a href="http://www.behringer.com/EN/Products/UCA202.aspx">Behringer UCA-202</a>. Il faudra probablement déplier et insérer le câble à l'intérieur du tuyau des switchs pour gagner de la place.</p>
<p><a href="http://jzu.blog.free.fr/public/Slampler/Slampler4.jpg"><img src="http://jzu.blog.free.fr/public/Slampler/.Slampler4_m.jpg" alt="Slampler assemblé - cc by-nc-sa" style="display:block; margin:0 auto;" title="Slampler assemblé - cc by-nc-sa" /></a></p>
<p>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.</p>
<p>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. <em>FAUX ! CF. infra.</em> 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.</p>
<p><a href="http://jzu.blog.free.fr/public/Slampler/console.png"><img src="http://jzu.blog.free.fr/public/Slampler/.console_m.jpg" alt="Code du slampler en mode debug - cc by-nc-sa" style="display:block; margin:0 auto;" title="Code du slampler en mode debug - cc by-nc-sa" /></a></p>
<p>Cela signifie aussi qu'il faut vraiment tuer les démons comme <code>hald</code> et <code>udevd</code> 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 <code>0/</code>, <code>1/</code> et <code>2/</code> allant se mettre par dessus ceux d'origine de <code>/data</code>, mais qu'elle ne peut être prise en compte qu'au boot.</p>
<p>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é...</p>
<p><strong>Edit</strong> 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 <code>./slampler</code> tournait, la commande <code>top</code> donne cette taille dans la colonne <code>VIRT</code> (mémoire virtuelle). Bref, le programme swappe à mort. Solutions :</p>
<ul>
<li>Réduire encore plus drastiquement la taille des samples (mais c'est pas drôle) ;</li>
<li>Réduire l'empreinte noyau (mais ça m'amuse moins que dans mon jeune temps, surtout les tests sur une machine headless) ;</li>
<li>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).</li>
</ul>
Slampler
urn:md5:9a911cc8deda66b65f15ecc573474457
2010-11-25T21:03:00+01:00
jean zundel
DebianDIYGNU-LinuxmusiqueNSLU2OSSSlabSlamplerSlug
<p>Le Slampler, Slug Sample Player, est né avec la formation d'un nouveau groupe,
sur les cendres des <a href="http://jzu.blog.free.fr/index.php?post/2010/05/07/Le-Knou-aux-BBB">Knou</a>. À 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.</p>
<p><strong>Son of Slab</strong></p>
<p>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.</p>
<p>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.</p>
<p><img src="http://jzu.blog.free.fr/public/Slampler/.slampler-studio_m.jpg" alt="Slampler en studio - © 2010 Delphine 13" style="display:block; margin:0 auto;" title="Slampler en studio - © 2010 Delphine 13" /></p>
<p><center>Prototype avec la pédale contenant l'interface audio, le Slug et le joypad</center></p>
<p><br /></p>
<p><strong>Le code</strong></p>
<p>Le code est sur <a href="http://github.org/jzu/slampler">Github</a> et rien de vraiment
notable n'a changé depuis le <a href="http://github.org/jzu/slab">Slab</a> 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 <code>latency</code>. 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
<a href="http://www.alsa-pboject.org/alsa-doc/alsa-lib/_2lest_2pcm__min_8c-example.html">pcm_min.c</a>,
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.</p>
<p>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.</p>
<p>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).</p>
<p><strong>Les données audio</strong></p>
<p>Le répertoire des données est indiqué par un <code>#define</code> 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
<code>/etc/fstab</code> pour y insérer une ligne comme</p>
<p><code>/dev/sdb1 /data vfat default 0 0</code></p>
<p>si le source contient</p>
<p><code>#define DATADIR /data</code></p>
<p>Les fichiers échantillons seront donc dans les répertoires /data/0, /data/1,
etc.</p>
<p>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 :</p>
<p><code># sox src.wav -c 1 -b 16 dst.wav rate -h 44100 dither -s</code></p>
<p>Pour convertir un fichier MP3 ou OGG en WAV, il suffit de lancer</p>
<p><code># mpg123 -w fichier.wav fichier.mp3</code></p>
<p>À 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.</p>
<p>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.</p>
<p><strong>Le système</strong></p>
<p>Comme pour le Slab, le socle est une <a href="http://www.debian.org/ports/arm/">Debian ARM</a> pour pouvoir
éditer/compiler/tester sur le NSLU2 lui-même. Les démons inutiles comme hald
sont coupés.</p>
<p>Il faut insérer une ligne dans le fichier /etc/inittab comme par exemple chez
moi :</p>
<p><code>sl:23:respawn:/home/slug/slampler/slampler</code></p>
<p>Elle démarre un processus <code>slampler</code> et le relance chaque fois ou'il s'arrête.
<code>telinit q</code> force le processus <code>init</code> à relire ce fichier si on (dé)commente cette
ligne pour passer d'une configuration de production à une configuration de
développement et vice-versa.</p>
<p>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.</p>
<p><strong>Pied au plancher</strong></p>
<p>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.</p>
<p>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>
<p><img src="http://jzu.blog.free.fr/public/Slampler/.slampler-pedalier_m.jpg" alt="Pédalier du Slampler - cc by-nc-sa" style="display:block; margin:0 auto;" title="Pédalier du Slampler - cc by-nc-sa" /></p>
<p><center>Le pédalier en construction</center></p>
<p><br /></p>
<p>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.</p>
<p>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...</p>
<p><strong>Résultat</strong></p>
<p>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).</p>
<p><img src="http://jzu.blog.free.fr/public/Slampler/.slampler-en-action_m.jpg" alt="Slampler en action - © 2010 Delphine 13" style="display:block; margin:0 auto;" title="Slampler en action - © 2010 Delphine 13" /></p>
<p><center>Portrait de l'artiste en <strike>jeune</strike> geek</center></p>
<p><br /></p>
<p>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.</p>
<p>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.</p>
SLAB - Slug Audio Blaster
urn:md5:bbfdcc4e43ee3e5ea13cdd63f8889e19
2010-04-19T13:06:00+02:00
jean zundel
DebianDIYeffetGNU-LinuxmusiqueNSLU2OSSSlabSlug
<p>Après le <a href="http://jzu.blog.free.fr/index.php?post/2010/03/30/Le-Phaseur-Arduino">Phaseur Arduino</a>, 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.</p>
<p>Parmi tous les matériels compacts pouvant tourner sous GNU/Linux, le <a href="http://www.linksysbycisco.com/EU/fr/products/NSLU2">Linksys NSLU2</a>, alias <a href="http://www.nslu2-linux.org/">Slug</a>, 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 <a href="http://www.nslu2-linux.org/SlugOS">SlugOS/LE</a>, qui ne m'a pas convaincu (trop compliqué à customiser, surtout alors que je pensais encore utiliser jack) et <a href="http://fr.debian.org">Debian</a>. 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 €.</p>
<p>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 <em>mécanique</em> 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.</p>
<p>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.</p>
<p>Ensuite, quelle couche logicielle attaquer ? <a href="http://jackaudio.org">Jack</a> 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 <a href="http://www.alsa-project.org/main/index.php/Main_Page">ALSA</a> sous-jacente. Malgré l'étrange avis du tutoriel de l'API ALSA concernant le full-duplex (<a href="http://www.equalarea.com/paul/alsa-audio.html#forget">In a word: JACK</a>), on peut parfaitement lire et écrire sur la même carte-son.</p>
<p><a href="http://jzu.blog.free.fr/public/SLAB/slab.c">Le code</a>, sous <a href="http://www.gnu.org/licenses/gpl.html">GPL</a>, est structuré en gros en :</p>
<ul>
<li>Thread séparé du joystick ;</li>
<li>Initialisation de la carte-son en full-duplex ;</li>
<li>Boucle de traitement avec l'enchaînement d'effets ;</li>
<li>Diverses fonctions de gestion des indicateurs lumineux, d'affichage de debug, gestion des signaux, etc.</li>
</ul>
<p>Dans les données, on notera surtout</p>
<ul>
<li><code>procbuf</code>, le buffer circulaire où le signal est traité ;</li>
<li><code>joyval</code>, indiquant la position du potard de la pédale, dont il faut intégrer les variations pour éliminer les fluctuations engendrant des distorsions ;</li>
<li><code>sinus</code>, un tableau de valeurs pre-calculées pour pallier l'absence de FPU sur cet ARM.</li>
</ul>
<p>On compile le source unique par :</p>
<p><code>$ gcc -g -Wall -lasound -lthread -o slab slab.c</code></p>
<p>et c'est tout. Si l'exécutable résultant est lancé par <em>root</em>, il permet en plus de commander les petites lumières du Slug qui indiquent quels effets sont enclenchés. Le flag <code>-d</code> fait afficher des messages de debug.</p>
<p>ALSA ne se laisse pas programmer facilement. Comme le rappelait déjà <a href="http://www.saunalahti.fi/~s7l/blog/2005/08/21/Full Duplex ALSA">Alan's clob</a> en parlant de ses efforts sur <a href="http://sourceforge.net/projects/gnuitar/">Gnuitar</a>, 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 <code>_near</code> pour ajuster les paramètres en interne si ceux qui ont été passés ne correspondent pas exactement à ce qu'accepte la carte.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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 <code>/etc/rc.local</code> - au cas où une série de <code>write_underrun</code> 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.</p>
<p>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'<a href="http://jzu.blog.free.fr/index.php?post/2010/03/27/Alesis-airFX">airFX</a>.</p>
<h4>Les photos !</h4>
<p>Le Slug et la carcasse de wah :
<img src="http://jzu.blog.free.fr/public/SLAB/.Slab1_m.jpg" alt="SLAB - premier essai" style="display:block; margin:0 auto;" title="Slug et carcasse de wah" /></p>
<p>Les éléments, de haut en bas - NSLU2, hub sur lequel est monté clef USB et carte-son, convertisseur joystick, carcasse (sans les boutons) :
<img src="http://jzu.blog.free.fr/public/SLAB/.Slab2_m.jpg" alt="SLAB 2" style="display:block; margin:0 auto;" title="Éléments non intégrés" /></p>
<p>L'intégration dans le boîtier :
<img src="http://jzu.blog.free.fr/public/SLAB/.Slab3_m.jpg" alt="Slab complet" style="display:block; margin:0 auto;" title="Slab complet, avr. 2010" /></p>
<h4>Les samples !</h4>
<p><a href="http://jzu.blog.free.fr/public/SLAB/slab1.mp3">Premier essai.</a> Clairement, cette pédale souffre, il faut faire quelque chose.</p>
<p><a href="http://jzu.blog.free.fr/public/SLAB/slab2.mp3">Ça marche !</a> Son clean, en direct sur une console de mixage.</p>
<p><a href="http://jzu.blog.free.fr/public/SLAB/slab3.mp3">Avec une fuzz devant</a>, 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.</p>
<h4>Les liens !</h4>
<ul>
<li><a href="http://www.cyrius.com/debian/nslu2/linux-on-flash.html">Linux sur disque flash</a></li>
<li><a href="http://www.cyrius.com/debian/nslu2/install.html">Install Debian sur NSLU2</a></li>
<li><a href="http://www.nslu2-linux.org/wiki/HowTo/UseTheResetButtonToEnterUpgradeMode">Bouton Reset et mode de mise à jour</a></li>
<li><a href="http://wiki.openembedded.net/index.php/Main_Page">OpenEmbedded</a></li>
<li><a href="http://www.thegnar.org/embedded_linux/SlugOsOpenEmbedded.html">SlugOS & OpenEmbedded</a></li>
<li><a href="http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/Tutorial-Improving-an-embedded-Linux-system/">Amélioration d'un système embarqué</a></li>
<li><a href="http://www.alsa-project.org/main/index.php/Low_latency_howto">Low latency HOWTO</a></li>
</ul>