5 juillet 2014

jackwsmeter - jack meter over websockets

14:51 - Code

Certainly I've been quite busy with work recently and a sane measure was not to spend my copious free time™ on computers; unfortunately that meant I didn't do much in GNOME since 3.12 got out. I handled the 3.12.1 and 3.12.2 releases, manned the booth in Solutions Linux in Paris with Luis.

Before getting back to GNOME, please welcome my pet project of the week, dubbed jackwsmeter. It's a way to transport audio input levels from jack over websockets. It's certainly not of interest for many people but it's been fun and I just pushed the code, http://repo.or.cz/w/jackwsmeter.git.

jackwsmeter screenshot

Boring screenshot

We will use it at Radio Panik to have an overview of the signal of various sources (studio 1 and 2, nonstop broadcasting system), and at various points of our processing chain.

As of GNOME, my jhbuild environment is up-to-date again (I experienced very few issues recreating it from scratch, that's terrific), I'm getting back on IRC, I'm looking at some bugs and patches, and with Matthias and others we are planning a release team BoF at GUADEC, we hope to get fresh blood in the team.

See you there!

3 octobre 2012

bin/recent

11:21 - Code

For quite some time the access to recent files has been put forward in GNOME, it happened even more so in 3.6 with a "Recent Files" view in Files (née Nautilus), that makes use of a new recent files backend in gvfs.

This is all very nice but my daily activities still involve a lot of command line usage, and I didn't find any way to mark as recents the files I receive via mutt, the text files I create in vim, the pictures I resize with ImageMagick, etc. That always bothered me at the moment I wanted to access those files, but then I just copied a copy of the file to a scratch directory I had bookmarked, and went on with my work.

Until yesterday, as I finally decided to fix that, and quickly put together recent, a command line utility that just puts the file it gets as argument in the recent files list. It's very simple, uses GFile and GtkRecentManager, and the code is located there: recent.c. It's so simple I guess many others wrote something similar, but here you have, perhaps it will be useful.

21 octobre 2009

An evening with threads

9:52 - Code

I noted on Monday how I have been working on jack mixer recently; to be honest I didn't do much work up to now, replacing some widgets, adding a preferences dialog, easy stuff.

But as I am starting to use it seriously I realized it didn't scale well, I would add five channels and it would burn CPU and memory in a terrific manner. Without much investigation I decided it was caused by the polling for MIDI events, and set out to fix this.

Well, jack_mixer is written in Python and C, Python for GUI stuff and C for jack and computer intensive stuff, and it turned out it's not possible to call back from a C extension to Python code, when using SWIG, so I got to write a manual binding, easy enough, and I got it feature complete quite fast, gaining good looking code along the way, from here:

mixer = jack_mixer_c.create("test")
print "Channels count: %u" % jack_mixer_c.get_channels_count(mixer)
channel = jack_mixer_c.add_channel(mixer, "Channel 1", True)

to there:

mixer = jack_mixer_c.Mixer("test")
print "Channels count: %u" % mixer.channels_count
channel = mixer.add_channel("Channel 1", True)

All was left was to replace the polling by a callback system, and it worked, then it crashed, randomly. And I realized I stepped in the dreaded thread country.

There is the main thread, it's Python, and PyGTK, but then there are threads created by jack, and the callback is called from one of them, from jack thread to Python, where the Global Interpreter Lock reigns, to PyGTK, where you should do everything in a single thread.

After much reading and pestering I believe I reached a working state doing the following things:

  • calling gtk.gdk.threads_init();
  • enclosing the extension PyObject_CallObject call (which calls a Python function from C) between PyGILState_Ensure() and PyGILState_Release();
  • emitting a gobject signal from the Python callback;
  • calling the GTK stuff from a function connected to that signal.

With all of that in place I can now turn knobs and push faders all I want, without crashing.

Unfortunately it didn't address the performance issue, which was in fact much simpler (some widgets were invalidated every 60ms, as their "value changed" computation was wrong).

Lessons learned (again): 1) don't jump to conclusion on the cause of performance issues, 2) it's possible to tame threads.

29 mai 2008

Le retour de Stamina

11:37 - Code

J'en suis arrivé à rêver cette nuit à une émission radio où les ennuis s'accumulaient jusqu'à me voir un rien irrité quand je découvrais qu'il n'y avait qu'un micro pour trois personnes, irritation qui se transformait en totale lassitude quand une note était passée signalant qu'on s'était trompé dans les dates, qu'il ne devait pas y avoir d'émission ce soir-là...

Et je me dis qu'il y a peut-être moyen d'y voir l'influence des problèmes récurrents rencontrés à la radio ces dernières semaines, même si d'un autre ordre, principalement en rapport avec le système de diffusion automatisée (par la suite simplement référé par l'appellation « nonstop »).

Coccinelle sur façade

Bruxelles, 20 mai 2008

Le logiciel libre, c'est super cool, ça veut notamment dire qu'on peut adapter le logiciel à nos besoins particuliers et en corriger les bugs nous-mêmes. Malheureusement ça ne se fait pas d'un coup de baguette magique...

On a commencé à utiliser soma il y a plus de deux ans, j'y ai corrigé certains bugs flagrants (ah ah, pas moyen de programmer quoique ce soit pour le 31 du mois, avec un message d'erreur affirmant presque qu'il n'y a jamais que 30 jours dans un mois) et ai ajouté certaines fonctionnalités par la bande (modification dans sa manière de stocker les logs, et utilisation de ceux-ci pour générer une archive de la diffusion). Mais l'adapter à notre mode de fonctionnement, assez différent semble-t-il de cette radio italienne où le logiciel a vu le jour, cela a toujours été vu comme une tâche trop importante, alors on a fait avec, contournant des problèmes de manière pas toujours très élégante.

Mais vraiment, tout le monde était quand même assez content des services rendus, jusqu'il y a quelques semaines, où un crash qui n'était arrivé qu'une ou deux fois est devenu bien plus fréquent, me valant appels téléphoniques, « soma est dans les choux », à dix heures du matin comme à dix heures du soir.

Du coup j'ai décidé de prendre un peu de temps pour investiguer, ulimit -c unlimited, exécution depuis gdb, mais que dalle, il y a bien une segfault à un moment, qui entraîne par la suite une boucle infinie consommant le CPU, mais pas la moindre trace laissée et qui pointerait vers la cause.

Page de notes

Notes prises rapidement, la nuit

C'est ainsi que je me suis dit que je devrais sortir de ses cartons Stamina, le logiciel de substitution que j'avais commencé à développer, début 2007, et cette idée qui était très vague, qui aurait pu être très éphémère, elle a terriblement pris forme hier soir, dans les rues vides de Bruxelles la nuit, et une fois rentré chez moi, je griffonnai bien vite mes réflexions.

Reste maintenant à trouver un rien de temps pour implémenter tout ça, mais j'ai remodelé cela pour au plus vite pouvoir arriver à quelque chose, donc j'ai quand même un peu d'espoir et suis prêt à assumer n'importe quelle remarque qui pourrait se faire lors de l'assemblée générale de la radio, ce soir.

15 mars 2008

Pas une prophétie auto-réalisatrice

20:17 - Code

À porter l'oeil sur les projets Mozilla et OpenOffice.org, quantité de similitudes m'apparaissent, la première évidente à tout le monde, il s'agit de deux projets phares de l'open source, cent fois cités en exemple, principalement du fait qu'ils ont énormément d'utilisateurs; utilisateurs qui sont par ailleurs majoritairement également utilisateurs de Microsoft Windows.

Techniquement, d'autres similitudes, une base de code énorme, d'origine propriétaire, et liée, l'utilisation d'outils n'étant pas les standards des autres projets libres (pour les systèmes de build et de traduction, par exemple); aussi l'utilisation d'un toolkit graphique spécifique, et imitant tant bien que mal le « look and feel » d'une application native.

Socialement, trois points : la part qui a toujours été importante de personnes salariées pour travailler dessus, les processus complexe d'acceptation de contributions extérieures, et surtout les processus de décision, d'orientation du projet, eux aussi complexes.

Le projet Mozilla, il a clashé avec Debian fin 2006, et arrivait un commentaire récurrent, « la version que vous distribuez n'est pas la version officielle, vous appliquez des patches qui font qu'elle crashe et vous nous donnez de ce fait une mauvaise image »; ce commentaire, basé sur un argumentaire technique (les patches), a alors été démonté par le mainteneur Debian), ce qui n'a empêché personne de continuer à le répéter, mais bon...

C'est en pensant à cet épisode que je lis, à propos de la version d'OpenOffice.org distribuée par Ubuntu : « Le fait qu'il n'y ait pas d'assurance qualité ni de localisation des fonctionnalités ajoutées sur ces versions les rend très instables et donne une piètre image de notre produit. » (source).

Et ici de ne pas vouloir, dans six mois ou dans deux ans, me souvenir avoir eu raison, en attendant que le splashscreen d'IceOffice disparaisse.