Tuesday, May 8. 2007OpenJDK and Gentoo/FreeBSDSo, Betelgeuse blogged about the new partly-free JDK released by Sun Microsystems. Kudos to them for actually starting to fix the Java Trap. Hopefully in the next months we’ll finally see Java taking the place it was designed for in development of platform-agnostic software, and applets in web pages, with the (hoped) availability of it on more platform that are available right now. Of course I want to get OpenJDK working on Gentoo/FreeBSD as soon as possible, as the FreeBSD Foundation’s “Diablo” project seems to be stale and broken (latest version is 1.5.0-7, I’m not even sure if it’s vulnerable, as I remember some security advisories for sun-jdk for Linux), and I wanted to move to Tomcat for my blog. So I asked Betelgeuse a bit of information about openjdk and downloaded the Java Experimental overlay, and decided to merge openjdk on Linux first. To get it to work on Gentoo/FreeBSD the first thing is to get the Linux emulation support at least partly working, as a JDK 1.7 is needed as a seed to build OpenJDK (this reminds me a lot of GHC unfortunately). So I’ll work on it until I can get OpenJDK building here. Unfortunately I can’t build openjdk yet, the build fails with an “Argument list too long” error in an execve() call. I’m not sure what causes it, but I hope to investigate it further in the near future (maybe I should ask Betelgeuse tomorrow after his exam). Another problem I’ve found with OpenJDK is that the build of hotspot mixes the values of CFLAGS and CXXFLAGS, throwing a lot of warnings about When I’m able to get OpenJDK building on Linux, and I understand the process well enough to work on it, then I’ll try to do my best so that OpenJDK works on Gentoo/FreeBSD at the best I can. I’m sure there are people from FreeBSD project working on it too, they did this already to get Diablo out, after all, but most of them don’t blog so you can’t really know what they are up to (beside if they are the same who would be releasing the new Diablos, they are probably missing in action for months now). Who knows, maybe we’ll be able to get OpenJDK working on Gentoo/FreeBSD/SPARC64 too, that would be neat Monday, May 7. 2007The relaxing method failureNot sure if you remember, but I’ve started, since a month and a half ago, trying to relax myself by playing with the Nintendo DS. When I bought I also bought Mario Kart DS (provided with the unit itself) and Pokémon Sapphire (for GBA, but that was needed also to protect the GBA card slot, as the pre-Lite version doesn’t have a dustcover for it). I’m the nerd kind of guy who actually like the Pokémon series, and I was pretty happy to play it through the end; I’ve played emulated the previous generations, this was the first time I could afford a game myself, and so I took the chance. I don’t actually like racing games, I got Mario Kart just because it was sold together with the unit, but I enjoyed it, especially to try out the Nintendo DS graphic which was quite nice. Of course after a while, playing only two games starts to be boring, so when I had the last cold I asked my syster to pick up Lego StarWars II for me. Nice game, nice graphic, nice ideas… too bad that starting from Episode V (the second of the three movies reproduced in the game), it starts to feel buggy.. there are times when you can end up stuck in a wall, requiring to end the mission and then restart from scratch. The game is nice so even if bugged, I continued playing, till in Episode VI I got stuck in a big bug and I needed to search for the solution of the game to find how to pass that mission… the solution also referred to the bug, so I did a bit of search, and I found that LucasArts admitted that the game, in its DS version, was shipped incomplete and unfinished. Nice one. Oh well, as I said the game is interesting on its own so I don’t feel like I totally wasted my money (I also got it relatively cheap), still I would have liked if Nintendo paid more attention to the title that are published worldwide, maybe putting a “Notice: might contain annoying bugs” on the package… okay I know it won’t ever happen, but let’s say that this game didn’t relax me that much. Then finally the game I was expecting was released, Yu-Gi-Oh Championship 2007, a nice game after all, although I don’t play the TCG, I found it quite interesting to play emulated before, so I gone for it as soon as it was available (via Amazon, as the local suppliers don’t carry it), I received it last Saturday and I started playing around. The nice thing about this game is the online challenge, which finally allows me to play against human opponents: playing against the computer becomes just a run to a better deck every time until you can beat the next opponent. So there I go, I try to get some decent cards and start getting beaten up by human adversaries, I wasn’t expecting anything different, but I wanted to see some more strategies before working out a deck that might work against the computer but not against an human. The online play is a nice thing, really cool especially since it’s WiFi-based so you don’t have to stay put while playing, and the stylus control in the game is well designed; but then I’ve started feeling bothered by the repeated “communication errors” I started getting during games. First I thought it was truly random, then I’ve seen it happened mostly when I was leading the game.. I thought of a coincidence, but when it happened after I did win the game, the opponent coming to 0 life points… I was sure the thing was not that random. Now, of course Konami can’t disallow people from closing their connection, or powering off the DS when they see they are losing, but… they could at least assign you the bonus points for the match, or at least the 10 match points you get for playing online, when the adversary fails to complete the game! Even if I like the game, I’m tempted to ask Konami my money back, online playing is poorly designed. iPod coverart sluggishnessFor those of you who have an iPod with a few thousand songs, you may have noticed that it can be sluggish to play songs and especially when playing the next song. This had been happening to me for a little while now, and to be honest I’ve really been to lazy to find out why, although I suspected the coverart. Songs with images took up to a few seconds to load, causing the gui to freeze totally (although music playback was uninterrupted). I knew something was totally wrong because the hard disc activity increased and battery drained quickly. My suspicion was that the libgpod library wrote covers to the database in an incorrect manner. Yesterday I was playing around on iTunes for some (competitor) research, and decided it was probably a good idea to update the iPod firmware. It never came to mind that the coverart problem was simply an inefficient art grabber within the iPod software. Lo and behold, updating to version 1.2.1 seems to have cured the sluggishness and the device is as responsive as it was when there was no artwork loaded. New KDE-Games is impressive
After reading this article on the dot I decided to give the new KDE-Games for KDE4 a spin. I have to say they've done fantastic work. The SVG graphics look just as good as on the screenshots, and scale beautifully to any resolution. Of course the best graphics technology is useless without actual artwork, so the kudos must also go to the artists. It's all very pretty. Likewise I was impressed by the relative maturity; many of the games seem already perfectly playable and in good shape.
The only small downside of the SVG rendering seems to be that it's quite CPU intensive. Resizing e.g. KAtomic to full screen takes a few seconds on my box (5000+ X2), and I can imagine that the application might appear to freeze on slower machines. However, in-game the performance is just fine, so I don't think that's a big issue. I'd say gaming on KDE4 is going to be shiny. Check it out if you haven't already Saturday, May 5. 2007Installing Amarok SVN in your home directory
We sometimes get asked by users how one can achieve to install Amarok in a different prefix. This can be handy if you'd like to check out a SVN version, but you don't want this to interfere with your packaging system. On our wiki there is already a guide for obtaining Amarok from SVN, so I won't detail this here (I am referring to the stable 1.4 branch here; Amarok 2.0 requires a lot more work to build). Once you have the sources, give the configure script your desired installation path ("prefix"):
Then compile and install as usual. After that edit your ~/.bashrc and add the following lines:
Now log out from KDE, and log in again. Voila, that's it Device Handling and HALMy blog's been rather inactive for a while. Most of this has been because of being busy, and because of not doing hugely exciting things when I have had Amarok hacking time (mainly some bugfixes in stable branch). But now something's come along that warrants an entry. Amarok's device handling is pretty adequate. Granted it could be better, but we support nearly every device on the market through some plugin or another. But there's one recurring problem: except in a few cases, Amarok doesn't know what device you have plugged in, and how to handle it. You have to tell this to Amarok. This means you, and we, have to deal with the manual creation of devices. Well, that's going to change. Enter HAL, and its KDE4 paramour Solid. By now, you probably know what these do. HAL, Hardware Abstraction Layer, gathers information about your hardware. Solid reads it (and some other information) and outputs a KDE interface to it. Now by itself, this isn't enough, because HAL has a namespace called portable_audio_player, but, with a few exceptions, it doesn't actually say what type of device you're using -- simply "storage" for a USB Mass Storage interface, or "user" meaning that a userspace library needs to handle it. However, for the last few weeks I've been working with HAL developers and the developers of libgpod, libifp, libkarma, libnjb, and libmtp. The goal has been to come up with a way that device access protocols can be auto-detected. If you know what access protocol a device uses, you can load the appropriate plugin automatically. Well, this has been done, and as a result the HAL portable_audio_player namespace spec is being modified to allow libraries to insert information they know about devices into HAL -- while at the same time keeping libraries from clobbering each other. Interested parties can find a draft version here, with the final verison going into HAL as soon as the slugs at freedesktop.org set up my account. After this, I will be adding proper entries in libmtp and libnjb (easy, since I have commit access for both), making entries for libifp and libgpod, and working with the libkarma developers for their entries. After all this is done (probably in the next couple weeks), Amarok 2.0 and other HAL-aware clients should be able to determine and load the correct plugin for just about any device on the market, automatically. Okay...after a lot more hacking on 2.0...but you get the picture. I'm hoping that when this is done we can remove manual device addition/deletion. It's a complex part of the code that can be difficult to maintain, and shouldn't be necessary any longer -- if you have a library that can handle the device that Amarok can use, Amarok should already know about the device from HAL. Even generic USB Mass Storage players should be fine, because they should be detected by HAL and exported through Solid as storage volumes. The only thing I can see this affecting negatively is the generic device plugin that just got fixed to support arbitrary KIO paths but I've been thinking about pulling that into the Collection some way anyways, now that the Collection can handle many sources, as this would let it handle lots of sources Continue reading "Device Handling and HAL" Friday, May 4. 2007Proceeding with xineMy changes to xine in the audio conversion branch are improving step by step; now all the decoders should playback fine, with their maximum resolution, by using the 32-bit floating point format as highest upscale. AC3 files are still a problem, although thanks to moesaji I now know that the mysterious function reduces the value basically by a value of 383 units; it’s still a mystery to me as I have no idea why that happens, and I can’t seem to find any documentation about these magic numbes for other stuff but a52dec. Anyway, beside a52dec, most of other decoders are already fixed for the new interface, and I’ve started working on updating the ALSA audio output plugin; unfortunately the code of that plugin is ugly and complex, and seems to be a great big compendium of bad code style. With my changes in the audio conversion branch, the size of the initialisation function was reduced by 1KB, which is far from being small. It should also reduce the number of strings to translate, as I’ve used two loops rather than unrolling the tests for the capabilities of ALSA devices, which then condensed the number of strings to translate (they are composed during output, rather than being complete literals). Hopefully the audio conversion branch will be merged into 1.2 series as soon as all the audio output plugins are converted, and a few more audio conversions routines are written. As the conversions are all limited to a single source file, it should also be quite easy to write more optimised routines using SIMD extensions for various architectures. By working on this I ended up applying a few changes to 1.2 series itself already, by removing a few members from the decoder’s state structure for many plugins, and putting them into the functions they are used (why declare them in a state structure that is allocated in heap and passed, by pointer, everywhere, when they are used only in a single function? Sometimes even in a single branch of a given function. The nice parts are that for instance NSF files now playback with a smaller memory footprint, as the buffer is allocated only when needed, and in the audio conversion branch also reduces the whole xine-lib memory footprint by two megabytes, this result means that to playback an mp3 file, xine-lib-1.2-audio-conversion takes half the memory xine-lib-1.1 takes! It’s incredible, but it’s true. There are a lot more improvements that I hope to push into xine-lib-1.2, one of these is the splitting out of the modplug demuxer on its own plugin, so that binary distributions can just package it separately, allowing users wanting mod playback to actually get it, and saving the ones who cares not about mod files from having to initialise libmodplug every time (it takes quite a bit of CPU time, because of the calculation of the samples, I think I’ll post some images about this in the next days). Oh and I’m actually thinking of reducing even more the code present in the decoders, by handling also the downmixing into the audio output loop (currently at least A52, DTS and Vorbis decoders contains the code to handle that) and by providing the code to handle also channels’ interleaving, as currently the same plugins also contain the same code, once again. This again is to allow providing optimisations if possible, although I admit I’m not sure which kind of optimisation can be handled here. Still, it should be better to only have a copy of the code, rather than an undefined number… Thursday, May 3. 2007todo for self: return of GraphEqualizerGraphEqualizer was an idea I had a while ago to free the constraints the equalizer puts on itself by being a direct analogy of its physical counterpart. I actually implemented it as an Amarok script (got removed since binary scripts are kind of a pain to package right). I was never really satisfied with it since it didn't have nice smooth curves between points. But today while poking around my second favorite mediawiki (sorry, Wikipedia is my guide to life Perfect! This Widgets and Classes page is a good idea. When the dust settles on trunk, there will probably be a couple of widgets Amarok can add to it. Wednesday, May 2. 2007The mystery of the a52dec decoded samplesI’ve been working a lot on the audio conversion code for xine-lib, with results that are always more satisfying, although Amarok fails to build on this new version, audio playback improved a lot, and with the code being all self-contained, the option of replacing the functions with more optimised code, using MMX, SSE, AltiVec or whatever other SIMD extension is more feasible. Unfortunately I’ve hit one issue: beside A52 and DTS having a channel order different than most of other formats, I have an issue with the type of the decoded samples. There’s a function called Now, if someone has any idea on what the following code does, I’d be glad to know it. The The output (on Little-Endian, as val_1 is the byte representation of a float number in Little-Endian) is: 383.999969 and -1; it makes no sense to me, but maybe someone else has a clue.. And for who’s wondering, the byte-value I chosen there is one of the samples decoded by a52dec, so it’s a proper value I’m trying to understand; and for who’s wondering, the proper correspondence for -1 (int16) in float32 format is (approximated) -3.0517e-05. Edit: thanks Nathan Smith who made me see the spelling error in the title (I still confuse the two).
« previous page
(Page 2 of 2, totaling 24 entries)
|
Amarok LinksCalendarQuicksearchArchivesCategoriesSyndicate This BlogBlog Administration |

