Periodic Pulseaudio Failure

The desktop I am on right now is running Ubuntu 8.10, complete with all of its PulseAudio glory (frankly, I wish they had waited until that glory was a little greater before making it the de facto sound system) and I had a problem that ran as follows: I would boot up the machine and sound would work beautifully for a while. After a couple days or so, sound would inexplicably stop working. I fired up the sound preferences applet, hit the magic “Test” button and, lo and behold!, it failed with a message containing the words:

audioconvert ! audioresample ! gconfaudiosink: Failed to connect: Connection refused

So, I would kill, restart, or start any sound service or process I could find, but sound did not return. A system reboot (something I am loathe to do) solved the problem–for a couple of days, then I was right back at the beginning. I did some googling this time around and ran the command

$ pulseaudio -vv

To see the output. There was a great deal there, but the key was this:

Error opening PCM device hw:0: Device or resource busy

Okay. So I googled it. After reading a couple of almost relevant posts, I opened up /etc/defaults/pulseaudio and changed




then ran

$ sudo /etc/init.d/pulseaudio start

and sound came alive again! What is this doing? Basically, it takes PulseAudio out of userland and puts it at the system level. The comments indicate that this is a bad idea because shared memory wouldn’t work and “could potentially allow users to disconnect or redirect each others audio streams”. Both arguments seem rather academic. I am sure the lack of shared memory access could be a performance hit, but having no sound is the ultimate performance hit (it consumes 100% of the resources with a performance of 0%!) and my untrained ear could hear no difference. The second one is relevant if you have multiple users on the same box who are running sound. This, of course, is not true on my desktop where I am the only user. Again, I understand the desire to close a security vulnerability but, personally, I would rather have sound and chance someone listening to the Derek Webb song I am listening to than have to reboot my computer every couple of days.

Vim tip…

I have been wondering for a long time how to copy text out of gvim into the operating system/window manager’s clipboard. Doing something unusual work today (most of my programming is a bash/screen/vim session; no gui until testing), I wondered again and finally decided to find out.

If you copy to the + register (i.e. “+, then a yank command) it will be available on the system’s clipboard.

So now I know.

Why there will never be an open source VB6

I was going through some code today and had to google some VB 6 related items. Both wikipedia and one of Jeff Atwood’s old postings have links to a petition to plead with Microsoft to keep legacy VB alive and well. Needless to say, in hindsight, it failed. One thing occurred to me, though: legacy VB would make a perfect candidate for open source cloning. It would be comparatively simple (both the language and syntax). Unlike Samba, Wine, or Mono it would not be trying to hit a moving target as Microsoft is no longer actively developing it. With a COM Bridge and a reimplementation of forms (probably through GTK, Qt, or wxWidgets) legacy code could be made operational and most code, that which does not actively use COM, could be almost automatically cross-platform. Moreover, those business with a vested interest in legacy VB, i.e. those with a pile of legacy code, would still be able to use it and depend on it and those disenfranchised VB6 programmers would be able to use their favorite language for life.

But it will never happen. The reason is quite simple. The people who actually mourn the loss of Visual Basic are not the ones, as a rule, who will be able or willing to write a compiler for it. This is not to say that there haven’t been a few open source imitators or derivations from it. Gambas, for example, is VB-like, but it is no VB clone. There are, I am sure, others who have done work heavily influenced by Visual Basic–but no actual clones (at least, not any of any real size). The next place to look for a clone (either commercial or open source) would be the companies that have a vested interest in VB, that is, the ones with a huge pile of VB code lying around. Once again, these are not apt to undertake the project for the very reasons that made them choose Visual Basic in the first place. The business case for VB runs something like this: it has a mammoth company (Microsoft) backing it and supporting it, we can get full commercial support from this mammoth company and we know that they will be around for a while (i.e. they won’t go bankrupt and leave us high and drie), and programmers for this language are as common as dirt (so we won’t have to shell out a fortune to some obscure consultant after our lead developer quits). In short, it is a safe pick. Obviously, none of these reasons (I pass no judgment on whether or not they are well founded, only that they are the reasons) are conferred on a project or an odd-ball third party clone (which also runs a pretty high risk of getting sued).

To summarize, the problem is not one of technical difficulty or logistic difficulty (i.e. keeping up with a constant stream of changes), but one of demographics. The very people who would most want this product are the ones least likely to carry out the work. Atwood points out in his article above that most VB developers are moving into C#. I think this is true. VB.NET is probably not the future of the .NET platform. Indeed, it has been a fairly second rate citizen in the .NET world. Read or skim through the ECMA document on the CLI environment. It is clearly modeled after C#, itself modeled after Java, not VB. To all appearances, VB.NET exists largely to ease legacy VB users and apps into C# and the .NET future–at least, that’s the strategy. As for how it plays out, only time will tell.