Avoiding audio skipping in Linux 2.6

After upgrading to the 2.6 kernel series in Debian Sarge I had terrible problems with sound skipping when switching desktops or tabs in Firefox, or basically when doing anything that takes a significant amount of CPU. Adding a larger buffer to xmms, killing artsd or switching audio drivers didn't help.

The reason was actually a combination of two factors:

First of all, when using the 2.6 scheduler, it is advisable to run the X server at nice value of 0, instead of -10, which is the default after installation. If X is at -10 heavy X operations (like Firefox redrawing a web page) will make lower priority apps starve.

Second, zsh has the option bgnice, which makes commands started in the background with & to be run at nice 5. This option is on by default, unlike in, for example, bash.

So, if you start xmms with the command "xmms &" and run X at -10, the result is that sound will skip horribly.

The remedy was quite simple: run 'dpkg-reconfigure xserver-common'. This will explicitly ask for the nice value for the X server and will explain that 0 is the appropriate value when running under kernel 2.6. Too bad this wasn't done or suggested by default when upgrading to 2.6.

For more information, see http://ck.kolivas.org/audio_hints.txt or this kernel mailing list posting.

Debian Sarge - first impressions

So, Sarge was finally released - the apocalypse can't be far away now. I just couldn't resist trying it out right away. I've been running Sid for a long time now, so I didn't expect any groundbreaking new features over that, but I wanted to see how smoothly the new stable version works.

Downloaded the DVD image with BitTorrent in a bit over an hour, burned, booted. Picked a spare partition I use for trying out OS installs. It automatically detected the W2k and Sid partitions and offered to add them to the GRUB boot menu - nice. The install procedure was remarkably straightforward compared with previous versions of Debian. Also, installing from the DVD was _fast_ - a complete desktop system install with over 1.7 gigabytes of stuff (GNOME, KDE, OpenOffice etc.) was done in less than an hour.

X configuration could be improved a bit: you have to pick a driver for your display card from a list instead of it being automatically detected. IIRC Ubuntu was better in this respect. For some reason the X configurator didn't add any resolutions bigger than 800x600 into XF86Config-4 and I wasn't able to easily find any graphical tool for fixing that so I added them manually. The monitor was properly detected with DDC, though, so I wonder what the problem was.

The new system seems to be much faster than my old Sid install. Of course Debian doesn't gather cruft as badly as Windows does, but the zillions of services installed just to try them out add up eventually.

Some of the games in Sarge are quite impressive, like

• Critical Mass, a really fast and smooth Galaxians style shoot'em up. It's great that the entire game experience in this is _fast_. You don't need to spend time looking at any "GET READY" text before starting a level and there are no delays when the game is over: When you die, you can start a new game immediately with just one click, which is really nice in a game such as this where you pretty much need to memorize the attack wave patterns to be successful.
  
• Blob Wars. A game about a yellow blob with a bandana. And guns. Lots of guns.

The X server supports GLX direct rendering out of the box and I get 834 FPS in glxgears, but unfortunately the Radeon All-In-Wonder driver still has bugs: Sometimes programs that use OpenGL work properly, sometimes they start printing "radeonUploadTexImages: ran into bound texture" and slow to a crawl. Or could this be just my card running out of texture memory or something?

It's infuriating that after so many years there is still no X server available for this card that would support both TV-output and direct rendering. For the past year or so I've used an X server compiled from old sources where the TV output works, but direct rendering doesn't. By now I've pretty much given up hope of ever getting everything working on it, so I think I'll be buying a new display adapter sometime in the near future.

Anyway, minor bugs don't change the fact Sarge is still a wonderful piece of work and a major achievement for free software. A big thanks to all the Debian people for their efforts and congratulations on the new release!

And now on to gathering courage to dist-upgrade my Woody file and web server, uptime 232 days and counting...

My favourite Firefox tweaks

• All-In-One Gestures: execute common operations with mouse gestures. I like these bindings:
  • left/right: previous/next tab
    
  • down: close tab
    
  • up: new tab
    
  • up,left,right: undo close tab
  
  This way I can perform tab operations without having to precisely locate the tab or even to look at the tab bar. Also, when "undo close tab" is readily available you can map the (very common) "close tab" operation to an easy gesture without having to be careful with it.
  
• SessionSaver: I wish this had been available back when Firefox was more unstable. Even now, it makes trying out extensions a lot more convenient.
  
• MediaPlayer Connectivity: Play embedded video files in the player of your choice. You don't have to read the source code of the page to see the videos anymore! Yay!
  

Random bits

It seems like the people of the PDIS project have been busy these past weeks. That appuifw compatibility layer of theirs is now also available for Windows and Linux. It's sort of like the Symbian emulator, only it emulates the Python-level API instead of the C++ level API. They also provide an alternate socket module that you can use for noninteractive Bluetooth discovery.

In other news, Christopher Schmidt wrote this TrafficCam app as a response to the winning entry in Macromedia's Flash Lite contest. The Flash app has some pretty gorgeus eye candy, but I bet adding the traffic cameras of your home town to it is not as easy as with the Python version... and, well, 45 minutes from zero to the first working version is pretty damn fast. (Biased? Who, me? :)

Matt's wiki has links to these and more. Oh, and people: if the Python bites you, remember to warn others at the PythonGotchas page.

Python for Series 60 Status

So, the 1.0 release is now done and in the wild, and development continues. In the near future we'll try to get the legal issues settled so that we can start releasing code without having to deal with so much red tape as for the formal releases. There's quite a bit of stuff that we've developed to a useful state, but that is not polished and tested well enough to merit a formal release. Starting a Sourceforge project for these code snippets and extensions is one viable option. We'll see how it works out.

Some of this stuff that's hopefully coming soon includes:

• Nonblocking sockets and select() support. The native socket module shipped with 1.0 actually already contains the necessary support for asynchronous calls, and this is just a pure-Python wrapper over that functionality that provides a standard nonblocking socket/select interface. The current version already works well enough for the irclib module to work without changes.
  
• A pure-Python (platform independent!) file transfer server, for transferring files to and from your phone over Bluetooth. This is a real godsend compared to the awful PC Suite - just edit your scripts on the computer, run a synchronization script and five seconds later you can run the new code in the Bluetooth console.
  
• zlib. Porting this to Symbian was easy. You just had to change the static type objects to dynamically allocated ones and add some boilerplate code and that was it.
  
• A concise and commented example on how to port an existing Python extension to Symbian. In the mean time you can check out the PyExpat port that the HIIT people made to see what needs to be changed while porting.
  
• A screenshot module.
  
• Unofficial fixes to some of the issues in the release notes. Some of the bugs are really trivial to fix, but they were found only after the final packages were signed and just a few days before the release. I'm talking about things like the get and setdefault methods of e32dbm. *puts brown paper bag on head*
  
  Oh, and if you are wondering what kind of magic the e32.Ao_lock() call in the rssreader.py example code RSSFeed constructor is doing: it's just leftover junk that was used in some previous version, but which is completely redundant in the current code.
  

Graphics support and some sort of a canvas widget is the next big thing on the agenda. The intention is to have a reasonably efficient and easy-to-use API for drawing and event handling that interoperates nicely with the native UI framework. The planning for this has only just started, and no specifics have been nailed down yet. One option is to use the PyGame API, and possibly provide access to an OpenGL ES renderer but this is just an idea. Feel free to comment if you think you have good ideas on what sort of a graphics widget you would like to see.

Tip: If you are thinking of trying out Python for Series 60, do see the Python for Series 60 wiki at postneo.com. There's a bunch of links to relevant blogs and other resources on the web. I suppose that's as good a place as any to use as the repository for related information.

Introducing...

Well, hello everyone and welcome to my blog. I actually created this some time ago, but I haven't had much use for it until now. Long story short: I was and am one of the developers in the Python for Series 60 project. I'm as excited about it as anyone. It's frankly quite incredible to get paid to work on a project I might even do for free, given a sufficient amount of free time :)

Anyway, since the future of this project depends to a big extent on what all the hackers do with it, I figured I should do what I can to share what I know. Hence, this blog. At this point I won't give any promises on how frequently I will post, but I will do my best to keep you up to date on what is happening in the Python for Series 60 world. I cannot comment on any matters that are company confidential, but that still leaves a lot to discuss.

If you have anything to ask, feel free to post comments here.

DISCLAIMER: This is my personal, unofficial blog. All opinions expressed here are mine, and not Nokia's.