Monthly Archives: February 2009

Technology

A113

2 Comments

I have two kids, aged two and five. In our home I get to see a fair amount of animated movies, and yes most of them are run over and over again as the kids for some reason like to see the same movie endless number of times.

Anyway, what does a man like me do when he sees the same movies many times? He spots inconsistencies and patterns. My wife can get annoyed at times when I for example remark on how Nemo can get back to the main tank when the only way back is a pipe stuffed with a plant, in Finding Nemo.

Or the fact that Dinoco is both the name of a gas station in Toy Story I and the name of the racing team in Cars.

More recently I detected a bigger pattern that collides a bit with myself:

A113 is on the license plate of Andy’s mother’s car as visible towards the end of Toy Story I.

A113 in The Incredibles it is the conference room number where our main hero Bob is supposed to meet someone at that special island, only to get end up getting in fight with the big spider robot thing.

A113 shows up on a screen in Wall-e as some kind of instruction from the huge Axiom ship’s computer.

A113 is marked on the “electricity cabinet” outside my house! (see picture below)

Yeah, and once I had all this tracked down and it felt a bit strange I typed A113 into that search engine thing and of course I got to learn everything about A113…

Open Source, Technology

A stream of streamings

I’m a last.fm fan. I love its ability to not only stream music without needing a dedicated client installed (yes a flash application I think suits a purpose) and I think it’s ability to provide music I might also like is amazingly nice. I’m a “random it all” kind of guy when I listen to my local music collection in most situations as well. It is not specifly well suited for listening on exact the songs you want, as if you select a specific song it won’t even play the full-length version of it.

Lately there’s been a lot of buzz in Swedish tech media about spotify, which is a similar idea (at the moment still an on invitation-only thing in Sweden). They stream music, but only to a proprietary Windows or Mac client and currently they offer free listening with ads (embedded in the audio and visible in the client) or 99 SEK (== 9 Euros == 11 USD) per month. The client is highly focused on specific songs or artists and it has nothing in the way of “random artitists I generally like and similar ones”. I’m not too thrilled.

Spotify offers its service in several places, and I hear in the UK it’s not even invitation-only (which of course is useful for the more forward-thinking hacking kind of guys who thus use a UK based proxy to reach them). There’s however no sign of a Linux client. We’re forced to run their windows client with Wine.

I’ve gotten the impression that Pandora is a similar concept to play with if you happen to be based in the US. I’m in Sweden and Pandora just shows me a “We are deeply, deeply sorry to say that due to licensing constraints, we can no longer allow access to Pandora for listeners located outside of the U.S.”

The other day despotify.se showed up. A bunch of clever hackers reverse engineered the Spotify protocol and stream and offer a full unofficial open sourced ncurses/libvorbis/pulse-audio/gstreamer/expat/zlib/openssl-based player! Reading the code shows that these guys certainly had to crack some hard nuts, but the activity in their IRC channel seems fierce and the code is rather clean so I expect it to turn out to eventually become a fine player if Spotify just doesn’t decide to play hard ball with them. Unfortunately, despotify hasn’t yet been able to produce a single sound for me since it has just died on assert()s on basically any attempts I’ve tried. The interface is also a bit… strange and not the easiest to figure out. (It should be noted that the despotify client still requires you who have an actual spotify account.)

It’ll be interesting to see how Spotify, or perhaps the big media companies owning all the music rights, will act on this initiative. This client does open up abilities for new fancy features. How about ripping the stream? How about re-distributing the stream like as a proxy? And of course it being open, it does open up for adding features I want to add.

Update: just hours after I posted this, Spotify closed access to their service using the despotify client as long as you’re not a “premium” (paying) user…

cURL and libcurl

Saying lib out loud

9 Comments

Not being a native English speaker, I’ve always pronounced libcurl with a ‘lib’ part as if it was part of ‘liberty’, and ‘curl’ with a K sound and ending with ‘earl’. I don’t know of any Swedes who would not pronounce ‘lib’ like that, but when speaking Swedish we’re of course highly influenced by other things so it’s not really relevant.

It wasn’t until I got on FLOSS Weekly that I fully realized that some English speakers would actually pronounce the ‘lib’ part as the first syllable of ‘library’ and that does make sense considering lib is short for library.

But libcurl is just a smaller player here. How do you English speakers pronounce libc? libxml? libgcc?

And yes, this is another one of those really important issues in life. Almost as important as how to close parenthetical expressions with emoticons!


Rockbox

Rockbox USB – A Long Journey

4 Comments

The road to get a fully working and enabled mass-storage USB stack in Rockbox has been long and bumpy.

Bridge-Chip

Back in the early days of mp3 players, they all had bridge-chips which basically meant that the entire USB handling was handled by a dedicated chip that also “took control” of the hard drive (right, most of the interesting players used hard drives initially) so Rockbox didn’t have to do much except hand over control, show something nice on the screen in the mean time and then when the plug was pulled, regain control of the drive again and continue working.

But similar to how early players used dedicated HW-solutions to do music playback and then ditched that for pure CPU-powered solutions, the HW-solutions for USB also died out and all recent models do USB in software.

Research

The PortalPlayer chips being notorious for their complete lack of public docs were more or less considered impossibly hard to get USB working on by us. Until MrH came along 2006 and figured out that the USB parts of the PP5024 chip (used in the sansa e200v1 models) was identical to the USB core used by Freescale’s imx31 chip and there are public docs available for that.

Software Stack

The first step towards a software USB stack for Rockbox was taken in the 2007 gsoc, when Christian “austriancoder” Gmeiner took on the task. He went for a Linux-kernel inspired and quite ambitious approach that at the end of the gsoc project still didn’t quite work. The plan was at that point to primarily write a driver for the Sandisk Sansa e200 series, and secondary for other PortalPlayer based targets (such as ipods etc).

Made Working

Enter Björn “Zagor” Stenberg who had a much more minimalistic approach. Not being pleased with the “big” approach Christian had provided, the existing code was simply cut out and replaced with the new leaner version. Focus was then to get something small and simple to work, and then add fancier layers or features later on instead of providing the architecture for that already from the start. The stack started to partially work for mass-storage.

Not Yet Stable

USB wizard Frank Gevaerts joined the effort and worked fiercely on the thing and not only did he bring USB serial support (that does enable things like logf() support to debug rockbox) he also made the mass storage support almost reliable. The non-existing docs for the hardware made the remaining few flaws very hard to catch and the development of the stack stood still at this point for a great while.

Meanwhile, the USB stack could successfully be used on various new (in the Rockbox sense, these models are no longer new on the mp3 player market) targets like the Toshiba Gigabeat S and the Onda series etc. Parts of the Cowon D2 reverse engineering was greatly enhanced thanks to the USB stack as figuring out the FTL is even more tricky without a fine way to get data over to the host PC. All this proved that the stack itself worked nicely but that there were target-specific inits or setups that were missing for the PortalPlayer targets.

Of course the other new targets were not PortalPlayer based so it took efforts from clueful hackers like Vitja Makarov to implement the hardware driver for the TCC chips and Maurus Cuelenaere who did the driver for the Onda.

Stable?

Now, in 2009 our reverse engineering hero Boris “dreamlayers” Gjenero banged his head against the problem and by doing really nice disassembly he figured out previously not done initiation sequences. These have now been committed to the Rockbox SVN respository, and the early tests of this are very promising showing the mass storage support to be very close to get supported “out of the box” on the PortalPlayer 5022 based targets now. The PP5020 ones still seem unstable, and we have no support on the PP5002 ones.

If things just proceed this fine, we’ll be able to ship Rockbox’s own USB stack by default in the upcoming 3.2 release!

Commit

At Wed, 25 Feb 2009 23:40:15 +0100, the USB code was enabled in the SVN code: “Enable USB mass storage on PP5020, PP5022 and PP5024 targets”

Rockbox

Updates: this post was updated several times to gain accuracy and truths pointed out to me by Dave Chapman, Björn Stenberg, Frank Gevaerts, Jens Arnold and others. Thanks!

Open Source

Project is Standard now

I fell over a (warning: Swedish!) article on the Swedish idg.se site describing the nominees for the yearly award “Guldmusen” (“the golden mouse”). One of them is this year the highly deserving Adam Dunkel, originator of among other things the very cool lwip (light weight IP) open source project.

However, in both articles on IDG that’s not how lwip is described. It is instead claimed to be “an unofficial world standard”.

“world standard” huh? Yes I admit that makes it sound quite a few notches better than “well-used and appreciated open source project”.

But lwip is an TCP/IP stack. A very small one. How can that be a standard, even if you call it an unofficial one?

idg.se continues to be rediculed by me and my friends and the reasons are silly things like this. Let’s hope they continue to amuse us for a long time to come! 🙂

Blogging

You and the 199 others

1 Comment

How many readers are there of my blog, being no frills hard core tech oriented and all?

The stats are pretty clear: there is roughly 200 visitors per day on the actual daniel.haxx.se/blog site. The main RSS feed is requested 600 times per day, but the blog entries are also mirrored and read on advogato.org and fnoss.org as well.

Since I started blogging on this site I’ve done 383 posts (before this one), which makes roughly two posts every three days on average.

Rockbox

Blame game

I’ve mentioned the fancy distributed build system of Rockbox before, and now it just got even fancier as I’ve introduced a “blame” script that sends a mail to the commit mailing list (that gets mailed with a diff of every single commit) every time one or more builds in the automatic system show up red in the build table. Red builds are for errors (as opposed to yellow for just warnings or green for OK)…

The mail simply mentions that the builds are now red and who did the commit(s) that was included in the failing build. Due to the nature of it, it can be one or more committers and in fact there can be more commits than one from any of them. It’ll help us get alerted about the problems, and hopefully get them fixed again a little faster.

Rockbox

Network, Windows

Windows localhost slowness

A client of mine and myself ran a bunch of tests doing FTP and SFTP transfers against localhost to measure how fast our custom solution is compared to a set of existing solutions.

The specific results from this aren’t what caught my eyes, mostly because they’re currently still only used for comparisons and to measure relative improvements, but it was instead the relative speed differences between the tests run on Mac 10.5.5, on Windows XP SP3 and on Linux 2.6.26.

Some of the Windows transfers took a magnitude more time than the others. Ten times longer. Since we could see this across multiple tests each being run multiple times and it was also visible with third party tools, the only conclusion I can draw from this is that Windows for some reason has a much slower localhost.

Does any reader of this have any further knowledge or details to share on this topic? Anyone knows if more recent Windows versions do this any better?

It should be noted that on Windows the ssh server used was running in cygwin, which may account for some of the slowness as cygwin isn’t really known for being blazingly fast…

Update:

Three friends responded to this question:

The first mention that he’d got problems on windows in the past where 127.0.0.1 worked but ‘localhost’ didn’t which might indicate that localhost for some reason would be treated differently.

The second said that it has been mentioned that Windows Vista has significant TCP improvements compared to older versions for which version the TCP/IP stack was rewritten completely.

Pierre (at Microsoft) pointed out that on Vista localhost resolves first to ::1 (ipv6) only, which may explain why some people experience quirks on Vista at least. This test was however done on XP…