The code in linuxaudiodev does its initializations in an order which is explicitly proscribed by the OSS programming guide.

I have a SWIG-based linux audio module that I use in my code, not wanting anything to do with the (to me) highly suspect linuxaudiodev module. Should I dust off this code and contribute it?

Of course, if we really want to provide high-quality audio support on Linux, we have to account for a number of different options - at least, OSS and ALSA... this is sort of a can-of-worms. But I do believe that the current linuxaudiodev module should be deprecated.

Sure. Do you want to take the lead here? Nobody at PythonLabs has any interest in this, and without someone putting a stake into the ground, there's no point in even talking about it. It sounds you know what you're talking about, and you have CVS permission, so if you want to do it, go ahead. (For b/w compatibility we may have to keep the linuxaudio extension around for a while, in a deprecated state.) --Guido van Rossum (home page: http://www.python.org/~guido/)

Charles> I have a SWIG-based linux audio module that I use in my code, Charles> not wanting anything to do with the (to me) highly suspect Charles> linuxaudiodev module. Should I dust off this code and Charles> contribute it? Charles> Of course, if we really want to provide high-quality audio Charles> support on Linux, we have to account for a number of different Charles> options - at least, OSS and ALSA... this is sort of a Charles> can-of-worms. But I do believe that the current linuxaudiodev Charles> module should be deprecated. Charles, is your SWIG-based thing still Linux-specific? (I sort of suspect it is.) While having to support multiple options will be a pain, I think they will each tend to be more platform-neutral than the current approach. Skip