Older blog entries for volsung (starting at number 13)

Damn. First major code submission and my first major screw up. The libao mega-patch I submitted to vorbis got integrated and broke the build for NetBSD users. Some guy started mouthing off on another list about how vorbis sucks because the tools (ogg123 and vorbize) don't work for NetBSD. Actually, they do (since NetBSD supports OSS) I just forgot to include that in the configure script. Grr..

I feel bad that Monty has to put up with crap like that when it was my fault in the first place. It also irritates me when people start mouthing off about how crappy a program is when the effort required to fix the problem is trivial. Email me about the problem and I'll fix it! Don't go complaining like a helpless fool. That's what you do when you run software that is written by people who don't care (or aren't paid to care) about users (cough, cough, insert your most hated program here).

I guess this is part of the learning experience. I can hardly wait until I get my very own flames. :)

Update: Argh. I hate script kiddies. Some prick buffer overflowed our ftp server and installed a root-kit. Fortunately, the root-kit install deletes samba (why?) which is rather essential to the operation our server. So I noticed right away when I got back from lunch that something was wrong. Next, rpm -Va saved my butt and showed me what had been screwed with. Actually finding the root-kit took a while until I noticed that all of the files this kid created were owned by the ftp group. "find -group ftp" quickly turned up a "/lib/   " (yes, that's three spaces) directory. Bingo! The installation script and all of his goodies were left there. Additionally, the kid left his buffer overflow login in the log, so I had his IP on a DSL modem. A quick letter off to the abuse address of his ISP will hopefully take care of things.

My lesson for the day is read the RedHat Security Advisories. They had the wu-ftpd exploit up for a month already. (Smack!)

[Dang Netscape sucks. My brother showed me his webpage which promptly killed Netscape, and my partial advogato entry. Doh!]

Odd. I feel a disturbance in the trust network. :) This morning I discovered that I had been certified by more people (thanks, whoever you people are), but that my overall trust level dropped back to Observer. I don't get it.

Update: Weird. I'm back at apprentice again. I don't get what happened.

In other news, we had a bomb threat in the building where I work. It's got a whole bunch of laboratories and offices. The police "inspected" the building and decided to let people back in. My boss and I wondered how the police are supposed to tell the difference between a bomb and a vacuum pump, or a lithium oven. Heck, any complex electronic device could be a bomb. I don't get it. Oh well, I've decided that people who make bomb threats are jerks.

I've decided that I don't like programming with a mouse. LabVIEW is a neat concept (graphical programming), but it is fairly cumbersome to do anything other than data-flow style programs. Loops are kludged in for completeness. I want source that is a text file, not a picture. I can't grep a picture.

ian: Conclusion -> People hate computing. :)

nymia: IIRC, threads are processes in Linux. The kernel treats them almost the same. The threads just share more parts of the process structure. I wish I could find a reference for this.

In other news, I'm still waiting for Kenneth to integrate libao into the vorbis CVS. Maybe I have to pester him a little.

While I wait for word on that, I've been spending my time hacking on some old code of mine. I wrote some code to interface to those netshooter remote controls that plug into the serial port. I stopped after the basic decoding was working. Now I need to figure out how to parse a config file describing the actions that should be performed when I press a particular button on the remote.

mrorganic: My theory is that Linux has become "trendy" enough to attract a different type of user/programmer than in the past, one which tends to be less productive and more vocal. Reading Freshmeat (as someone pointed out here) is a good way to see gauge the culture. You find lots of inexperienced (myself included) programmers with minimal abilities, often driven more by ego than technical issues. The joke about the project that has no design and no code (but certainly a project lead) which is looking for programmers demonstrates the "leader looking for a following" mentality.

Fortunately for the BSDs, Linux has become the lightning rod absorbing all of these people due to its exposure and growing ease of installation. The result is the BSD talent pool has not been diluted to the same extent the Linux talent pool. I still believe that there is as much good Linux code as BSD code, but good luck finding it through the daily announcements of KickASS-AIM-0.0.0.3: yet another messenger clone that just started from the [LM]AIM code base and added different colors. (Okay, I made that up, but you get the idea.)

Be wary, however. If BSD becomes the trendy OS of the week, you'll get to watch the last 3 years of Linux history happen all over again. I wish it weren't so, but someone's development community is going to overrun once the lemmings (and the media) get tired of Linux. The next OS to get hit will either be BeOS or BSD, it's too soon to tell which.

Sent off my libao patch to Kenneth. Now we just have to see if he'll incorporate it into ogg123.

Not much else going on today. I'll probably do some history reading. The Vietnam War is really quite interesting. If computers and physics weren't so much fun, I think studying foreign policy would be neat. Well, maybe if it had math.

Yes, mathematical foreign policy would be cool. :)

Dang, Win32 is *ugly*. I dug up the MSDN Library CD here at work and started reading the section explaining sound output. Boy, I don't like it. The waveOutWrite() call is always non-blocking *and* I can't free the buffer until the write is done. That means I can't return from the ao_play () call in my library unless the block is done playing or I've copied it to a new buffer.

In either case, I'm going to have to figure out some goofy way to sleep until the block is done playing. A poll loop is icky because I would have to hot spin and blow CPU time. I can do a callback, but I don't have a clue right now how I should go about sleeping until the callback wakes me up. I want to use something like signals I think. I sure as heck am not going to dive into Win32 threads and lose my mind. Bleah.

Wow, Slashdot sure is whacked out these days. I went back to try and read the comments, and I can't deal with it anymore. The demographic has changed so that I'm not that interested in the discussions that go on. Too bad. I kind of liked that place.

Good thing I found Advogato, or I might have actually become productive. :)

Took someone's (darn, already scrolled off the end of the recent diary entries) advice and changed the libao API for the third time. The change was trivial, and the result is much cleaner. Thanks.

Finally figured out the ALSA problem. By default the driver operates in non-blocking mode. The program would decode the next block before the first one had finished playing and would overwrite the currently playing block with the next block. Hence the neat (though frustrating effect) of listening to Brickhouse at 33% faster speed. I fixed that and wrote some buffering code to pack the data coming in (which can be in chunks of whatever size) into 32k blocks and send the completed blocks to the ALSA driver. Sounds good.

I've decided to wait on submitting this code until Kenneth gets back. Monty mentioned a little while ago that he would no longer mess with that branch (after accidentally stepping on Kenneth during a commit frenzy). In the meantime, I'm going to see if I can scrounge up an IRIX account on some friend's box to test (at least the compilation of) libao on IRIX. Same goes for Solaris, though I don't know if our school's Solaris boxes have the sound header files. If neither of these seem feasible, I'll go figure out how to do Win32 code instead. :)

Also hacked on a patch I found to let ht://Dig work with SSL. The patch was for 3.1.4, but would not cleanly apply to 3.1.5. I've never hacked a diff directly, though I must say it is not as hard as it looks.

ralsina: Ack. Slashdot has cured me of my desire to participate (or watch) the license flamewars. I must say that the GPL == non-free debate is one of the stranger ones I've heard of. I guess my take is that every license except the public domain is "non-free" to a certain extent, just like anarchy is the only truly "free" form of government. Of course, being "free" isn't one's only motivation in such things, so the issue is how much freedom should be traded in for other things we want. That's the real debate in my mind, and the rest is just playing games with semantics.

jmg: Careful with the CD-RW. I've had problems reading them in most CD drives (unless they are also CD Burners). I imagine newer drives have no problems, but you may be stuck in front of an older box.

Got ALSA working on the spare computer. It looks really quite powerful. Perhaps one day we'll start seeing audio workstations running on this architecture. (Come on Cakewalk, you know you want to do a Linux port. You know you do!)

Finished my API rewrite for libao and tried to write the ALSA driver. Whoa boy, too much control. I have no idea which values are critical to set. I can finally get about 5 seconds of playback before the program goes silent. It keeps running, but I can't hear anything. Hmm..

Back in real life, I decided not to go to my Theoretical Computer Science class. I think my time was better spent reading the chapter for 20 min than sitting in class for 90 min. Why are these classes so boring?

Update:Argh! ALSA is making me very mad. I can't figure out how to get this thing to do anything but play "Brickhouse" (my test OGG file) at high speed. It seems to be chucking 25% of my buffer everytime I write. Ack. Tired.

I was thinking in the shower this morning and realized that my public interfaces to libao are fairly annoying. Why make the application keep track of the driver function table *and* the device state. If real life is any indication, groups of items tend to get separated and lost. I should just make generic wrapper functions that take device id's (think file id's) returned by the ao_open function, lookup the associated function table, and call the right function.

Does this sound familiar? I should have looked at the standard UNIX open() and write() functions. Doh! Reminder to self: Never forget precedent. If UNIX programmers like it, it can't be that bad. :) (I'm sure someone in the audience will have issues with that one.)

Anyway, I've started installing ALSA onto a spare Linux box I have at work. Once I get the hang of it (and get it to work with my AWE32 card), I'll write an ALSA driver for libao. Still waiting for someone (Monty) to tell me how I should get this package into the vorbis tree. Maybe my last email was unclear. (Or maybe Monty is clairvoyant and knows that I needed to fix my code.)

libao is ready to integrate into vorbis now. I still need to hear back from Monty about how to get all my changes into the tree. Next up I need to add support for ESD and ALSA.