Amarok Blog

After a week spent closing envelopes and attaching labels, I was finally able to get the audio conversion branch of xine-lib 1.2 to play mp3s.

As libmad decodes the mp3s as 32-bit signed integer samples, the direct output cannot be sent directly to PulseAudio when playing it back (and PulseAudio is the only audio output I converted to the new plugin API), so I had to actually implement at least some basic conversion, in this case from almost every integer format to 32-bit floating point samples (which is the simplest conversion, although it’s CPU consuming.

Previously every mp3 file decoded with libmad was truncated to 16-bit signed integer samples, losing precision, and for what I can see amplifying the volume quite a bit, distorting the signal, but with my new code, there’s no precision loss, and the difference is audible.

You can see the difference in the following screenshot:

If you look at the screenshot you will see the stream info dialog windows of xine-ui: on the left there’s the window for xine-lib 1.1 while on the right there’s the one for xine-lib 1.2 audio_conversion branch. As you can see at the bottom of the window, the first one reports 16-bit for the stream, while the new one returns 32-bit as intended.

I can tell you, the difference is great, and this is just the first step! Hopefully it will be merged in xine-lib-1.2 and then it will be able to play hi-fidelity wave files just fine.

Unfortunately before I can actually merge this branch into main xine-lib-1.2, all the output plugins, the post plugins and most of the audio decoding plugins have to be ported, which is a HUGE amount of work for just one person. I’d also require to use some virtual machines to confirm most of the output plugins work afterward, so it will take me a lot of time alone. If you can handle converting and testing the code, that will certainly be appreciated.

I’m not sure if you remember, but last Christmas I blogged about my need to find a way to allow my smartphone (a Nokia E61) to automatically accept the certificate file for my IMAP server, to avoid having to accept it every time when I want to check my mails.

Well, I originally thought it was just a problem of format, as a lot of places on the net talked about the need to convert the PEM certificate to a DER certificate, and then download it with the internal browser from a properly-configured webserver (properly meaning the certificate is served with the mime-type application/x-509-ca-cert), but then it wasn’t enough, I thought it was a problem of size of the certificate (over 1024 bits it doesn’t seem to be supported) but it wasn’t the case either, and the last idea I had was that the problem was with the firmware version.

Unfortunately last month when I asked a friend of mine to help me updating the firmware on the phone, the download process on his laptop (with Windows XP) took more than three hours, then we shut everything down, as it was coming late, and the download wasn’t complete yet. I tried upgrading through a (demo) version of Parallels Desktop for Mac OS X, but it didn’t help either, today I tried on vmware-server, and there it worked fine, without the problems with disconnection and reconnection of the USB device that Parallels suffered from (probably while the device was being reconfigured to provide a different interface to check the phone model, serial and firmware). The firmware upgrade process went fine and easy, in about thirty minutes just like Nokia wrote on the site, I’m not sure what was wrong with my friend’s laptop, nor I care much at this point, if I have to be blunt.

But, not even the firmware update helped me.. so I decided to investigate further: the posts on the web about the configuring the E61 (or the USA-marketed E62, which should just be a crippled version of mine) mixes information about the addition of extra Certificate Authority certificates with requests for help with self-signed certificate. As soon as I considered this, light shed into my mind and I found the problem: the Nokia E61 does not support self-signed certificates; this is an absolute, and there doesn’t seem to be a way to get around this. What you can do instead is create your own Certificate Authority, load that certificate on the smartphone, and then use it to generate your own SSL certificate; this solved the problem for me entirely.

If you need an easy way to build a certificate authority certificate, and to create a new certificate signed with that, you might want to look in the openvpn’s sources’ tarball, that contains an easy-rsa directory with a series of scripts that really helps on that matter.

By the way, the reason why I updated firmware was also to enable the VoIP features, so that I can have a landline-like number routed on my phone while I’m at home (or anywhere where a WLAN can be found) allowing me to receive calls directly without passing through my family’s number.

Classically, usb.ids file can be found at http://www.linux-usb.org/usb.ids unfortunately there doesn’t seem to be any more updates after last December. I sent to Vojtech a few patches to add the devices I have here at home, but I didn’t get an answer (I know Vojtech usually answers in a day or two).

Since I hate seeing stuff getting obsoleted so easily, I’ve decided to add a bunch of devices to usb.ids, fix an entry (the one for APC UPSes, as now I have two of them to cope with), and maintain my own copy of usb.ids.

Most of the devices I’ve added are things that I have here at home, but they are not limited to, I’ve added some USB sticks of friends of mine who happened to pass by here, and an entry for a Microsoft mouse from Timothy. I suppose that while usb.ids is not fixed in the original location, I can continue maintaining it for my systems at least, by changing the cron jobs’ path to fetch from (it’s also pretty much useless to download the same usb.ids every month).

So my copy of usb.ids is located at http://dev.gentooexperimental.org/~flameeyes/usb.ids (thanks Patrick for the hosting, which I’m also using for a few other stuff like dist tarballs); if you want to add more devices to the list, feel free to mail me at flameeyes@gmail.com with a diff -u, or simple the vendor and product ids of the device, and the complete naming of it.

I know the hardware from the MacBook Pro is missing, I’ll see to add those the next time I boot the laptop on Linux.

As I bought the new UPS, I now have quite some time to work with it while I’m without power, as the two UPSes can keep the system online for about one hour without any kind of interruptions, included network access. This is quite nice, but there is one thing I was thinking of today…

When the workstations are running on UPS’s battery power, it’s comparable to a laptop running on battery, so I could be just using the same method laptops use: reduce the frequency of the CPU. At least Enterprise is able of CPU frequency scaling, so I’ve configured it to switch to power saving profile when the onbattery event is received by apcupsd.

It was actually quite simple, first of all apcupsd runs as root (although it should drop all privileges, but I’m not sure about it), and I have powersave installed and configured to handle this, so I just changed the /etc/apcupsd/onbattery and /etc/apcupsd/offbattery scripts to add a call to powersave binary, with -e Powersave on the onbattery event and -e Performance on the offbattery event; unfortunately I don’t think there is anything else beside slowing the CPU speed during UPS battery supply that can be done on a Workstation

Now I’m going to look to split the connection of the power cables in my home office so that the hardware that would just go in standby while I’m sleeping would be connected to a single multi-socket, which can be disconnected at once, to avoid leaving the hardware consuming power without any reason. I’d like to be able to do the same with the monitors (that otherwise would remain in standby as they can’t be shut down. If I wasn’t using the same UPS for both networking and monitors, I could probably use the UPS to shut them down and turn them back on at my command.

Sigh, I’m afraid there will be a looot of work to do, and I’m sealing envelopes, once again

I might be sick, or just crazy, or both of them, but I still think I’m quite more productive when I have fever, or the days around that time. Yesterday I had fever, and I was knock out till late afternoon, but then I started feeling better, and I started producing.

First of all, rbot’s init script in my overlay has been updated: Subversion trunk will now create a rbot.pid file inside the bot’s directory without need for start-stop-daemon to create it itself, which means I can finally let rbot fork on its own rather than forcing it to background (which is not really a good thing to do, if it can be avoided). Thanks to tango and jbn for looking after my raw patch.

Then I decided to finish the work with apcupsd; again in my overlay you can find a new ebuild for 3.14.0 based on the one found on bugzilla, but with a new apccontrol file and a totally renewed init script. This script can be multiplied, which means you can have a /etc/init.d/apcupsd.foo link, which would then start apcupsd looking for /etc/apcupsd/foo.conf configuration file. Thanks to apcupsd authors for implementing this feature in 3.14!

I’ve also attached the two UPSes to Farragut instead of Enterprise, as the latter is not a server and might as well be offline when Farragut is still up (for instance this is the case most of the times I’m outside for the whole day, or if there is noone at home); apcupsd on FreeBSD works nicely, and doesn’t require any fiddling with configuration, neither kernel side (the ugen support is built by default) nor with permissions (as the default is to run as root, this might change in the future, but as it is it’s fine to me; I’ll be working on a better handling of permissions on device nodes for Gentoo/FreeBSD, but it’s not in my priority list at the moment). Also here, they work perfectly fine.

I was also able to fix a bug in xine-lib, with mp4/mov files playback that used version 1 rather than version 0 of the media header atom, such as files generated by FFmpeg. The bug was reported on sourceforge already but I wasn’t sure what it actually meant and where to find a sample file; when I generated the same condition by chance here, I decided to take a deeper look; unfortunately MultimediaWiki doesn’t provide much information about that, but I asked Mike to give me an account there so I can try to write something useful, maybe next time someone else needs a mdhd atom description they won’t have to look at the sources of FFmpeg to see how it’s read and generated.

Then tonight I wanted to resume my work on implementing audio conversions inside the audio output loop instead of doing it for every decoder; it’s an hard work as it probably will require rewriting a good deal of code, but it should be rewarding once it’s done. Right now there are a bunch more of flag values for capabilities, so for instance I can say if a drivers supports integer or float 32-bit samples, 64-bit samples, and if it can accept streams in a different endianness. This is important because there’s little point in doing the job of the output plugin, that might handle that transparently, for instance a big-endian stream might be decoded on a little-endian machine, then sent through PulseAudio to a big-endian machine where it will be reproduced: in this setup, xine’s endian reversal of the stream (from big to little endian) would have been superfluous, as PulseAudio would have accepted the big-endian samples, then sent them to the other machine that needed not to reverse them to reproduce them.

Anyway, right now the code is quite fragile, there’s no conversion being done, there are mostly only things that are totally broken out, there are asserts @1 == 0@ used to mark the code that needs to be rewritten. But something works: I was able to remove a lot of code from the musepack decoder, as libmpcdec always produces 32-bit native-endian (or maybe little-endian, I’m not yet sure) floating point samples; previously the decoder converted all the samples back to 16-bit format, and then gave it to the audio output loop to handle? now instead it sends them directly to the output, and as PulseAudio supports 32-bit float samples, they are not converted and play back fine.

Tomorrow I’ll see to work a way to handle upsamping and downsampling of streams, the problem is that it’s not trivial to decide what to do: if a plugin supports 32-bit integer samples, but not 24-bit integer samples, it should probably upscale the 24-bit to 32-bit to avoid losing precision; if it doesn’t it might upscale it to 32-bit float, or maybe downscale it to 16-bit integers. The same applies to channel mode, if the driver doesn’t support stereo output, should it be updated to 4.0 or should it be downgraded to mono?

For sure this time I’m very happy of being working on branches: leaving the code broken for weeks, maybe months, is not something you want to do on the main development branch. And I mean it, because with the changes I’m doing, not only I’ll be changing the ABI of the library itself (well, actually not much, just a couple of structures), but more importantly I’ll be changing the audio output plugins API, as I need to feed them a sample format rather than a bits-per-sample size.

Anyway, this is not going to be something easy to complete, but it will be a noticeable improvement for Amarok users once done, especially because I want to make sure that the capabilities for “mixer” volume and “PCM” volume are cleared up, probably by deprecating one of them, so that Amarok can be changed not to use xine’s software amplification (which also sucks and I also need to rewrite in good part in this branch) if the output plugin actually supports a per-stream volume (like PulseAudio).

Sponsoring, bribing, and comfort words are welcome, as xine-lib’s audio_out code is giving me creeps.

Sorry for the downtime guys, the update to baselayout 2 on Farragut wasn’t as easy as expected, I have some talk to do with Roy about it

Now, this is probably going to be the fourth night I’m not gonna sleep well, today I had a support request to take care of in the afternoon and I was supposed to go out with a few friends tonight, but I was so tired that I started having fever, so I had to get a raincheck for that.

The good news is that I received the new UPS, an APC SmartUPS 1000VA, that seems to be able to take enterprise and farragut up for 1 hour and a quarter, which is quite good (the other UPS would take the monitors and the network equipment up for also an hour, which is not bad, and should cover most of short-time non-planned outages.

Unfortunately, if you have followed me for a while, you know there’s no flawless hardware acquisition for me; this time the problem comes from the software needed to control the two UPSes; please note that there are two.

First of all, when I started using an UPS, I used apcupsd but then I moved to nut because it had a decent graphical control software (knutclient); what was the problem with this? Well, nut was confused by the two UPSes, that being both APC, shares the same identical vendor and product ID for the USB device. So it was not a nice thing.

I’ve then decided to come back to apcupsd, but the latest version is not in portage (again) so I bumped it locally with the patch on Bugzilla, and added a gnome useflag for the graphical control utility that is now present. This version is important to me, not only because of the utility, but also because with this version is possible to choose the configuration file at runtime, as it’s not hardcoded during build.

This is also important because in previous versions the only way to have more than one UPS being monitored on the same box with apcupsd required to have two different builds on different places. What I want to do now is to rewrite the init script so that it is multiplexed (like rbot, mt-daapd, openvpn and so on), that way I can simply start two apcupsd instances to have all I need (note that one of them won’t be shutting off my box at all, as it would just keep monitoring the UPS that is actually connected to the monitors and networking.

Once Baselayout 2 is more functional on Farragut, I’ll probably move apcupsd instances there, and network it down here, it would be safer on the long run as enterprise might not be up when farragut is.

I still haven’t been able to finish working on rbot’s changes I need, sigh. And don’t get me started on xine-lib, I’m taking a few days off because what I found myself working on now is a veeery bad thing I’m afraid…. (bit per sample transcoding during output).

Don’t worry all you people, I wasn’t killed in a bus accident yet; you are lucky, I actually go out quite rarely so I don’t suffer from this kind of problems very often, the worst that can happen would be a health problem, but I’m lucky enough to feel decently well at the moment Of course there is too much heat for my liking and I start to feel how annoying it is at this temperature, especially staying in my home office with two/three boxes online.

Anyway, as I promised, I started looking at the fork of libdvdnav lead by Nico, to import a newer version of libdvdnav in xine, and cleaning up the patches applied.

Unfortunately it wasn’t exactly straightforward to update the libdvdnav version; beside my will to move the sources into the contrib/ subdirectory as I already did for libmpcdec and ffmpeg, Nico started to replace autotools with a build system alike to FFmpeg’s (which is quite fine by me, as I can integrate it nicely enough into xine-lib), so I had to make sure that the build system was up to a minimum support for the features I needed. The main showstopper was the lack of a way to build in a directory different from the original sources directory, but that was quite easy to handle.

But luckily working with Nico is quite enjoyable All the patch I’ve sent for inclusion up to tonight (so excluding the one I sent less than an hour ago) were accepted and committed to the Subversion repository, which means that the build system is usable from xine-lib’s custom base system, that the compiler flags we inject are respected, that the library builds with -Werror-implicit-declarations (the change was needed to libdvdread, Nico took care of sending it up there).

Tonight I rebuilt xine-lib-1.2 with the new libdvdnav, and it’s working nicely. I suppose the reason why external libdvdnav is not working on seeking is that the code was present in cvs (for sf.net’s dvd project) but not released yet. I should probably also add support for .pc files for libdvdnav and then use those to check for its presence, so to require at least a new enough version that doesn’t have seeking problems, but that is not a priority until a release is done.

There is only one problem that has to be considered: the libdvdnav copy in xine-lib is patched with a patch from Bastien Nocera (Totem’s author) which is used to play invalid DVDs (non-encrypted ISO filesystem DVDs; proper DVDs have UDF as file system). That patch as it is won’t be accepted by libdvdnav authors, and sincerely I wouldn’t have accepted it for xine-lib either.

Why this? Well, the patch takes an opaque type, and makes it transparent, copying out of libdvdcss the structure definition. This is fine as long as the structure is not changed on libdvdcss, but the reason why a type is opaque, is just so that you don’t have to put its definition in the ABI, so you can change it without having to deal with software crashing because it was compiled against the previous definition. This patch breaks this assumption with xine, so it’s bad from a good practices point of view.

I’m not sure myself how much sense does it make to use such a stupid solution (sorry Bastien, but re-declaring an opaque type is a stupid solution) to consider invalid media. A better solution would be to always use the files if they are found, rather than using UDF access, with fallback to raw UDF instead. This should work, but I need first some media to test with, and then I have to understand libdvdnav code.

Anyway, the build framework changes are now committed to the xine-lib-1.2-newdvdnav branch, the “only” thing missing there is the libdvdnav code itself; the reason for this is that up to tonight I was still working with patched sources, not with upstream sources, and I wanted to avoid recommitting everything every time. I will probably wait as much as I can before committing the sources themselves, with this “as much as I can” representing ideally the time till I get to have committed to libdvdnav all the changes that make sense for xine-lib (revised Bastien’s patch, and the file descriptor leak patch).

I also want to thank Nico for the work being done toward adding an option to use external libdvdread in libdvdnav, which will certainly help Gentoo and other distributions: you wouldn’t have to duplicate the code between libdvdnav and libdvdread; you’d have one more dependency in the libdvdnav library, but that shouldn’t be much overhead.

And I want to say it officially: there is a lot of code in xine-lib that scares the hell out of me, and I would like to see it killed before it propagates too much; unfortunately overhauling all of it is difficult alone, especially since I might end up having repercussions that I don’t see (like the CDDA failure that didn’t fail for me when I tested – I was using by-extension detection in Amarok – and the DVD failure that still I was unable to reproduce till at least since Darren fixed it).

I start hating spending my time on xine, I hope to be able to continue working on it till it’s enjoyable to do so.

Returning on yesterday’s blog entry, today I’ll see to update you on the status of xine-lib’s XDG support.

Thanks to Mark Nevill, I didn’t have to reinvent the wheel by parsing the various XDG_ variables to check for the directories I have to search in; he already wrote a libxdg-basedir library that takes care of most of it, allowing me to take care of the implementation details.

Now, xine-lib-1.2 branch has an internal copy of libxdg-basedir (two source files, so it’s not a big deal, and I’ve added a switch to use the external copy of it if needed), and uses it to decide where to read and write some files.

For instance, the plugins cache is no more in ~/.xine/catalog.cache but it’s in $XDG_CACHE_HOME/xine-lib/plugins.cache which both makes more sense and can be decided by user to be moved out of its home (for instance I change the value to XDG_CACHE_HOME, but that’s a topic for another post). The CDDB cache is also moved on the cache home, while the fonts are now discovered in the XDG_DATA_DIRS defined paths. Darren also moved channels.conf load from ~/.xine to XDG_CONFIG_HOME, which means it’s loaded in ~/.config/xine-lib by default.

Please note that I’ve been using xine-lib all over rather than xine, so that users know what is generated/handled by the frontends and what is actually part of the library, if they care.

There are still a few changes pending, for instance Darren wants to support loading of a system-level channels.conf, so that it can be put in /etc/xdg and used for all users without having to put it in xine’s configuration for every user.

I’ve also decided to pay more attention to the security side of xine-lib, for instance, after talking with Taviso today, I’ve added a xine_xcalloc function to wrap around calloc, which should avoid possible overflows (there was one in input_dvb); I’ve changed some of the code, but of course it’s not totally cleaned up. xine-lib really should be audited piece by piece for improvement, every time I touch something I end up cleaning it up by adding more const keywords (trying to let the compiler optimise a bit more) and adding/removing/cleaning up code .

One thing that certainly would help would be to put a better wall between contributed code (where we should always do the work on upstream’s side and then merge it back into xine-lib, to avoid getting them out of sync, unless fixing some xine corner case or similar—although there it could certainly help to put a proper wrapping around the two), and the xine proper code that should fixed/cleaned/improved as we go.

Really, while xine actually do its job most of the times, it still suffers from a lot of possible problems just because the code is too old and stratified. I think I should simply undergo an audit file per file trying to fix stuff while I also update the documentation to be doxygen-compatible, but that’s going to take so much time that I’m not sure how realistic is to work on it; beside I don’t have hardware such as a DVB tuner that would allow me to complete the audit (I can’t try that code and I can’t ensure its working state).

On the other hand, tonight I fired up Klothos again; it has been some time since I’ve done any Gentoo/*BSD work, but I’ve lately asked Roy to put me back in bsd@gentoo.org alias, to see if there is work that needs to be done that I can do. Yes, I suppose I’m considering coming back, but if I will do that, it will be on a lower profile; maybe I’ll help Mike, Frysinger, SpanKY and vapier with the ARM architecture, maybe I’ll just decide to take care of BSD alone.

The problem with Klothos is the PSU; the whole box is quite silent, as the UltraSPARC CPU is cooled by a slow and silent fan, but the PSU is annoyingly noisy, and I can’t just put a be quiet PSU like I put on Enterprise because of the Ultra5 casing (it’s a desktop machine, the case is high as the ATX power supply, which means the big fan used by most silent units would be obstructed by it); I could try a passive PSU, as the box shouldn’t be sucking too much power anyway, but I’m not sure about it and I don’t have money to waste (at the moment I’m unemployed).

If anybody has a suggestion about which PSU I could use for such a box, it’s really appreciated. It’s funny that I paid ?35 for a working box, and then paid way more to bring it to a standard worth to be a dev machine… well, I got the SATA controller already in my possession, as well as the SATA hard disk; the DVD reader was also an old one I used, but I had to buy a new ethernet card to avoid using the obnoxious hme0 driver..

Of course, this entry will talk about xine-lib.

First of all, a note about what I’m trying to do with contributed code in xine-lib for 1.2 series. As I said already, my ffmpeg_integration branch, which is one of the two branches I merged to get the 1.2 branch itself, was born to allow using FFmpeg without changing its buildsystem, and putting it in a contrib/ subdirectory instead of mixing it with xine sources.

Well, as I’ve now started working on providing also some Doxygen documentation, I’ve seen that this is useful also for other projects that are imported in xine-lib, so that I don’t have to blacklist one by one the directories and the files that are not to be parsed for Doxygen generation.

In xine-lib-1.2 hg tip you can now find libmpcdec (that replaced libmusepack) in contrib/libmpcdec/ rather than having it together xine’s actual code (the decoder plugin code) inside src/libmusepack/. I also updated it to the last version available.

Similarly I hope to move other code, like libmad and of course libdvdnav, that was recently taken over by MPlayer developers because of the unresponsiveness of the original development project.

It will take some time to complete all the moves, also because I’ll try to contextually update the code with the last version available for every project beside libmpeg2. This should be a breath of fresh air for xine 1.2.

Talking about FreeDesktop standards, as Darren already changed gxine to abide to XDG Base Directory Specification, he also added better FreeDesktop standard support in xine-lib for configuration and cache files. So right now I’m working on making xine-lib use XDG_CACHE_HOME to store the plugins cache instead of the hardcoded ~/.xine/catalog.cache, which also allows me to move more cache data out of my home directory

By the way, why one earth the description of the permissions to use while creating directory (that is actually a quite logic 0700) is written in the «Referencing this specification» section ?