Belatedly I have realized that going along with big old WordPress for this intermittent blog of mine was probably a mistake.

I use about 1% of its wealth of functionality, and not often enough to become proficient at it. It’s also slow as molasses on this cheap host I’ve been using.

Moving to a better host (for many other reasons) also made me aware of the hassle involved in carrying over database contents for such apps.

So instead I painstakingly extracted my posts from WordPress and ported them to a much simpler, lighter and database-less blog app called PluXml.

There will be a post with actual content appearing shortly on this new media, which makes it two posts this year, a huge improvement on the previous ones :-)

The new IBTC is at http://w4.monbo.net/blog/ and the old one will probably disappear shortly.

Given that Maemo Planet is pretty quiet these days, I thought people wouldn’t mind a quick and almost, but not quite, off-topic post. Also, it’s hard to resist turning a bad pun into a blog title :-)

This post is a shameless plug for a new project started in this TMO thread.

The goal is to take advantage of the “USB Host” (h-e-n) package to stream digital audio through the USB port.

In the portable music player scenario, the N900 is used for digital music storage (32BG internal + µSD), user interface software (like Rockbox) and decoding music files (like mp3 or flac) to uncompressed PCM format.

This stream is then sent out through the USB port to an external digital-to-analog converter (DAC) and headphone amplifier, bypassing the N900′s own electronics, to achieve maximum sound quality (see the first post in the thread for a more detailed explanation).

Such DAC/amp “combos” exist in portable form, such as the Fiio E17 and iBasso D-Zero.

Another (technically similar) scenario is to stream sound in through the USB port, for example from a portable mixing console, and use the N900 as a high-quality recording device.

Right now we have proof-of-concept for both use cases, as h-e-n with power-kernel automatically supports such USB audio functions, and the corresponding ALSA device is created.

Using command-line tools in xterm (like mplayer, MOC or arecord), sound can be streamed to/from this ALSA device, with very good results.

One limitation of this method, however, is that it doesn’t work with Hildon GUI apps (like the stock Maemo media player, or the Rockbox port).

Another is that it doesn’t use the N900′s DSP, doing all the encoding/decoding in software, with higher than necessary CPU usage.

Our present understanding, so far, is that we would need to:

• tweak PulseAudio to make the USB “sound card” available system-wide,
• and use gstreamer to take advantage of the mafw framework and the DSP.

Unfortunately none of us end users really understand how this alsa/mafw/gstreamer/pulseaudio puzzle fits together inside Maemo. Conventional wisdom for regular desktop Linux does not seem to apply, and all experiments to date have failed.

If you are reading this and are knowledgeable about the specifics of the Maemo sound system… and enjoy a challenge… please do chime in ! :-)

…as predicted. But this is what happens when cracks get fewer, far between and a bit tight :

Ah, the moon’s too bright
The chain’s too tight
The beast won’t go to sleep
I’ve been running through these promises to you
That I made and I could not keep
(Leonard Cohen)

Well, as I’ve had the surprise (and honour, thanks Jaffa!) of appearing in today’s Maemo Weekly News, I guess I might as well expand a bit on that “packaging issue” Andrew mentions, and the subsequent “plea for help”. In my view there’s quite a bit more to that issue than shown in the quick exchange in the SnXM topic on t.m.o.

Yes, yes, I’m painfully aware that it was ages ago I promised a “Season Three” about Hyakutake that has, so far, failed to materialize.

What didn’t fail to happen, however, is something I anticipated in a previous post… Since that time I became ever more engrossed with the speed of Python on the N900, the release of a Nokia-sponsored, beautifully “Hildonized” version of PyQt for Maemo5, and the wealth of great community applications that ensued : KhtEditor, DropN900, GRead, to name but a few.

Until, of course, I found an “itch to scratch” and a plausible excuse to make my own.

The itch was Simplenote, a web service that lets you jot down quick text notes and access them from anywhere. Think of it as a KISS version of Evernote that handles only plain text, but fast and well, especially when used off-line through native clients. There are quite a few such apps, for Windows, Mac OS and some mobile platforms : iOS and Android obviously, also Palm webOS, but no Maemo, as usual.

That was bait enough for me to take the plunge. After all, it did have “simple” in it, didn’t it ?…

So here is version 1.0 of SnXM, my very first PyQt app for the N900. And onwards, I hope : I’m confident it’s almost as future-proof as a web app, and the name reflects that — XM is 990 in Roman numerals :-)

It may not be the most polished UI out there (I still have much to learn about Qt), but it works. If you are a Simplenote user, or were waiting for a Maemo client to try it out (as I did with Evernote, Dropbox and Google Reader), check out the talk.maemo.org release topic and pipe in…

Enjoy!

Yes, I know, the previous post was supposed to be the last in Season Two. But Frederik’s comment there suddenly reminded me that I had introduced the series as a replacement for a demo that I didn’t get to make. And after a lot of hot air, here I was postponing any actual glance at the app itself until Season Three, which will clearly be a while in the making… not fair on the reader, I guess.

So today, on a rainy day off, I set out to actually do that demo, while also recording it. I am not well versed at all in the mysteries of video recording, editing and such, so it took me quite a few trials and errors to find something that I could manage. Initially I thought it would be simpler to record a screencast on each machine, and then somehow paste them side-by-side in the same video. That failed abysmally, so I went back to filming both devices together, finger included, with my digital camera. I am not an expert photographer either, so there were problems with lighting, focusing and whatnot. Then, over the course of an afternoon, I learned plenty of interesting stuff: how to convert the huge MOV file from the camera to a more manageable AVI; how to create a file with the subtitles in it (I really didn’t want to tackle a voice overdub!); how to generate a second AVI with those subtitles “burnt into” the video; how to create a hosting account and upload the masterpiece, etc. All reusable skills, I’m sure :-)

The result is two minutes long rather than the five planned for the lightning talk in Amsterdam, but I guess it’s enough to get the gist of it. In retrospect, I’m actually relieved I didn’t have to do this “live”…

I chose the N810 for the demo because it is the smallest tablet and would block less of the laptop’s screen. Both machines are connected to a third host (10.10.10.10), the tablet on port 9000 to web2py, and the laptop on port 8000 to orbited. Both browsers (Tear and Firefox, respectively) are full screen.

Here you go: enjoy, feedback welcome!


Hyakutake demo from fpp on Vimeo.

Well, you can’t go much further out than Pluto without leaving the neighbourhood altogether, so it’s back to Earth now…

We will conclude Season Two with a quick but much-needed reality check:

Does the system work ? Yes. Surprisingly well, one might say, for something that should not be possible by design.

Is it useful ? Definitely. Once you see it in action it tends to give you ideas for other uses: displaying digital images; a family agenda; sending short messages or reminders from outside to those at home, and so on. There is much potential in having a full-blown web app server on the remote-command side; using it just to display a menu of icons is admittedly trivial, but you can stray from that initial approach for more elaborate actions. Like HTML-scraping the target and displaying a custom version on the remote instead of the original page; forms for data entry; remote controlling a gallery; automatically displaying sites depending on the weekday and hour, cron-like. And certainly a lot more I just didn’t think of.

Fine, but did it solve my original problem ? Not really, because in the meantime an N900 joined the family, so I still have too many devices :-)

After this rather high-level view of the what and why, I plan (if there’s interest…) to follow up with a more technical, hands-on Season Three about the how: the innards of Hyakutake as an application, its various bits ‘n pieces, their installation, configuration, and even — gasp — actual code. And screenshots :-)

Any takers  ?

Once I had this general understanding of how things stood, which took a good while, choosing a COMET server package was no big deal.

So here are the items I brought back from my trek in the wilderness, after I didn’t get eaten.

First, I quickly realised there would be no “cut ‘n paste, roll-my-own” here. COMET is a complex beast, covering a good handful of different techniques, relying heavily on javascript code and AJAX, and accordingly having to negotiate with browsers to work around incompatibilities. The only way someone like me could use that stuff would be through a ready-made package to encapsulate the complexity of setting up the communication channels between clients and servers, on both sides.

Speaking of which, I also discovered that I would have to add another web server to my toolbox. You see, http is a stateless protocol, by design: a client sends a request to a server, the server responds, and both happily forget about each other right away. There is normally no way for a client to stay connected to a server indefinitely, much less for a server to send data to a client that didn’t ask for anything… Pushing the boundaries of the protocol specs that hard requires active participation of the server, to say the least. So COMET servers tend to be specialized and dedicated to their function — feeding their clients. If these also have need of standard, request/response http services, they must ask somewhere else.

So, if a picture is starting to build in your mind, you may see where this is leading: if one client communicates with a “normal” web server (say, web2py), and the result of that interaction is pushed to another client by an unrelated COMET server, where is the missing link?

The answer is that the two http servers must communicate between them through a “message queue”, using a protocol which adds yet another entry to the alphabet soup: STOMP (Streaming Text Orientated Messaging Protocol). A complete COMET package will also include a STOMP server, such as MorbidQ or RabbitMQ… it sort of piles up, doesn’t it ? :-)

Finally, I learnt that the various methods used by COMET servers to stream data to their clients all had their specific pros and cons: that’s why there are several, to choose the best one for a given job. Fortunately for me, those pros and cons mostly seem to revolve around the same couple of issues: scalability and performance with many clients, and/or fine-grained control over the appearance of the content being streamed to a client. As I only intend to have one client at a time, and basically just switch it from one Web site to another, this, at least, was something I wouldn’t have to worry about.

So I set out to summarily evaluate the prominent COMET packages, and rather quickly settled on the one we’ll see next: Orbited.