Tuesday, September 27, 2011

pygame on raspberrypi, pyconuk was awesome

Thanks to @ntoll I had a chance to play around with the raspberrypi alpha board at the pyconuk conference (which was a great little community conference with a big heart).
That is it on the pink bubble wrap.  It's hooked up to a monitor via the digital HDMI video port, with a keyboard and mouse connected up via USB.

We only had a few hours to play around with it, but managed to try a few things out.  Whilst we were there playing around with it, a whole bunch of people popped there heads in to have a look and ask questions.  Lots of enthusiasm for the project, and also the machine, but also a bit of cautiousness about the project.

In another room, there was a talk going on about how the BBC was going to help bring a programming education project into the schools of the UK again - like they did with the bbc micro.  Tweets started to fly around on the tweet projection screen about it, but then at the end of the talk we found out it was a hoax.  Haha.  It was more a "wouldn't it be awesome if..." kind of talk.

So, what did we find out in our exploration of the raspberrypi?  Firstly, the rasberrypi had a debian linux distribution running on it, and many packages were available to install.  Including an old version of pygame.  Sound wasn't working for us, there were none of the various sound systems running.  It turns out the analog output port is currently really terrible.  With a 1bit DAC, I guess it will sound something like a PC speaker or maybe slightly better.  However, digital audio is going to come from the HDMI port along with the video.  So that should sound really good, assuming it is hooked up to a TV with HDMI.  There's also the option of using a $3 USB sound card - which the project reccommends if you want audio input (eg, a microphone).

One interesting thing is they have not put a real time clock on there.  So when you reboot the system it has the wrong date all the time, which really messes with things like the packaging system, and the file system.  However, once connected to the network it can grab the time from there.  You may be noticing a theme... they've cut back on components to keep the cost low.  I think that it's a great approach in order to get something useful at the price point they are aiming for.

The alpha board had no WIFI hardware, but we found an ethernet cable and plugged it into my laptop, so we were able to share the laptops WIFI internet connection through it.  @ntoll had the pygame package already installed, but it was an old version that didn't include the example programs.

@ntoll has previously blogged about his raspberrypi

So we set the debian package manager the task of installing the gcc compiler, and various other things needed to compile pygame from source(SDL, ffmpeg, portmidi, etc).  It was downloading packages over the network connection at about 1MB/s which is pretty fast for a 10/100 ethernet port (which seems to be attached via USB), and then out over my laptops wireless connection.  It did take a while to install the packages on the SD card though.  Perhaps a faster SD card could be used, or maybe the SD card driver could do with some speed improvements.  However, it wasn't too slow, definitely usable.

All the dependencies installed with no issues... winning!  Then we started up the compiler, and we got pygame to compile with gcc after a fair wait.  This was quite impressive, compiling stuff on the raspberrypi itself, rather than having to use a cross compiler.

So X was running, but so far there was no hardware acceleration of graphics.  I guess in time, someone will be working on the video drivers.  This little machine is designed around a GPU, so it is definitely capable of some fast video.  So web browsing with iceweasle (rebranded firefox) was a bit slow.  It was pretty much unusable whilst pygame was compiling, but usable when the machine wasn't doing much else.

@ntoll got his xmas card pygame program he wrote for the london dojo last year running on the raspberrypi.  It was going a bit slow, but after a few tweaks it ran at an acceptable frame rate (if not exactly smooth).  So this is good news, because even though the graphics drivers are not hardware accelerated yet, the little machine can run simple programs at an acceptable speed.

I also tried running a very CPU and graphics demanding pygame game zanthor.  But it wasn't able to run above 1fps.  The zanthor game has trouble getting 30FPS on a 5 year old laptop with good graphics drivers, so this wasn't unexpected on an alpha board that doesn't even have its hardware acceleration available yet.

We also ran the pygame test suite, and most everything passed except for the sound related tests (and things like the camera, and joystick tests, since it doesn't have a camera or joystick attached).  Apparently there are pins that could be used to attach a camera, since this is a mobile phone chip.  There's a lot of work that could be done to pygame to make it run better on the raspberrypi, but I'm happy that it's mostly working already.

I also tried running an OpenGL demo, but it ran really slowly.  So I'm guessing that hardware accelerated OpenGL was also not working on the distribution that it came with.  But they have shown it working in other demos, so it is only time before it is working in X.  Also, I think the board supports OpenGL ES 2.0 which there is not currently a python wrapper for (please leave a comment if you know of a project for this).

There seemed to be about 189MB of ram on this board according to 'top'.  I guess it was a 256MB ram model that had 60ish MB of ram taken up by the GPU.

@tjguk was there too hacking on his quiz program.  It was interesting listening to him talk about his program, and what he was doing with it.  But I won't go into it here, since he might want to blog about it himself.

Also at the conference was Garry Bulmer who was talking about the ARM board that he has made.  Previously he has been using the arduino micro controller platform as a robotics teaching platform for kids and adults.    I'd like to follow his project, and look forward to seeing it progress.  He talked about wanting more processing power to do things like process cd quality audio, which the arduino can not really do.  His arm cpu board was aimed at also teaching hardware related things, so his board has more usable GPIO inputs and output pins for controlling electronics.  Whereas the raspberrypi board is not currently designed to work well for arduino uses.  It is good to see competition in the cheap educational ARM board space, but I think the two projects have slightly different use cases.

One concern some people had about the raspberrypi project is there seems to be a link between the broadcom employee and the chips they use on the raspberrypi board.  This could be seen as a conflict of interest.  However, maybe it doesn't matter.  Perhaps it is even a good thing!  Since then there might be better support from the company because an employee might have better access to docs, and such things.  At least there will be someone on the project who has access to the tools needed to fix bugs.  There were also concerns about the lack of source code for the chips 18MB binary blob firmware.  What does that code do really?  I think the project wants to open that source code, but so far it is not available because the company does not want to open it.  As a pragmatic option, I still think the raspberrypi is ok.  It's not completely open hardware, but it's open enough to be useful for an educational project for creating software.  The projects goals are to provide a cheap PC to children, so they can use it themselves to learn - it is not about creating an open hardware platform.

I'd love to get a development board, but the raspberrypi foundation only made 50 and they are all distributed to developers so I'll have to wait like everyone else until they are up for general sale.  I think they are aiming to make them available in a few months.

There were plenty of other interesting things going on at pyconuk this year too.  Including talks about testing(mocks, extending unittest and such things), a realtime web socket game (kwizzle) that uses tornado and mongodb, fluiddb (kinda wikipedia for databases), a visual programming environment (The Larch Environment), a django work shop, and the always good 5 minute lightning talks - where random people get up and talk about something for 5 minutes.  Amongst plenty of other things going on.  The volunteers put on a great conference again, with very little resources.  I wish I could have talked with more people at more length, but there's not really enough time to do so.  There's always a creative buzz at these things.  So many creative, passionate people talking about their projects in one spot is quite inspirational.

Wednesday, September 21, 2011

jquery.shitsound.js - a shit sound player for web browsers

Yesterday, I made the first release of shitsound.
jquery.shitsound.js is a shit sound player for web browsers.
Used like this:
$.snd.init({}, function () {
        // we are ready to play sounds!  Brilliant.
shitsound only does a few things with sound::
play, stop, stopAll
jquery.awesound.js might do:
changing volume, pitch, playing with a different tempo, playing in stereo, 3d sound, etc.
jquery.shitsound can not do any of this fancy stuff. It can just play sounds, and stop playing them.
shitsound detects which implementation to use at init time.
  • html5, using the html5 audio tag.
  • embed, for using the embed tag.
  • soundmanager1, for old flash 7.
  • soundmanager2, for modern flash (8,9,10+).
  • empty, pretend implementation that does nothing.
It currently requires jquery, since I use jquery. However it could quite easily drop the jquery dependency with some work. Other dependencies are soundmanager 1 and soundmanager 2, as well as (optionally) swfobject. These are all bundled in ready to use though.
Each implementation is kept separate in the code base, and it is fairly easy to extend with other implementation. The html5 implementation is separate from the soundmanager1 implementation for example. I plan on implementing a phonegap implementation in the future.
If you'd like to see another JavaScript audio engine supported, please let me know.

Yes, it does support netscape navigator 3+. As well as old versions of internet explorer that don't have flash installed, or have old versions of flash installed.

preparing your audio

Because sound support on the web is shit, you need to prepare your audio in various different formats for it to work cross platform.
You need a .wav file, a .mp3 file, and an .ogg file to support all platforms.
It might not be a good idea to include big .wav files for large amounts of audio like songs though. Because they can be 10 times larger than a lossily compressed mp3 or ogg file. But if you want full browser support, then .wav files are required.
The ffmpeg is quite a common powerhouse of a multimedia tool. It is available on OSX through brew, or macports. It can even convert audio for you.
  • ffmpeg -i file.wav file.mp3
  • ffmpeg -i file.wav file.ogg

preparing your webserver

If you use nginx you might need to modify your /etc/nginx/mime.types file for oggs::
audio/ogg ogg;
Other web servers may also need mime types being added.


Maybe these things will be done in the future.
  • volume control. This is possible with all backends.
  • Better browser detection, and blacklisting of bad html5 audio engines.
  • wider testing and debugging.

Wednesday, September 14, 2011

pygame sprint at pyconuk, and virtually. Friday 23rd to Sunday 25th of September

There is going to be a pygame sprint at this years pyconuk. We're going to tackle whatever the participants who turn up want to hack on. That might be porting to a new platform like the $25 rasberrypi computer(there's going to be a couple at pyconuk), or improving the pygame android support. Or it might be polishing off one of the new modules like the new freetype font module, or perhaps implementing a brand new module.  Or maybe it's jazzing up the documentation, or working on a new import pygame.examples. I'm getting there on Friday, so I hope to do some hacking then, and we might be able to get some sprint space for the Friday(conference propper starts Saturday, but some people are getting there early) - otherwise it will have to be in a cafe or something.
Also going on during the conference is the python core sprint and CKAN sprint.  It should be fun to join in on those sprints too.  Of course there will be talks, work shops, an unconference room, lightning talks (5 minute talks) and coffee fueled hallway conversations.  There's even going to be a Code Dojo - london style, and of course - most importantly: lunch/dinner.

pygame recently migrated to mercurial and bitbucket: https://bitbucket.org/pygame/pygame  We'll be able to commit changes to there or work off branches and submit pull requests later.  There is a pygame hacking guide which we will make notes on any questions people have with working on the pygame code base.

It will also run as a virtual sprint in the irc chat room (freenode #pygame), so if anyone wants to join in remotely they can.  If you only write python code, there are plenty of parts of pygame that can be worked on.  For anyone who turns up I can show them the basics of CPython modules if they already know C.

We'll try and tweet sprint goings on via the @pygame_org twitter account.  Hope to see you there.