Sound Juicer "I Need A Little Love To Ease The Pain" 2.14.5
Sound Juicer "I Need A Little Love To Ease The Pain" 2.14.5 is out. Tarballs are available on burtonini.com, or from the GNOME FTP servers. This releases rolls in the bug fixes from 2.15.4:
- Add date information to all possible albums (Alex Lancaster)
- Improve GStreamer error handling (Tim-Philipp Muller)
- Don't crash when re-opening the Preferences dialog
- Clear the genre field when re-reading the disk
Sound Juicer "Two Undernourished Egos Four Rotating Hips" 2.15.4
Sound Juicer "Two Undernourished Egos Four Rotating Hips" 2.15.4 is out. Tarballs are available on burtonini.com, or from the GNOME FTP servers. Not a lot going on, sorry.
- Add date information to all possible albums (Alex Lancaster)
- Improve GStreamer error handling (Tim-Philipp Muller)
- Don't crash when re-opening the Preferences dialog
- Clear the genre field when re-reading the disk
American In Britain
Britain is often said to be part of "the United Kingdom", along with several other countries, including England. Ireland is also nearby, and is considered part of Scotland, which, in turn, is adjacent to, and included in, a small country called Wales. To first-time visitors this can be confusing, especially when one learns that - paradoxically - France is considered by the British to be its very own nation!
A snipped from the first article in a series in The Guardian. It continues later:
The traveller must, of course, always be cautious of the overly broad generalisation. But I am an American, and a paucity of data does not stop me from making sweeping, vague, conceptual statements and, if necessary, following these statements up with troops.
NP: Neighbour Radio, Last.fm
Hot Patch And Merge Action
For the last few weeks I've been trying to get as many of the non-DBus specific changes to EDS we've made in the eds-dbus port, to ease re-basing the port against EDS 1.8 for eventual upstreaming. Many thanks to the Evolution maintainers for reviewing so many patches so quickly, I just hope I broke nothing in the process!
- Added API: e_book_query_vcard_field_exists, e_vcard_get_attribute, e_vcard_get_param, e_vcard_attribute_remove_value, e_vcard_attribute_remove_param_value, e_data_book_view_notify_update_prefiltered_vcard
- Extended EContactPhoto structure to support remote photos
- Changed name parsing tables to avoid relocations
- Fix "all contacts" optimisations so it actually happens
- Increased performance and reduced memory usage of the default addressbook backend
Out of the thirty commits to the addressbook since since April, half were merged from the DBus port!
NP: Feedback, Jurassic 5
DBus Performance
Ah, the classic DBus performance issue has reared it's head on Planet Gnome again. I'll chip in my thoughts on this, as I've done a fair bit of profiling on a large user of DBus.
When I first ported of EDS to DBus, it didn't perform as fast as the original ORBit implementation. However when I dug out OProfile I discovered that the main bottle necks were deep in EDS itself, and DBus although in the profiles, wasn't anywhere near the top. We spent a few months optimising EDS-DBus (there was some serious low-hanging fruit) and by the time we'd done the obvious optimisations, EDS-DBus was faster than upstream EDS for the typical usage (running a book view, which happens every time you search in Evolution).
For some methods EDS-DBus was still slower than EDS, and getContacts() is a perfect example. This method takes a query, builds the set of contacts that match, and sends it back to the client in a single list (compared to book views that do the same thing incrementally, and provide future updates). When profiled you discover that libdbus and libc are the top offenders, taking almost 70% of the runtime. The benchmark was asking for all contacts, so EDS-DBus was sending a 150 contacts as vCards over the bus in a single list, which amounts to about 100Kb of data. Now, this gets copied when it enters the library, copied again as it enters the sockets to the bus, which then sends it into another socket to the client, which then makes a copy. These copies really hurt, and are one of the things that ORBit does better than DBus: it copies less frequently and has generally had more optimisation time. There are several ways of making it better.
-
Those nice people at Collabora have
batshit insanecunning plans for a SHM-based transport, instead of sockets. This would reduce the number of copies, but does introduce some, well, interesting locking fun. - Almost half of the copies could be removed by creating a private connection between the client and the server, missing out the bus entirely. I plan on doing this for the book views as they are heavily used and the bottleneck is, again, the copies.
- Obviously, heavily profiling and optimising libdbus to remove any redundant copies would help. There may be cunning ways to avoid some of the copies for certain situations, and allowing those to happen in the GLib bindings would be useful.
In conclusion, the DBus vs ORBit performance issue isn't a real one generally. It's a rare case where the cost of the transport is the bottleneck (generally only in fake benchmarks), and when the transport is the bottleneck, there are generally other ways of optimising the code: as Havoc says DBus makes doing true asynchronous method calls trivial, and if you are sending huge amounts of data down the bus a private connection should be used (which will also make you a nicer citizen on the bus, as sending huge messages will clog up the tubes).
NP: Kind Of Blue, Miles Davis
Lens Opinions
My main camera lens at the moment is the EF 28-135mm IS USM, which although excellent for a non-L lens is limited as on a non-fullframe DSLR the widest it goes is 45mm. Now if I had a decent wide angle lens such as the 10-22mm this wouldn't be a problem, but the only lens I own going wider than 28mm is the kit 17-55, which isn't great.
Thus I've been thinking about selling the 28-135 and buying the 17-85mm IS USM, which is clearly targetted as being the 28-135 for cropped digital SLRs. I'll loose the extra zoom but in return gain the wide angle in a single lens. However, the optical quality of the 28-135 is excellent for a non-L lens, and I'm worried that the 17-85 isn't up to the same quality. Are there any really picky camera geeks out there who have used both the 28-135 and 17-85 and can help me decide?
NP: Prose Combat, MC Solaar
Crap Speakers Of Doom
I just discovered a use for the Treble Booster EQ on my iPod... Now that
I'm working in the spare room study pretty much all the
time I really miss not sitting in the sweet spot for the hifi downstairs.
Hanging around I had some cheap Logitech computer speakers, so I've dug
those out and plugged my iPod in. This morning I fancied a bit of Sigur
Rós so I slapped on Ágætis Bryjun and after two
minutes was enjoying the bass (the speakers are sub/sat) but was left
wondering what happened to the drums. If I listened very carefully I
could just make out a snare, but the cymbals... totally inaudible. Thus
Treble Booster, which has at made this album listenable too at least.
It's a pain that these speakers are so bass-heavy as my laptop doesn't
have bass/treble controls. The irony is that the sub doesn't even go that
low, on Flugufrelsarinn the bass drum is totally drowned out
by the organ. The mid-bass is just very, very loud.
Oh well, I'm planning to get a pair of small speakers (MS Avant 902i are looking good) and one of those super-cheap Super-T amps for this room at some point.
NP: Ágætis Bryjun, Sigur Rós
EDS and Berkeley DB
Back in the good old days of Evolution 0.9, Evolution depended on Berkeley DB being installed. At the time Berkerley DB ("BDB") was undergoing a some major changes so it wasn't uncommon to upgrade your distribution and find that the new BDB can't read your addressbook. This was solved by Evolution embedding a copy of BDB into the source code. and statically linking it into the relevant addressbook backend. Problem solved.
Over time Evolution was refactored, split into Evolution and Evolution Data Server, and so on. Then BDB was statically linked into not only the addressbook backend but also libedataserver, which contains some generic caches based on BDB. Now BDB isn't exactly a small library (it adds ~600K to a .so), so the second static linking started to irritate people. Not only does EDS have a private copy of a library, meaning extra work when BDB has security bugs, but there is 1.2M of code that could be shared. This led to various distributions patching EDS to use a system copy of BDB, a patch that has finally made it upstream, but not everyone is using it: by default EDS uses it's private copy.
Now fast-forward to today. I did a full build of EDS from CVS using the system BDB (it's also a lot faster to build that way) and hit build failures from code demanding the static BDB to be built. Fixing these was trivial, but when I checked in the patch it worked fine... I investigated and discovered that BDB is now used in four places inside EDS:
- The addressbook "file" backend. This is the original user
- libedataserver
- The Groupwise backend, as a cache
- libedata-book, the server-side addressbook library
Now, BDB is approximately 600K when statically linked, and a typical EDS build statically links it four times. The server process will load both backends and both libraries, so it contains all four copies of BDB at once.
This is getting silly. Please, all packagers, if you support multiple versions of BDB in your distribution, use --with-libdb=/usr to dynamically link to BDB. As a fallback I'm about to create a patch that installed the private BDB into a private library directory, to avoid all of this static linking.
NP: Neighbour Radio, Last.fm (via Last Exit)
Evolution Broken
That was a nice inflammatory title to get everyone's attention. I've just committed a change to Evolution Data Server (#313533, extending EContactPhoto) that not only breaks ABI but also API. Rock on!
Now I've yet to update Evolution for the new API, so people doing builds from CVS will find they break. I'll try and get it fixed today, but I can't promise it. The fixes will be fairly simple if you ignore the new features, so someone else should be able to easily do it.
NP: Cool Groove
GUADEC 2006 Photos
On Sunday I spent a good hour or so sorting and uploading the photos from GUADEC 2006. Most of the photos were taken by Daniel Stone, after he stole my camera during the Maemo One Year Old party. Anyway, here they are on Flickr.
NP: Colour the Small One, Sia (via Last.fm)
Last Exit debs
Iain has just released Last Exit 1.0,
triumphantly feature-complete when compared to the official player. I've
created Debian packages that are currently sitting in the NEW queue, until they hit
Sid there are packages in my
repository. They are targetted at Sid, but should install
fine on Dapper. Tell me if they don't and I'll do a rebuild.
Update: packages built on Dapper are now available too. Another
Update: hopefully non-broken packages for Sid and Dapper are now
uploaded.
NP: Neighbour Radio, Last.fm
Go Energy
To counter the Stop Energy I'm famed for (think of the Listen saga), I'm going to blog some Go Energy.
Sputnik is a great little Internet radio player. The UI is heavily based on Muine, it uses Python and GStreamer, and pretty much Just Works. It's only up to version 0.0.3 but it's been my main source of music for the last few days, so it does what it needs to well. I'd like to see it displaying the song title and artist somewhere, but that is about it really.
NFlick is a Flickr set browser for the Nokia 770. As it is only version 0.1 is has some flaws: it eats huge amounts of memory (no running it at the same time as the web browser). crashes a fair bit, doesn't cache images, and doesn't support the hardware keys. However, when it works, it works well: this is just the sort of tool I want on the 770.
NP: Digitally Imported - Lounge
Qt 4.2 Preview with Glib Mainloop
To enable closer integration with the GNOME deskop environment and tools, Qt 4.2 now contains support for the Glib eventloop[via]
Next step: World Domination!
NP: This Is My Demo, Sway
