A misc weekend

So today is the first week without Gentoo work for me. I admit I feel a bit disappointed, I used to do a lot of stuff and now that I can’t do them anymore (for my choice too), I feel like I’m useless. But I’m resisting the temptation to feel my overlay with a lot of ebuilds for the bumps that I would have done myself previously.

First of all, I wish to thank the anonymous “bla” who commented on my previous post about the lack of analysers for the usbmon output, suggesting me Wireshark. I really didn’t know they were working on supporting USB sniffing, and yes that is nice and stops me from deciding to write an analyser myself. Unfortunately, the current weekly snapshot of libpcap and the current subversion trunk of Wireshark does not get along well together: they simply don’t allow me to sniff at all, I get a series of errors instead.

Talking about the Chinese adapter, I found something on their site but I’m not really sure if it’s a specification or simply a description of the driver interface. Nonetheless, I’ve been able to identify a few patterns in the logs I was able to get with usbmon (analysed by hand), and I now know two major type of commands that are sent to the device: a pair of set and get commands used to set and get a 16 bit word out of at least three «registers»… I’m not sure if they are registers at all, they only are three 16-bit words which have another 16-bit word assigned to them, and which is set and get with some vendor-type requests. Unfortunately, I haven’t been able to get a hold of their actual meaning yet.

I’ve also found a sort of “commit” request, or a “get internal status” command, that tells me I haven’t initialised the device correctly yet: when handled by the Windows drivers, this request always return 0x9494, while here it returns values like 0xf4f4 or similar, never the actual 0x9494 word I’m expecting.

I didn’t work on Rust in the past few days but I have been thinking a lot about it, as David is being the first user of it, and submitted me a few reports of features currently missing, which I didn’t think of before, namely support for multiple constructors, and proper support for sub-classes. I haven’t worked on this yet, but I’ll do soon. He also provided me a patch that I merged, but I’ll have to write a series of testcase for that too, so that I can actually be sure that Rust continue behaving as needed.

Today I also decided to look a bit more on xine, as lately I’ve been neglecting it a lot. I’ve tried to cleanup my Wavpack demuxer a bit more, and I just finished a Valgrind (massif) run while playing two wavpack files one after the other. The results are somewhat interesting: xine does not leak memory, as the memory consumption remains constant between the two playbacks, but it also seems to allocate about ten megabytes of memory in _x_video_decode that are not used at all, as I’ve disabled the effect plugins, and so there should be no video at all. About seven more megabytes are wasted in the overlay handling, which also shows that the video output is not correctly disabled while playing audio tracks, with xine-ui at least.

I’ll be running a callgrind now also to test where time is actually lost, it’s good now that I have KCacheGrind displaying properly the callgraph, thanks to Albert Astals Cid (TSDgeos from KDE). One thing that I’m afraid of is that xine does not really have good performances on lossless files because it uses too small buffers, at least by default; I have this doubt because while mp3s play mostly fine – with mad decoder, not FFmpeg’s – it skips a lot for both Flac and WavPack files. This is especially seen when you run it through Valgrind, as the code is obviously slowed down and shows the need for improvements.

If only there was support in ruby-prof for Valgrind-style output to analyse the output with KCacheGrind, I could be improving Rust too. But that will have to wait I’m afraid.

Oh well.

xine gets improved WavPack support

It’s 6:35Am, I’m still awake, and I worked the whole day and night on xine-lib, so let me try to show what changed there of nice, so that I can also drop some of the negativity going on.

First of all, I stated fixing the WavPack demuxer so that it shown the correct duration and playing time of the stream, this way also Amarok stops going crazy when WavPack tracks are present in the playlist. This was the easy part.

Then, I decided to try again writing a WavPack decoder that used directly the WavPack library rather than FFmpeg. Why this? Because FFmpeg has a few imitations at the moment when WavPack is concerned, for instance it does not handle at all the multichannel WavPacks. I started working on WavPack support in July, but I was never able to get anything working until FFmpeg got WavPack support, and then I limited myself to a demuxer plugin, so this was the time to restart my work.

I’ve decided to make a single plugin fo both demuxer and decoder, so that you don’t have two different plugins to load, both using libwavpack. To do that, though, I had to shuffle around the demux_wavpack.c file, so i lost a bit of history; luckily the demuxer was young enough not to have anything important in there.

I had to fiddle quite a bit to get the demuxer working, because I have to pass between the demuxer and the decode entire blocks of data, and I need two different sets of wrapper functions that mimic filesystem access (seek, tell, read, …), one that used xine’s input framework, the other using a simple buffer access (for the decoder). I had some trouble because I lost a bit of focus while I was working on it, so I made some stupid mistake that asked me to rebuild the code a lot of times before finding the cause, and I wasn’t really able at the end to get some PTS support working.

About at 6AM I was finally able to play Hikaru Utada’s Passion from my own WavPack rip of the single album (thanks again Ben for it :) )… being my first xine decoder from scratch, I felt so excited that it finally worked, that I cannot even sleep now about an hour later.

Of course the work is not complete yet, I’ll have to spend a little more time on xine-lib to complete things like Seeking (currently totally unimplemented), and I plan to remove FFmpeg Wavpack decoding support today as soon as I wake up after taking a few hours of sleep. This is because FFmpeg requires the frames to be passed with the last 12 bytes of the WV header (which would be otherwise 24 bytes), which is incompatible with WavPack library requirement of having all of them; right now, the decoder is forging a WavPack header while reassembling the frame, and more or less works, but there are two cases where this method will not work.

The first case is when the WavPack version is updated; currently I’m setting the version to 0x0406 which is the generic version created by WavPack 4.40 utilities; it might not be the same version as the original WavPack file though, so it’s probably not always working as intended already; the second case is with multichannel WavPack files. WavPack files support multichannel data by interpolating stereo and mono frames that covers up to 6 channels easily. It’s not difficult to handle, as the streaming mode of the library will just convert the three blocks composing the 6 channels into one single decoded 6-channels frame, but to do so, I need to pass more than one actual frame in a single xine frame, and so I cannot use the 12-bytes trick anymore.

Considering that FFmpeg does not handle multichannel files, and that requiring half of a frame’s header is quite silly (either you require the header or you don’t requiring half of it is pointless, even if the upper half is not used), I’ll easily get rid of FFmpeg WavPack decoding if that brings me a working multichannel decoder using the official library. It’s not even an additional dependency at build or runtime, as the library was already needed for the demuxer alone (it’s quite complex to write a new demuxer, or better, it’s quite long and boring to do so, it’s probably simpler than writing a FLAC demuxer).

Another planned feature is support for basic tags reading so that it can actually appear in xine, but for that I’d rather think about writing a tag reading implementation in xine-lib itself, as WavPacks like MP3s and MusePack files would use APE tags, so it’s pointless to repeat the same implementation over and over. I considered for a moment TagLib, but I refuse that idea at the moment.

Multichannel output

And so back I am discussing my problems with multichannel output with ALSA. Seems like my odissey will last more than I foresee.

So it seems like either I was under drug usage when I was sure that speaker-test is able to send 6 channels output, or via82xx did play trick with me, and encoded it somehow on the fly before sending it through opto out, as it just seems technically impossible to get 6ch PCM output through optical output. Anyway, the point is that it doesn’t work and probably no other card, without using on the fly encoding in AC3, will give me that result.

So, no reason to waste money on a new soundcard, and I’m trying alternatives. The first alternative that came to my mind was to use the a52 plugin for ALSA, present in alsa-plugins, that allows to encode on the fly to AC3 to send to the amplifier, which would decode and play over the 5 channels. Even if it’s a lossy-to-lossy compression most of the time, it shouldn’t be much of a problem on its own. The problem is that, well, it simply wouldn’t work, as it segfaulted inside FFmpeg code. A quick look around told me that ALSA developers need to start reading documentation of the libraries they use, as they weren’t initialising libavcodec at all. Two-liner patch and I’m back on the road. (for who’s wondering, the patch is applied now in alsa-plugins-1.0.14_rc1-r2, while the ffmpeg useflag that was present before has been removed in all previous ebuilds, to avoid users hitting the bug).

So, with on-the-fly ac3 decoding, the situation is a bit better, I can actually play a 6-channel wave file through aplay, and it plays on the rear channels just as well, which is good. But of course, talking about ALSA, it couldn’t be that painless. So let’s see what the problems are.

First of all, when encoding to ac3 you’re using the S/PDIF output in exclusive dedicated way, (if you have a VIA card, this means that the IEC958 Playback AC97-SPSA control in the mixer is set to the higher level, rather than the lower you need to play stereo sound through it), meaning you cannot do neither hardware nor software (dmix) mixing, like if you were using iec958 (because in fact it is using the same output method); for this reason you still need a software mixing daemon like PulseAudio to be able to play more than one multichannel stream at once. This is also true for soundcards that have hardware mixing, like emu10k1- or emu10k2-based cards.

The second problem is tied to PulseAudio, that as I said would be needed to be able to play more than one stream at once. «Would», because it simply won’t work at the current status. As ALSA does not provide a CTL plugin for a52, but only a PCM, the virtual device wouldn’t have a mixer (it’s right), and somehow this leads to the crash of PulseAudio it seems (the crash is, of course, in alsa-lib code). I’ll have a «good» time trying to get a hold of this, I’m afraid.

Now of course, being finally able to have 5.1 output, and having some 5.1 audio samples, is quite interesting for me, as I can test them with xine (and FFplay) so that it can finally play WavPack 5.1 :)

The ZFS tale

Wonder what? I cannot sleep tonight either. I think my biological clock is not totally broken, and I cannot get to sleep at all. The nasty thing is that I’m dead tired, maybe too tired to sleep, and that is driving me crazy because I want to sleep, today like I didn’t in the past months. And the bad thing is that I’m supposed to go to the mall later on today with my brother in law, as I need to pay the last month of the old iBook, and look up a decent bag for the new one. You close one circle to open another sometimes.

Of the long TODO list I had yesterday, I wasn’t really able to make much; the hope to watch a movie while lying on the couch vanished easily, as I’ve started taking care of a few things. For once, I wanted to be able to compile and run pan on Gentoo/FreeBSD, for the pure sport of fixing things while I’m at it (actually, gmime was fixed already by upstream, so I didn’t have to patch it at all at the end, thanks to Ticho who simply bumped it). I didn’t have time to look at nss-mdns, and I now seen that there’s a new release too (I hope that 0.9 won’t break my patch too badly), but I had another entry on the TODO list that was interesting enough to prioritise over the rest for a day at least.

[Now of course, even tonight, like last night, and the night before, and three nights ago, my cat had to come in my room to see if I was awake, until I brought her down, and gave her an old shirt of mine – that I was already going to give her as it was kinda ruined now – which lowered my hopes to be able to sleep soonish… at least I drank two glasses of white milk, it might make me sleep better]

So what is the interesting thing that fascinated me away from finishing the port of nss-mdns? It had to be something cool, or I would have preferred helping FreeBSD devs for sure ..

Well, Astinus pointed me to a patch to FreeBSD -CURRENT to support ZFS natively; considering that FreeBSD does not have license problems with using cddl code in the kernel, it was interesting for them to integrate. I looked at the patch and the main issue was to break it down into a kernel patch and an userland package, so I started working on that, with Astinus who’s gonna be the test moneky for it :)

The results aren’t totally ready yet, as I was able to get the kernel patched, but not the userland to compile; I haven’t tried compiling the kernel y et, neither. The main issue is that the userland not only requires the patched kernel, but seems to rely on some compatibility support that was probably added to 7-CURRENT, so I have to work it around to get it working on 6.2, but it seems to come out nicely up to now.

For what regards Klothos, still missing a way to parse and interpret the coredump, I’ve decided to get a try to make catalyst build a new stage of that too, with the libedit problem fixed. The main problem that made me gave it up before was that it had to load the nullfs module, that caused the Kernel to panic, as I told already; by building nullfs inside the kernel, I can make catalyst work for the time being. Unfortunately when I started looking to start the catalyst build there, I got in a fight with my soundcard, that required me to shut Enterprise off (which shared the Portage tree I was going to snapshot at the time).

Now there are two things I want to talk with in this blog entry, before the end. The first is the soundcard fight and the second is a problem with the Gentoo/FreeBSD 6.2_rc2 stages that Astinus pointed me at.

Starting with the second, that is more interesting to users, there seems to be a problem with the Portage version shipped with the 6.2_rc2 stages I released a couple of days ago; that version of portage is unable to create $DISTDIR if it’s missing, so fetching packages will fail until you create the directory yourself and give it to portage user and group; to fix this issue, I now have Prakesh doing a new catalyst run for a stage3 only (stage1 and stage2 are byproducts of the process to create the stage3, I publish them for completeness as releng does so, but I won’t support them anyway), so that it can be refreshed on mirrors and I can tell Jeffrey to remove 6.2_beta3 too to avoid wasting space :)

And if you didn’t already notice, nightmorph updated the Gentoo/FreeBSD Installation Guide that now covers the 6.2 stages (built with Catalyst and with baselayout 1.13), and the problems with the partition being created as ad0s1d rather than ad0s1a. Thanks goes to him who updated it in a matter of hours from my pretty long and boring mail.

For what concerns my fight with the soundcard, I have to say I came to hate not only ALSA but also the via82xx driver; the former because the new kernel release is, surprise, breaking alsa-driver again, so unless upstream this time is nice enough to give me an rc2 before the new kernel is released, I’ll have to resort to a snapshot once again; the latter because I wasn’t able to get it to work on 6 channels in any way.

Let me try to explain: John Myers commented on my previous post giving me a command line that actually works to extract the audio tracks of a DVD with mplayer (<tt>mplayer dvd://[<title>] [-chapter <start>[-<end>]] -vo null -vc null -ao pcm:fast:[file=<filename>] -channels 6</tt>), thanks John a lot, it works as a charm!

The extraction works, WavPack encoding works (besides, thanks Timothy too, for pointing me at the ability of wavpack command to set the metadata on ripping, now I can rip my next CDs without having to tag them later with Amarok!), but I cannot play the files. Audacious doesn’t support multichannel WavPacks, FFmpeg (at least the version in portage) does not demux them correctly, and also mplayer fails to read them (because it seems to use FFmpeg’s demuxer for them); the best result I got with xine, that plays them although very garbled, I suppose I can be proud of this :)

While trying to find what was causing the problem, so that I could try to see if newer FFmpeg works, or if I can fix it myself, I tried to see if the original multichannel WAV file was playing correctly… but aplay was able only to give it to me in 2 channels. I tried every configuration and every choice, but my via82xx just plainly refuses to play more than two channels unless I use IEC958 passthrough and an AC3 or DTS track. The speaker-test does not work (it used to last year, at least I think I remember it did), it does not even do more than one channel when I point it to hw:0,0, while surround51 has the appearance to work, while it only outputs on left and right channel, as usual. I start to hate that card, not only it does not work as intended now, but it also requires me to shut both the computer and the external amplifier down to reset if I crash something down (in my last case, the a52 ALSA plugin), so that not even iecset can reset. I’d really like a decent soundcard, but I’m not even sure what I should look for; tsunam and nightmorph suggested Audigy2 ZS but I can’t even find them on ebay at a first glance (let alone finding them in a shop), and the newer Creative cards are not supported at all. Suggestions welcome.

Rip, rip, rip

Well, today I have a pretty long TODO list that I’d like to accomplish, although at the top of my list was also to watch Ice Age 2, while relaxing on the couch, that would probably stop me from finishing any other entry on that list… so I’ll remove that one for now. After all yesterday I as lucky, and tired, enough to watch Pirates of the Carribean (which was, by the way, a quite good movie, especially for someone like me so fascinated with swords of all kinds, thanks Alberto for «forcing» me to watch it ;) ).

I also tried to get pan (not PAM this time) to compile on Gentoo/FreeBSD, but after fixing enchant, I found myself stuck with gmime, as that needs a patch too but I’m not sure how to handle it yet (there’s an extra _POSIX_SOURCE that breaks on FreeBSD). I’ll fix this later on today.

Also Bruce M Simpson from FreeBSD contacted me about the nss-mdns port, so I’ve resumed looking for it, I’ll tonight if I can apply what I found today in the sources to get it working somehow. I don’t think it’s too difficult, it’s just scarcely documented.

But in this whole lot of stuff to do, I was hoping to relax by listening to some music.. something I wanted to try, was to rip the 5.1 tracks out of the Rhapsody’s Live in Canada 2005 to compress to WavPack so that I could listen to it through Amarok (one of the reasons I had was also to test the WavPack 5.1 support in xine/ffmpeg and the ability for PulseAudio to play 5.1 files from xine). Unfortunately, even if there are tricks with mencoder to dump the audio of a track through mplayer to an ac3 file (no way to get it through a GUI it seems), I can’t find a way to pass it to wavpack, as both ffmpeg and a52dec produce a stereo wav file, rather than a multichannel one, and WavPack does not work with AC3. I suppose my best bet would be to code myself a bridge between the two, but I don’t have enough time. Sigh.

Moving from FLAC to WavPack

Some of you might have noticed that I blogged about adding WavPack support in xine ; now I’ve also committed to the tree the ebuild for a new CVS snapshot of xine-lib with WavPack supported. The reason why I did this cvs snapshot rather than asking for a new xine-lib release next week (thing that I’m still thinking about) is because one of my additions to this release, a sanity check for the symbols used by the plugins being defined at link time, so that they will fail during build if symbols are missing rather than die on the user at runtime, requires a bit of testing. Compiles both on my systems and on Debian’s buildhost already found some missing link lines that are now fixed, but I cannot really test all the possible combinations. For this reason, the ebuild is now in Portage under package.mask.

Now, to use WavPacks easily with Amarok, you also need TagLib to support them.. luckily aumuell found on the Net some TagLib plugins, now imported into Amarok, that support both WavPack and TrueAudio (the other lossless format I added support for in xine-lib in the past days). The patch is applied in the repository and will be released with version 1.4.5, but for my own pleasure, I’ve patched 1.4.4-r3 in my overlay to add those plugins, as I wanted to be able to test WavPack as much as I could. The result is really good, the plugin works well both in reading and writing APEv2 tags on WavPack files.

Now, I wanted to give WavPack a better go… when I first implemented OggFlac support into xine-lib, I got in a really bad fight with the FLAC format for the use of 3-bits 7-bits and 22-bits fields that are a mess to read without implementing a bitstream parser altogether (which is not practical to be done when the most of the reading is done at byte blocks, rather than bits, like a demuxer does usually), and having the choice of backing off it, I wanted to try it.

Well, I’m satisfied with WavPack way more than with FLAC; encoding a CD Rip (I rip my own CDs, as I want to listen to them with Amarok rather than having to change the CD every time) takes a fraction of the time needed with FLAC, and the files are smaller; now that xine and Amarok supports it, it’s worth the hassle.

Of course, WavPack is not at the same level of FLAC yet, at least when it comes to popularity: neither KAudioCreator nor ruby-ripper have a preset to rip to WavPack, the wavpack commandline utility does not allow you to set APEv2 tags, ls does not recognise them, nor does GNU file, nor KDE’s mimetypes, but it works quite fine to me.

As no commandline tagging application besides Amarok (edit: Lukáš Lalinský pointed out that there are taggers for WavPack files.. unfortunately I was too sleepy when I wrote the entry and I didn’t specify, I meant commandline tools.. and I was sidetracked thinking that Amarok had a DCOP interface for tagging files… instead it was JulTagger I was designing the DCOP tagging interface… so here it is what I meant :)) seemed to be available for WavPack files, I’ve resumed my work with RubyTag++, even if it’s still half broken due to TagLib being incomplete (and Wheels hasn’t released the long promised 1.5 yet), and started adding the support for the extra plugins found in Amarok…

The result is quite nice to me, as I now have a simple script that decompress a flac file, re-compress it in WavPack and copies the basic tags from one to the other, so I could transcode my whole library from FLAC to WavPack, sparing about a gigabyte out of the total (23/22GB) of my music collection.

I’m planning to release in the next days the first alpha of RubyTag++, and then start shipping at least some commandline tool to allow tags manipulation, and hopefully resume work on JulTagger soon too.

And now a little question for my readers: what should I do with MTP support being now lingering? Seems like no interested dev has a MTP device to test with, and after Thomas retired, the libmtp package is also unmaintained. I’m not that keen on buying myself an MTP player just to test Amarok (especially since my cellphone – well, the broken one I have to get repaired – is also an MP3 player of tis own). Is anyone available to be a tester/maintainer for MTP stuff?

I’m no Santa…

But I do have some presents for my users.. First of all, the CVS version of xine-lib now has a lot of fixes for those bugs that were reported on SourceForge and I could fix. And as second present, it now plays not one but two new lossless formats: WavPack and True Audio; the first depends on the wavpack library to demux the files but uses FFmpeg to decode the audio stream, while the latter uses a standalone demuxer and again FFmpeg to decode.

I was working on getting WavPack to work since at least last July, being finally able to play those files made me very happy… I hope also my users will be happy. Also a big thanks to aumuell from Amarok team who’s working on getting their internal TagLib plugins to read tags for those formats, too, so that Amarok will support them entirely.

While bragging about the two new formats supported in xine on #amarok, an user also gave me a MusePack file that doesn’t currently play with xine.. The problem was that it used a misterious SV 7.1 version that wa skipped by xine.. Fixed now by accepting 7.x versions. And again while fixing this, I noticed our current musepack software status being bad and thus decided to update it. So libmusepack, the obsolete name for 1.1 series of the decoding library has been masked, pending removal next month, in favour of libmpcdec; and I added mppenc, that replaces upstream the musepack-tools package, although missing the player, that now uses cmake… As the mppdec sources are not available upstream, I’ll add mpc123 for who needs a commandline player.

Don’t forget to fight for your rights to be able to use a namely free software by mailing Nero, if you didn’t already.

On a slightly bothering note for me, my DVD±RW seems to be giving up.. I couldn’t rip the Ireland CD a friend of mine gave me for Christmas into FLAC files, and I’m not sure if it depends on the reader or if it’s FLAC not working as it should.. I should probably try with WavPack or True Audio (if I can find a TrueAudio encoder of course) so that I could also use the new features in xine and Amarok :)

Working on the infamous Wavpack…

.. plugin for xine.

As my sucky ISP has something wrong with international routing, that makes it impossible for me to get a full cvs up of the tree, and blocks my attempts to read Userfriendly, I’ve decided to spend some more time on xine trying to get more into the internals.

In particular, there was that idea of writing a wavpack plugin, as xine right now does not support that particular format. I originally started writing an FFmpeg demuxer, but ended up not having a clue of how split the stuff to pass to the decoder.

I then started looking into writing a demuxer and decoder for Wavpack directly in xine-lib, by using libwavpack. After a night of working on that, I can tell it’s not a good idea. The library is a big mess; to start with, it has a wrapper structure that wraps around file access, allowing to read a stream out of a buffer too, which ain’t that bad on its own (actually was quite simple to write a version that works using xine’s input plugin stuff), but it assumes 32-bit everywhere, which means that it won’t work with largefiles (>= 2 GiB). There’s no decoding function that can work with a raw buffer of bytes, all need the same context used for reading the file, which makes the decoding using libwavpack a lot tricky.

I’m afraid that this idea is going to take quite a bit more of time than I expected, as I cannot really rely on libwavpack too much, so I should probably write some routines to handle the whole format from inside xine-lib itself, and that becomes a major problem considering I have works to handle.

Oh well, sooner or later something will come up.

The missing bumps

So, I think I didn’t focus too much on Gentoo in the last couple of days, but don’t worry, I’m catching up ;)

First of all, I’ve already bumped k3b finally (I was actually waiting for carlo as he’s the one who usually takes care of it, but right now it was a bit too much to wait, and it had FreeBSD fixes I wanted).

Now I’m compiling KDevelop 3.3.91 (3.4 beta1) that will be in portage soon enough. I want to look at it as it’s promising well.

Later I’ll add a new snapshot of xine-lib, still waiting for the 1.1.2 release (damn I wanted it two weeks ago :?) and I’ll add one of xine-ui too as there are a few fixes that might be interesting. Yesterday I also worked to fix a few format-string related bugs to both so that now they are safer than ever :)

Remaining in theme of multimedia, I’ve also been sending a few patches to FFmpeg to try to cut down the patches that xine-lib has to apply over their code, and to try again to proceed on the visibility patch. I think I’ll end up being hated again, but I’m stubborn enough to rework patches and resend them even 10 times :P

I’ve also started looking to write a wavpack decoder inside FFmpeg to start with, before trying to do the same for xine-lib. The next stop would be having a TagLib plugin for it, but it’s likely to take a while, as for instance the first about that is to move the extra plugins from Amarok to their own package, but for that I want to wait 1.4.1 release, and having a bit more time.

I haven’t been able to set up a GNOMEish chroot yet, although I did use a chroot to work on openmotif, which last version should build in a more acceptable way. People using PPC or other platforms with problematic strict-aliasing bugs are suggested to rebuild last version.
For people using libquicktime and experiencing problems, a re-emerge of latest ~arch is suggested rather because I “riced it down”, by making it not try to use the CFLAGS it wanted, but the ones that users choose, in particular it used to build with “-O3 -funroll-all-loops” that in some systems produce non-working or slower code.

Finally, a suggestion that I got from Plasmaroo but might interest other people too ;) When I moved to emacs I continued to use vim for quick editing of configuration files, because it’s simpler to use “sudo vim”, and cannot mess with configuration files, emacs I wouldn’t trust to run within sudo as it has its own configuration and I don’t want to break it. A good replacement is zile, that’s a minimal replacement that do exactly what I need: edit configuration files quickly :)

Too hot

Today is too hot for me. And I mean it.

I hate summer and I hate heat, I hate when the temperature comes near the 30°C, and I hate the 90% humidity I have.

Today staying in my “home office” is difficult, and now I really can’t stay there anymore.
I ended up taking out my shirt and now I’m on my bad in my room, with the iBook.

Developing today is not possible, too hot to stay there, too hot to pass the whole day in front of the monitors because of the humidity. I worked on unieject this morning, and that is enough for today I suppose.

Actually, I also took some time to fix the licenses of my software, to update to latest GPL and LGPL texts available, and to update the address of FSF on all the files.

Now I will probably just find some time to hash out some documentation on gitarella, to release the first alpha alpha version, that at least might show some interest on that. It works basically, and that is what I wanted for it for now. Future development might make it use also SCGI, who knows? :)

My idea of adding WavPack support in xine seems to have changed a bit, Luca suggested me to rather write an ffmpeg plugin, so that the files would be played directly with it, but to that I should also add to my list the creation of a demuxer plugin for xine-lib (or it won’t be able to play wavpacks by themselves, but just wavpack streams) and a TagLib plugin inside Amarok to be able to get the metadata.

I’m afraid I won’t be able to take out much of useful by this pace, mainly because I never did anything like that in my life, and the time I can pour in that is strictly dependent on the free time I can get, and that is likely to be too few as I need a new job to be able to have enough money for the university.

Oh well, we’ll see.