Oui, ubuntu est un bon produit dans sa globalité, j’en ai fait des éloges à ses débuts, j’ai pris sa défense lorsque les premières bourdes sont apparues, j’ai même encore recemment chanté les louanges de héron boiteux, mais voila, me concernant, la qualité du travail effectué par les mainteneurs d’ubuntu depuis quelques mois n’a fait qu’empirer.

Gravures CD/DVD hasardeuses, divers bugs relatifs a la gestion du clavier, crash à l’install d’intrepid sur une machine vierge, innombrables déconvenues liées à pulseaudio, upgrades toujours cauchemardesques, et j’en passe. Autant de raisons qui m’ont peu à peu dégouté du “Linux for human beings”. Evidemment, ces bugs sont répertoriés dans le fameux launchpad, seulement voila, launchpad est devenu à mes yeux une sorte de liste de bugs qui ne seront pas résolus tant que debian n’aura pas fixé le package associé en “unstable”.

Donc voila, j’écris ce billet depuis une Debian/testing fraichement installée, aucun problème, pas de pulseaudio, tout fonctionne au poil. Je souhaite sincèrement que cette course effrenée à la nouveauté instable que semble poursuivre ubuntu ne causera pas une deterioration irrémediable de leur image, mais surtout de l’image de GNU/Linux.

Hier soir, alors que je me rencardais sur DSSI (un API pour créer des plugins audio à la VST), je suis tombé sur ce lien. FST n’est ni plus ni moins qu’un programme qui permet, en utilisant Wine et JACK d’utiliser des plugins VST sous GNU/Linux. Là comme ça, ça a l’air de rien, mais les musiciens dans l’assemblée, s’ils ne sont pas déjà au courant (le projet date de 2006 tout de même), devraient faire dans leur froc.

Un peu dubitatif, je décide d’essayer le machin.

Sous une Ubuntu / Debian, les packages suivants sont nécessaires :

• wine
• wine-dev
• lash-bin
• lashd
• liblash-dev

Décompressons de la version 1.8 de FST.

Après avoir récupéré le SDK 2.3 VST chez Steinberg (voir le lien chez http://www.joebutton.co.uk/fst/), décompresser l’archive vst_sdk2_3.zip puis vstsdk2.3.zip contenu dans cette archive dans le répertoire créé par la décompression de FST, fst-1.8. Le Makefile de FST est un peu foireux, commentez la ligne suivante :

        #cp -a $(VSTDIR) ./vst

Et réalisez cette étape à la main avant d’invoquer make :

$ mkdir vst && vstsdk2.3/source/common/* vst/

Enfin :

$ make

À ce stade, un executable, fst, devrait être disponible.

Démarrez alors LASH en invoquant la commande :

$ lash_panel

Téléchargez l’un des innombrables plugins VST disponibles, souvent gratuits et parfois libres, par exemple sur VST4Free et lancez le de cette façon :

$ pwd
/home/imil/sound/src/fst-1.8
$ ./fst /chemin/vers/le/plugin.dll

Le premier choc, c’est l’apparition du plugin :

Le second, c’est son apparition dans la liste des clients JACK :

Reste à attacher la sortie audio du plugin au port sonore systeme :

Le plugin est alors manipulable en utilisant n’importe quel canal midi (à eventuellement attacher au plugin en utilisant la console jack).

Et maintenant, j’ai besoin de Guronsan.

options snd slots=snd_hda_intel
alias snd-card-0 snd_hda_intel

au fichier /etc/modprobe.d/alsa-base d’une Ubuntu, on s’assure que la carte dont le driver est snd_hda_intel sera toujours associée au slot 0. Ainsi, tous les évenements sonores “habituels” utiliseront le slot 0 par defaut, et on affectera le slot 1 à JACK et toutes les applications l’utilisant.

Il suffit alors de recharger les modules alsa via la commande :

$ sudo alsa force-reload

et tout devrait rentrer dans l’ordre.

En effet, depuis quelques mois, le son provenant d’une application que je faisais passer par Jack grésillait inéxorablement. Gresillement / saturation, difficile de cerner le soucis et d’en rechercher la cause.

La solution vint de Tito, bien plus habitué que moi à bidouiller du son sous GNU/Linux. Via qjackctl, j’ai passé l’option Periods/Buffer de 2 à 8, et ô magie, un son pur comme le crystal s’échappait de mes enceintes.

On trouvera également quelques infos interessantes sur le sujet à cette adresse.

$ sudo rm -f /etc/asoundrc
$ sudo apt-get remove pulseaudio*

Cette dernière action effacera également la dépendance ubuntu-desktop, mais cela n’a aucun impact.

Virer toutes les références à pulse potentiellement présentes dans vos ~/.asoundrc et .asoundrc.asoundconf, puis dans System->Preferences->Sound, dans la section Devices, tout passer à Alsa.

On reboote histoire de tout remettre d’equerre, et HOPLAAaaa, dégage vieux “framework sonore” foireux.
Tout refonctionne par-fai-te-ment.

Comme on peut le constater sur ce suivi de bug launchpad, ça concerne un peu de monde.

Pour résumer, c’est pas gagné. Enfin pas pour le Héron Boiteux en tout cas. Mais on a bon espoir que d’ici Avril 2009 on ne passe plus pour des charlots quand un pote voit qu’”avec ton Linux présumément stable tu peux même pas matter deux videos youtube sans que ton navigateur crashe mOUAhahaha” – “oui mais c’est paske y’a pulseaudio qui… nan rien.”

Bref, en attendant un fix digne de ce nom, un des gars impliqués dans ce beau bordel propose une solution temporaire: virer la libflashsupport -qui est la machine-à-crasher-Firefox-, puis installer ce package nspluginwrapper de son cru. J’essaye sa solution depuis quelques minutes, ça a l’air de le faire.

</aigr>

Errno: 5 (Input/output error), write_g1 scsi sendcmd: no error

etc etc etc.

Evidemment, rien à voir avec l’application (gnomebaker en l’occurence), c’est wodim / ex-cdrecord qui perd le fil. Car en effet, si l’erreur est reproductible, elle n’apparait jamais au même moment de la gravure, ce qui a eu pour effet de cramer une bonne dizaine de CDs vierges.
Finalement, après quelques tests, plusieurs gravures ont fonctionné avec les parametres suivants :

Ajouter :

combined_mode=libata

Au menu.lst en parametre au noyau

Ajouter :

options libata atapi_enabled=1

Au fichier /etc/modprobe.d/options

Et finalement ne pas laisser la detection de vitesse de gravure, avec un graveur 40x, la gravure s’effectue (pour le moment) sans problèmes à 32x.

Je deteste ce genre de bidouille…

Errno: 5 (Input/output error), test unit ready scsi sendcmd: fatal error

ou :

/dev/scd0 is not a cdrom device

ou encore :

failed to IDENTIFY port is slow to respond, please be patient

Ou finalement, un cdrecord -scanbus désesperemment muet ?

La solution est cachée ici et ici. Ajoute l’argument combined_mode=ide à / aux la / les ligne(s) kernel du menu.lst et tout reviendra dans l’ordre.

update

Rapide le Héron, un upgrade proposé ce soir me fait passer en 2.6.24-17 et corrige le problème. Classe.

Je vois défiler l’apt-get dist-upgrade (du moins son pendant clicka-graphico-convi), et pressens moult emmerdes à la lecture de beaucoup trop d’unmet dependancies… mais bon, c’est démarré, c’est démarré, advienne que pourra.

Et c’est l’heure du reboot.
Et ça merde à plein tubes.

[ 227.335011] device-mapper: table: 254:1: linear: dm-linear: Device lookup failed

Ça, plein de fois. Je me décompose devant ce reboot misérable. Bon, honnètement, un minimum de recherche m’apprend que c’est le package evms qui met le bordel. J’étais pas en mode apprentissage, donc, j’ai jugé qu’un # dpkg --purge evms serait suffisant dans l’immediat.

Reboot, 2.6.22 fonctionnel.
# ifconfig -a

humm… eth1 ? bizarre.
# rmmod atl1 && modprobe atl1 (atl1 c’est le driver de ma NIC)… eth2.
Je deteste ce genre de truc.
Finalement, c’est vck sur #gcu qui m’informe que de nouvelles regles udev du type persistent-net.rules s’occuppent de gérer “intelligemment” l’association MAC – device. Moui. Bah en attendant, 75-persistent-net-generator.rules s’amusait à incrémenter le fichier 70-persistent-net.rules. J’ai reglé l’histoire en collant dans ce dernier une rule custom :

SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:1c:fc:80:a3:36", NAME="eth0"

Voila, ça, c’est reglé.
Hm.
Pas de X.
Prévisible.

J’ai une carte nvidia. Oui je sais, nvidia, mal, driver propriétaire, j’irai cramer en enfer et ce simple fait anihile tout ce que j’ai pu réaliser. Mais en attendant, j’ai une nvidia. Une GeForce 6600 pour être précis. Et devine quoi ? le driver X n’est plus nvidia-glx, mais nvidia-glx-new. Evident hein ?

Pour finir, de manière assez incompréhensible, l’upgrade m’a réinstallé Xgl (ou au moins réactivé), un petit # dpkg --purge xserver-xgl a reglé l’histoire.

Ah, un dernier truc, les applets relous.
Je sais pas pour vous hein, mais moi, /etc/network/interfaces, ça m’allait très bien. Alors le Network-Manager de mes deux là, c’est killall -9 nm-applet et trash du démarrage dans “sessions”. Et je ne vais meme pas m’attarder sur cette merde intersidérale qu’est trackerd pour lequel ils ont du se tromper de déscription, je pense qu’il s’agit simplement d’un consommateur de disque / CPU qui tourne sous forme d’applet. killall.

Moyennant tout ce beau merdier, ma Gutsy tourne, et mon NetBSD kvm aussi :)