So Windows Vista finally allows to enable ClearType font smoothing for Remote Desktop / Terminal Services sessions.
If you try to connect to a machine running Windows Vista using rdesktop, you won’t get smoothed font typing since at the time of this writing rdesktop does not officially offer an option to control this feature. However, here is a workaround:
Continue reading ‘rdesktop: Connect to Windows Vista with ClearType font smoothing enabled’
Less
More
Archive for the 'Linux' Category
Today I’m releasing QScrobbler: a Last.fm / Audioscrobbler add-on for Quasar Media Player.
As with Quasar, I’ve been using QScrobbler for almost a year now and finally decided it is ready for the public. ;)
For more details please visit the project’s homepage here.
Finally! Almost a year after the first mentioning of my new media player for the Sharp Zaurus and after several development hiati, I’m today officially releasing the Quasar Media Player for SharpROM- and pdaXrom-based distributions.
For more details please visit the project’s homepage here.
Today I’m officially releasing my extended driver and mixer for the Wolfson WM8750 CODEC / sound chip that comes included in the latest Zaurus models.
The driver exposes the following new features:
- ability to set and control Treble, Bass and 3D stereo sound enhancement;
- ability to set and control various cut-off frequencies supported by the sound chip;
- output source selection (Autodetect, Internal Speaker, Headphone).
These features can be easily accessed via a Qt based mixer control app or directly via a /proc/driver/wm8750 kernel interface.
Both, the driver and the control app are available for Sharp ROM / Cacko ROM and pdaXrom beta 3 / pdaXii13.
Kernel patches are available for Sharp’s Linux kernel 2.4.20 and can be downloaded here:
http://www.katastrophos.net/zaurus/sources/wm8750mixer/
(No kernel 2.6.x support yet. Sorry folks.)
By default the audio driver is compiled into the kernel. Sharp didn’t compile it as module, so it can’t be easily replaced. Same goes for most third party ROMs. You’ll have to reflash your kernel to install the new driver.
In case you don’t want to roll your own kernel, I’ve made pre-compiled kernels available for all supported ROMs and models here:
http://www.katastrophos.net/zaurus/kernels/v55/
The control app and start up scripts are available as IPK here:
wm8750mixer_0.9_arm.ipk - WM8750 mixer for Sharp ROM / Cacko ROM
wm8750mixer_0.92_armv5tel.ipk - WM8750 mixer for pdaXrom beta 3 / pdaXii13
On a side note, we’ve been discussing the extended features of the WM8750 audio chip for quite some while in this thread over at the OESF forums. I have the feeling the driver and the Qt application have received a fair bit of testing. So, that’s why I am officially releasing it today.
Alright, this blog has been very quiet for the last few months. That’s partially due to me being very busy with other stuff.
I’m slowly picking up pace and getting things done again.
So, here is a short update on the media player that I’m currently developing for my Zaurus. Well, actually it’s been in long-term testing mode for ages now… :)
I finally have a name for it. It will be called “Quasar Media Player” - or shorter “Quasar”. Below are some screenshots of the current development version running on Qtopia. I hope to have a release ready soon.
Yet another short update on the development of my still untitled media player for the Zaurus. In the meantime it’s called YAZMP.
Again, I’ve been working on improving performance - this time on the performance when loading playlists.
Before I continue, let me give a brief overview of the structure:
Library -> Playlists < -> Media Cache
YAZMP doesn’t manage a library similar to i*Tunes. Instead it solely relies on playlists. Metadata (title, artist, album, etc.) is kept in the database and will be associated to once the playlist is loaded. The reason for this is pretty simple: Scanning audio files (and media files in general) each and every time a playlist is loaded will definitely take a lot of time. So, for every file the gathered metadata will be saved in the DB. Think of it as a cache.
Continue reading ‘“Yet Another Zaurus Media Player”… done differently . (Phase 2.1: Development progress 2)’
So, like I’ve already mentioned in my previous comment, I’ve got some free time to work on my pet project here.
Development progress
I’ve been optimizing a lot under the hood. Tons of blood, sweat and tears have already run into optimizing the core parts.
Coming from a different background in programming, namely a desktop background, doing embedded development is a whole new experience for me. And let me say this: it’s definitely a refreshing one.
Development for embedded devices can be quite challenging if you have hard memory limitations and performance restrictions CPU-wise. These limitations go even further than the ones I’m used to when doing component or graphics development. And I’m doing quite a lot of that…
Just so you get the idea:
My essential requirement for this project is that the player is able to cope with thousands of files in a playlist.
With that being said, I’ve already rewritten the playlist management four times. :)
The first approach was fast but ate RAM for breakfast. Incremental searching on a playlist was fast but also required additional memory. The second approach was more memory-friendly, but searching was slow. Besides, some Qt widgets make development a real pain - at least in Qt/E 2.3.x. For instance, QListView can pose an incredible hog on performance. I’m currently using several hacks to speed things up. However, I’m still thinking about replacing the whole component or doing some custom coding to improve it…
Anyway, since I couldn’t really get rid of the memory problems, I finally decided to give SQLite a try. SQLite offers very sophisticated caching, which helps getting rid of the RAM problem. I really could use the enhanced features of a SQL database. And let me say this: SQLite is awesome. And it’s as fast as it could be on such a small device - that is, if you know how to use it…
With that being said, different rules in database design apply for embedded systems:
In the third approach I already created a pretty decent database schema. Something I naturally would have done on a desktop system. Keeping the layout clean, using relations where applicable, minimizing data storage requirements.
On a desktop system dereferencing and joining tables is fast. However, not so on my Zaurus: Simple left-joins over three tables would take up to a few hundred milliseconds. In contrast, these queries are almost unmeasurable on my desktop system, meaning they were faster than 10 ms.
Now add a few other equally expensive queries to that and imagine, you’re doing a search on your playlist with 2000 items. Do you want to wait 3 seconds or longer for the result? That’s not what I call interactive.
So, I had a nice profiling, optimizing and testing marathon last weekend. To make a long story short, after analyzing the bottlenecks and also having a lengthy discussion with a DB-guru friend, I ended up simplifying the database schema in a direction I wouldn’t normally take on a desktop system. It’s not totally ugly now, but it’s just not as relational as you might expect a SQL database to be. Also, some data is redundantly held in temporary tables, which isn’t nice either, but helps performance A LOT.
In order to do the profiling I made some changes to the SQLite codebase, which I will post shortly along with some optimization hints. Update: Hints here, patch here.
Screenshots
No release yet, sorry! I have to finalize some features first.
However, here are some new screenshots that show the new overview feature in action. The design of the application is temporary, stay tuned! :)
Andreas Junghans has an excellent tutorial on how to set up a Zaurus ARM cross compiler on OS X. However, there is one problem: It will only compile on PowerPC.
So, here is my patchset for compiling on Intel:
Use this file instead of the one offered on his page and just follow his instructions.
The fix is really simple in nature: I’ve just added one file, namely xm-openstep.h in gcc/config/i386. This does the trick.
As a follow-up to my previous entry about greylisting, here is what I used for the setup: the greylisting patch at Bill Shupp’s wonderful qmail related site.
I’ve made some modifications to his patch to allow for sender address and sender domain based whitelisting.
You can get my patch here:
large-qmail-patch_greylisting-katastrophos.net-20061023.patch
The dbdef.sql file includes an example of how to set up a whitelist filter for a specific sender domain or sender address.
The patch is against Bill’s Large Qmail Patch 0.8.3.
Three weeks ago I’ve set up greylisting on our little qmail toaster. The technique works amazingly well on our setup:
The server used to get hit by round about 1600 mails each day. Roughly 70% of those were spam mails. Now, with greylisting activated, this amount has been reduced to just a dozen spam mails and around 350 - 400 legit emails:
The server load is also reduced because SpamAssassin and ClamAV are less busy filtering mails:
So, speaking for us, this experiment has been very successful. Exactly no real mails got lost, tons of spam was blocked at the SMTP level. Excellent. Now, let’s see how long the effects of this technique will last…
See http://projects.puremagic.com/greylisting/ to learn more about greylisting.
Twitter Updates
Comments
David, duplicity broken pipe, Mike, maximus, Mark, Mike
Ted, Ted, Emmanuel, Meme, Lara Boons, stwoods, NeoBetas, Dalain, Axely, sofiaa [...]
matthis, Andre, matthis, Andre, JB, slewis69au, sofaraway2us2, JavaHack, AGAWA Koji(atty), wirelessdreamer [...]
Keith Wedinger, Gregory Robinson, Carl Carter-Schwendler
Luís Miranda, Mico, Sriram M, Andrew Ferguson, Carl Stephenson, Todd, chencho, Morgan, Ryan, Ryan [...]
Meme