Older blog entries for habes (starting at number 4)


I'm really happy with what I've managed to accomplish on Audacity in the last month or so. Everyone is starting to itch for a new stable release, so I have been working on trying to knock the audio i/o into shape in time for 1.2. A few months ago we moved to a thread-based model for audio i/o that decreased latency and improved resourse utilization, but there were some kinks that it took some time to discover and diagnose.

Audacity can now build against PortAudio v19. PortAudio v19 is still unfinished, but it will have the ability to support OSS, ALSA, and JACK in a single build (all natively)! I was hoping this would be finished in time for Audacity 1.2, but since it won't our audio i/o is #ifdef'd to support either v18 or v19.

Looking for Summer Work

I would really like another internship this summer. Initially I placed a lot of eggs in the RealNetworks basket, since I figured my experience with Audacity would make me a prime candidate. But Real is a wall of silence: I never heard a word back from them. I need to pursue it more proactively.

I also need to think of other places where I could find work. I would like to stay in the Seattle area if possible (though I would willingly relocate like I did last summer), and hopefully I could find something having to do with audio or multimedia in some form.

Sometimes I worry that choosing work in a field similar to the work I do on free software will force me to close off part of myself and my knowledge to the free software community. I half-heartedly approached employees of Syntrillium (makers of CoolEdit) last week at a presentation and asked if they hired interns. When I said I was interested in programming they blew me off and said that wouldn't really be possible. But what if they did have internships available? It would be extremely similar work to what I do on Audacity, would I be forced to sign NDAs and wall off the insider knowledge of Syntrillium products to the work I do freely?

It seems difficult to find employment opportunities that would utilize my free software experience.

I desperately wish I had infinite time to be able to contribute to any free software project that interested me. I am constantly exposed to really neat projects that I want to learn about and help improve. I want to do everything I can to advance the power, usability, and range of available free software.

Every time I feel this urge, I remind myself that the most productive I can possibly be is when I am working on a project I already know well. In other words, the best way to achieve my goal of furthering free software in general is to do lots of good work on Audacity and PortAudio. Meanwhile, the people who have found different niches, whether it be in the libraries that do all the grunt work or in the desktop environments that present the gateway to individual applications for the user, are simultaneously advancing the state of their pet projects also.

Not that I have the time to code much of anything these days, with school and all...

Another thing I constantly have to remind myself is that the best way to solve a problem is usually not to start with a clean slate and attempt to make an ultimate design. Though it's much less sexy, the better solution is to build on what has already been done. Every time I tell myself "we need to trash X!! It's way too hard for users to configure, the fonts suck, and you can't change resolutions," I step back and remind myself that improving X is probably the better long-term solution. My sense of aesthetics makes me want to use something like DirectFB instead, since it's clean, sleek, and new, but it would take so much to get to where X already is today.

Another place I struggle with this is all the way down to the Linux kernel. "How is my mother ever going to use Linux if configuring the network requires decyphering driver names like 'ne' and 'rtl8139?' How is Linux ever going to become robustly GUI-configurable as long as we keep using text configuration files? How far can open()/read()/ioctl()/write()/close() really take us??"

Free software is really becoming kickass in some cases. I prefer Galeon to any web browser available for Windows. Though I don't use them much, I continue to hear that Evolution and Gnumeric and Gnucash are kicking some serious ass. But how is my mother ever going to use free software if there's no free platform (meaning kernel+userspace+standard APIs) that works straight out of the box, without configuration pains?

And speaking of standard APIs, I think lack of them is a problem on Linux. How does an application play sound on Linux? Well, it's very simple! OSS will probably work, ALSA is better if it's available, JACK is best for low-latency, inter-app work, but ARtS if you're using KDE and ESD if you're using Gnome!

Challenge 2: set the resolution to 800x600 and play a movie file fullscreen. There's no obviously standard way to do this on a basic Linux/X11 box. Stuff is written for SDL, Allegro, ggi, even svgalib. Some may work on your box, others might not. This is where cathedral-engineered OS's have a one-up on us: there are standard ways to do things like this that will always work.

What Linux needs is something like LSB, but much more far-reaching.

And perhaps what I'm looking for already exists in Gnome and KDE. These are real platforms, in that a Gnome application will use the same set of APIs that any other Gnome application will. And if everything was a Gnome app or everything was a KDE app everything would be peachy.

But they're not, so we're still stuck with a situation where some apps may play sound fine, while others pop up a dialog box saying "esd not running."

That's enough for now. I want so badly for free software to succeed on laypeople's desktops. I think we're on a good track, we just need time to fill in the gaps and polish everything.

15 Jul 2002 (updated 15 Jul 2002 at 22:36 UTC) »
Audacity is getting major publicity this week!

First off, we hit 1,000,000 downloads, which are mostly from the last year and a half. That was exciting.

Then Audacity was mentioned on the TechTV program "The Screen Savers." I got it on tape this morning: an incoming caller wanted to know a way to do noise reduction on mp3s, and the hosts recommended Audacity and brought up the web page. That was even more exciting.

Then today I noticed Audacity was reviewed in the Washington Post! That was the most exciting of all. (well, besides sharing a front page slashdot story a few weeks back).

Please accept my apologies for bragging, but these are exciting times.

Audacity 1.0 is released! This is exciting for so many reasons. The two biggies:
  • we can forget about the 1.0 branch now. The 1.1 branch is so much better that maintaining 1.0 was becoming a pain.
  • a bunch of subprojects that we were putting off for the release are now progressing full speed ahead. The most exciting one is a split of the GUI and audio engine modules: this allows us to write rigorous tests to hammer at the audio engine code, as well as opening up the opportunity to implement alternate GUIs on top of libaudacity.

I finally have internet at home, which means I can do all the things I've been planning: a PortAudio implementation for JACK and/or ALSA, a media player for PicoGUI using gstreamer in Python, and who knows what else. Now that I have weekends the sky is the limit. Unfortunately I've gotten too used to working 10 and 11 hour days, so I don't have too much time during the week...

24 Apr 2002 (updated 24 Apr 2002 at 10:12 UTC) »

This week I took time that I didn't have to code two long-overdue features for Audacity: Ogg exporting and command-line exporting. There was no good reason why I hadn't written these features yet and I got tired of Audacity not having them, so I caved and tabled all my homework (including "compose a three voice fugue") to write these new features.

Ogg exporting is working nicely, and though command-line exporting works fine for me on my little-endian Athlon, I forgot to add code for byte-swapping the WAV header. Matt wisely suggested I dump my custom WAV code and just use libsndfile like the rest of the PCM exporting code does. Though it won't be as efficient since we have to copy the data in and out of libsndfile's buffers, the robustness and reliability will be worth it.

The gap between Audacity's 0.9 branch (which we are releasing from these days) and the 1.1 branch (which we are hacking on) is becoming wider all the time. The 1.1 branch has so many significant improvements over the 0.9 branch that I wish we could dump the 0.9 branch completely. But then we would lose some of the freedom to make drastic changes on a regular basis, so it's probably a good thing in the end.

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!